React是JavaScript库而非框架，核心价值是以组件为单位组织UI和逻辑；函数组件+Hooks为官方唯一推荐写法，首字母须大写；组件化重在责任边界而非视觉切割；通信仅用props、Context、自定义Hook三种方式；JSX是JavaScript表达式树。

React 是一个用于构建用户界面的 JavaScript 库，**不是框架，也不强制你用它的路由或状态管理方案**；它最核心、最不可替代的价值，就是**以组件为单位组织 UI 和逻辑**——所有功能都围绕“怎么定义组件、怎么组合组件、怎么让组件响应数据变化”展开。

函数组件是当前唯一需要掌握的组件写法

React 官方自 18 版本起已明确推荐函数组件 + Hooks 的组合，类组件（class MyComponent extends React.Component）不再出现在新文档首页，且无法使用 useEffect、useState 等现代能力。

• 函数组件本质就是一个返回 JSX 的 JavaScript 函数，首字母必须大写（否则 React 会把它当原生 HTML 标签处理）
• 它接收一个 props 对象作为参数，可以解构使用：function Button({ text, onClick }) { ... }
• 内部可调用 useState、useEffect 等 Hook 来管理状态和副作用，无需 this 或生命周期方法
• 错误示例：function button() { return Click; } → 首字母小写，React 渲染为 原生标签，不会当作组件执行

组件化不是“拆页面”，而是“划责任边界”

很多人以为组件化 = 把 HTML 按视觉区域切开，比如“头部”“轮播图”“商品列表”。但真正决定要不要拆成组件的，是**是否具备独立状态、是否可能被复用、是否需要单独测试**。

• 有自己状态的逻辑块必须抽成组件：比如一个带计数器的 Counter，不能和父组件混在一起写
• 同一份 UI 在多个地方出现（如按钮、表单输入框），哪怕只差一个颜色，也该封装 —— 否则改样式要搜 5 个文件
• 无状态展示型组件（如 UserCard）和有状态容器型组件（如 CartManager）应分离，前者只收 props，后者负责拉数据、处理事件
• 反模式：App 组件里写 200 行 useEffect + 手动拼接 DOM，不拆任何子组件 → 后续加个筛选功能就得重读全部逻辑

组件通信只有三种可靠方式，别造轮子

父子之间传数据，看似简单，但错用方式会导致调试困难、性能下降甚至 rerender 泛滥。

• props 下传 + 回调上抛：最基础、最可控的方式。子组件触发 onClick，父组件传入的函数处理业务逻辑并更新自身 state
• Context + useReducer：适合跨多层、低频变更的数据（如主题、用户登录态）。避免把所有状态都塞进 Context，否则每次 dispatch 都会让所有 useContext 的组件重渲染
• 自定义 Hook 封装逻辑：比如 useApi、useForm，把获取数据、校验、提交等流程收拢，再在不同组件中复用 —— 不是组件，但服务于组件化
• 危险操作：直接修改父组件传来的对象/数组（props.items.push(...)）、用 ref 跨组件调方法、手动维护全局变量同步状态

JSX 不是 HTML，它是 JavaScript 表达式树

写 {title} 时，你不是在写模板，而是在调用 React.createElement 构建一个描述 UI 的对象。这个细节决定了很多行为：

• className 而非 class：因为 class 是 JS 保留字，JSX 编译后要能合法运行
• 条件渲染必须用三元或逻辑与：{isLoading ? : }，不能写 if 语句
• 列表必须带 key，且 key 要稳定（别用 index 当 key 处理动态增删）；否则 React 的 diff 算法会复用错误的 DOM 节点
• 事件名是 onClick 而非 onclick，且传的是函数引用，不是字符串：onClick={handleClick}，不是 onClick="handleClick()"

组件化真正的门槛不在语法，而在判断“这个逻辑该不该属于这个组件”。比如一个搜索框，是否该自己发请求？是否该缓存历史？是否该支持快捷键？这些问题没有标准答案，但每一次拆分决策，都在塑造应用后续半年的可维护性。