1. 为什么先啃这三块骨头React 从 2013 年诞生到现在生态已经膨胀到令人头皮发麻的程度——路由有 React Router状态管理有 Redux、Zustand、Jotai数据请求有 React Query、SWR样式方案更是多到能打一架。但无论这些工具怎么迭代底层那几块基石从来没变过语法、组件、JSX。这三样东西是 React 世界的母语不把它们揉碎了嚼烂了后面学什么都是在沙地上盖楼。我见过太多人一上来就冲进 Redux 和 Next.js结果连函数组件和类组件的区别都说不清楚JSX 里写个className都要犹豫半天是不是拼错了。这种学法最致命的不是不会而是不知道自己不会——业务代码能跑但换个场景就懵性能优化无从下手bug 排查全凭玄学。这篇文章我想用最接地气的方式把 React 的语法底子、组件机制和 JSX 规则摊开来聊一遍。里面不会有花哨的炫技也不会有十分钟精通React这种鬼话都是我在实际项目里反复踩过的坑和沉淀下来的套路。适合刚接触 React 的前端初学者读也适合那些用了很久 React 但总觉得根基不稳的同学回头查漏补缺。2. 语法基础React 的“方言”到底特殊在哪React 的语法大框架就是 JavaScript它没有自创一套语言。但为什么很多人初看 React 代码会觉得不像 JS因为 React 代码里混着两种特殊的东西JSX 语法和组件专属的调用方式。理解了这两个点React 代码就不再是天书而是一套有规律可循的表达。2.1 先搞清楚 JSX 不是 HTML也不是模板字符串JSX 的全称是 JavaScript XML它是在 JavaScript 文件里直接写长得像 HTML的标记语言。很多新手第一眼看到 JSX会觉得这就是 HTML 嵌在 JS 里于是下意识地用 HTML 的规则去理解它结果处处碰壁。最典型的差别在三个地方第一HTML 里class是定义样式的JSX 里必须写成className。因为 JSX 本质是 JavaScript而class在 JS 里是关键字直接冲突了React 就改用 DOM API 里的className这个叫法。我在带着几个刚入门的朋友做项目时他们几乎都在这上面栽过一跤控制台报错说 Invalid DOM propertyclass然后一脸茫然地来问我。第二HTML 标签可以不闭合比如img、input、br浏览器会自动容忍。JSX 里一律要求严格闭合img /、input /这种自闭合写法才是合法的。这个规则看着小实际写起来经常漏尤其是从 HTML 模板转到 React 项目的前几天几乎人人都会因为这个编译报错。第三HTML 里的注释是!-- --JSX 里注释得写成{/* */}。因为这个大括号是把表达式嵌入 JSX 的语法标记/* */才是 JS 的注释写法。你要是直接在 JSX 里写 HTML 风格的注释React 会把它当作文本渲染到页面上虽然不报错但页面会莫名多出一段注释文字这种隐性问题比报错更坑。2.2 大括号是 JSX 和 JavaScript 之间的“传送门”JSX 里有一个核心规则凡是动态的东西都要用{}包起来。这个{}就是 JSX 世界和 JS 世界之间的传送门里面可以写任何 JavaScript 表达式。来看一个实际例子function UserCard({ user }) { const greeting 你好${user.name}; return ( div classNamecard h2{greeting}/h2 p{user.age 18 ? 成年用户 : 未成年用户}/p span{user.tags.join( / )}/span /div ); }这段代码里greeting是变量三元表达式是条件判断join是数组方法调用它们全部都被包在大括号里。这个传送门特别强大因为它不只是填充值还支持任何 JS 表达式包括函数调用、数组方法链、逻辑运算。但这里有个新手特别容易混淆的地方{}里只能放表达式不能放语句。比如if、for、switch这些都不能直接写在大括号里。原因很简单表达式有返回值语句没有。1 1是表达式它会算出 2if (x 0) { ... }是语句它不产生值。JSX 渲染需要的是值所以语句在里面毫无意义。你可以在大括号外面用if提前算好结果再把变量传进去或者直接用三元表达式、短路运算这些表达式化的逻辑来搞定条件渲染。顺便说一个我刚用 React 时踩过的坑你以为{}里写个console.log(hello)能打印日志确实能打印但这行的返回值是undefined所以 React 会把它当作undefined渲染——实际上 React 对undefined、null、false都是直接忽略不渲染的所以页面不会出错但你也什么都看不到。2.3 一切皆“表达式”的思考方式学会了{}传送门下一个关键认知是用表达式思维代替语句思维。这是从会写 React到写好 React的分水岭。比如你有一个数组要根据长度显示不同文案// 不推荐先在外面算好 function CommentList({ comments }) { let title; if (comments.length 0) { title 暂无评论; } else { title 共 ${comments.length} 条评论; } return h3{title}/h3; } // 推荐用表达式直接搞定 function CommentList({ comments }) { return h3{comments.length 0 ? 暂无评论 : 共 ${comments.length} 条评论}/h3; }我也不是让你所有逻辑都硬塞进 JSX那也会把代码弄得没法看。实际项目里常见的是混合策略复杂逻辑抽成函数或变量简单逻辑用表达式。核心原则是你写的每一行 React 代码都要时刻意识到它是在计算一个值还是在执行一个动作。前者是用来渲染的后者是用来响应事件的。搞混这两者代码就会越写越拧巴。3. 组件机制从函数到 UI 的思维方式转变组件是 React 的核心抽象也是我最想提醒初学者认真对待的一个概念。很多人在学习时只是机械地跟着教程写function App() { return div...但完全没意识到这个平平无奇的函数背后是一整套以函数为界、以输入输出为轴的设计哲学。3.1 为什么说“组件就是函数”React 的组件本质上就是一个函数。它的输入是props外加内部状态state输出是一段 JSX也就是 UI 描述。如果你自己写过一些规模稍大的原生 JavaScript 项目应该能感受到那种痛点DOM 操作散落各处代码的数据逻辑和界面逻辑纠缠在一起改一个需求要小心翼翼点好几个文件。而 React 的组件化思路就是把数据到界面的映射关系收拢进一个个独立的函数里。你用这个组件时只需要关心两件事传什么进去props得到什么出来UI。用生活化的类比来说React 组件就像一台咖啡机。你往里面放咖啡豆和水props按下按钮它稳定地给你倒出一杯咖啡UI。你不用关心机器内部怎么加热、怎么研磨只要接口不变内部随便改。组件化拆分的核心价值就是这个接口稳定、内部自治的封装性。但这里有一个关键认知要纠正组件内部绝不是一团死水。React 组件有自己的生命周期有内部状态。也就是说它接收外部输入的同时还能自己维护一些随时间变化的东西。这就是useState这类 Hook 存在的意义。看这个实际场景做一个点赞按钮父组件传过来初始点赞数按钮内部自己维护用户是否点赞和显示的数字。点赞数会变这个变是组件内部的状态不是父组件的东西。这就是函数组件里useState最常见的用法——外部给初始值内部负责后续的动态演化。3.2 函数组件 vs 类组件选哪个为什么组件有两种写法函数组件和类组件// 函数组件现代写法的绝对主力 function Welcome({ name }) { return h1你好{name}/h1; } // 类组件老项目里还能见到 class Welcome extends React.Component { render() { return h1你好{this.props.name}/h1; } }如果你现在开始学 React我不建议你在类组件上投入太多精力直接学函数组件 Hooks 就好。原因有几个方面第一函数组件代码更短心智负担更小。同样的功能类组件要写class关键字、extends、constructor、super(props)、this绑定一套组合拳下来简单功能也会被写得冗长。函数组件就一个函数参数进来返回值出去清爽利落。第二类组件的this是个大坑。方法内部要用this.state、this.props还得记得绑定事件处理函数忘了绑就报undefined这种错误在项目里见得太多了。函数组件靠闭包捕获 props 和 state天然没这问题。第三React 官方对函数组件 Hooks 的态度很明确未来所有新功能都在这个方向上推进。类组件虽然还能用但更像一个历史遗留的兼容层了。不过话说回来如果你维护的是老项目类组件必须能看懂。核心就是知道this.state管内部状态、this.props管外部输入、render()方法返回 UI在这个基础上改点小需求没什么太大障碍。3.3 Props数据从父到子的单向河流组件之间怎么传数据答案是props。Props 是父组件传给子组件的数据在子组件里是只读的。这个只读设计非常关键。React 的数据流是单向的——数据从父组件流向子组件子组件不能直接修改父组件的 props。如果你在子组件里改了 propsReact 在开发模式下会有警告而且这种改动不会触发父组件更新最后的结果就是界面表现混乱数据源失去唯一性。举个例子父组件有个用户列表渲染UserCard子组件。子组件收到的user对象是父组件数据的一份引用子组件里面不能写user.name 新名字正确的做法是子组件把用户想改名字这个意图向上抛调用父组件传下来的回调函数让父组件去改数据源头。这套数据往下流事件往上走的模式是整个 React 组件通信的纲领。props 不光是数据也可以是函数。父组件传一个onDelete回调给子组件子组件在删除按钮的点击事件里调用它。这个模式就是子组件想要改变父组件数据时唯一的合法通道。我第一次带项目的时候就发现新人最容易犯的错就是跨层直接修改数据把单向数据流搞成双向奔赴代码复杂度瞬间爆炸。4. 事件处理React 和原生 DOM 的“翻译层”React 不是直接给 DOM 元素绑定事件它有一套自己的事件系统。这套系统的存在让跨浏览器表现一致成为可能也让性能优化有了更多下沉空间。4.1 用驼峰命名替代小写事件名原生 HTML 里点击事件是onclickReact 里是onClick语法上还有更多地方要注意// 原生写法 button onclickhandleClick()点我/button // React 写法 button onClick{handleClick}点我/button留意两个区别事件名是驼峰onClick而非onclick事件值是一对大括号包着函数引用不是字符串调用的形式。很多教程都只给这么个对比图就完事了但我觉得真正值得展开的是这里的大括号为什么是函数本身而不是函数调用。如果你写onClick{handleClick()}React 会在渲染时立刻执行这个函数而不是等点击时才执行。渲染页面时运行一个本应在点击时运行的函数轻则逻辑错乱重则死循环报错。正确的写法是onClick{handleClick}就是传引用、不调用。如果你需要给事件处理函数传参不能直接onClick{handleClick(id)}得用箭头函数包一层button onClick{() handleClick(id)}删除/button这种写法是每次渲染都新建一个函数性能上有一点额外开销但在绝大多数业务场景里微不足道不用担心。箭头函数的优势是捕获当前渲染轮的 props 和 state语义清晰、不容易踩坑。4.2 事件对象和合成事件React 给每个事件处理函数传入的参数是一个合成事件对象SyntheticEvent它不是原生 DOM 事件但把常用属性和方法都封装进来了。比如event.preventDefault()、event.stopPropagation()、event.target.value这些原生 API 的常用操作在合成事件里用法一致。有一个重点必须记住React 的合成事件是复用的。事件处理函数执行完毕后合成事件对象会被回收重置。如果你在异步代码里比如setTimeout、fetch回调使用这个事件对象会拿到已经被重置的数据得到看似莫名其妙的 bug。假如你写了一个输入框要在防抖 500ms 后把值提交到后台function SearchInput() { const handleChange (e) { // 这里存的是值不是事件对象 const value e.target.value; setTimeout(() { // 错误示范直接用 e.target.value此时 e 已被重置 submitToAPI(e.target.value); }, 500); }; return input onChange{handleChange} placeholder搜索关键词 /; }正确做法是第一行先把e.target.value提取到局部变量里再在异步代码中用这个值。这不是什么高级技巧但几乎所有从 jQuery 时代转过来的人都在这个坑里栽过跟头。4.3 阻止默认行为和冒泡的正确姿势在表单提交、链接跳转这些场景里需要阻止浏览器默认行为。React 里的写法和原生 JS 类似但有一些微妙的差别。form onSubmit{(e) { e.preventDefault(); // 自行处理表单逻辑比如发送请求 }} input typetext namekeyword / button typesubmit提交/button /form这里我特别想提一个很多人忽视的点e.preventDefault()和e.stopPropagation()的生效范围。React 的合成事件绑定在根容器上stopPropagation()阻止的是同层级 React 事件之间的冒泡。如果你混用原生事件监听比如通过ref直接addEventListenerReact 的合成事件和原生事件的冒泡顺序会有差异有点绕。我的建议是一个项目里尽量统一用 React 的合成事件体系不要混着来除非你有非常明确的性能优化目标需要原生监听。5. 条件渲染与列表渲染React 中最常用的两大“招式”组件要干活的日常场景无非就是根据条件显示不同内容和把数据列表渲染成 UI。这两块用熟了基本就可以应付 80% 的业务页面了。5.1 条件渲染的三板斧React 没有像 Vue 那样内置v-if指令它的条件渲染完全靠 JS 表达式实现。常用的有这三种第一三元表达式。{isLoggedIn ? UserDashboard / : LoginButton /}这是最直白的写法二选一场景优先推荐。可读性最好语义清晰。第二逻辑与短路。{unreadCount 0 span classNamebadge{unreadCount}/span}适合满足条件才渲染不满足就不渲染的场景。它的原理很简单unreadCount 0为真时直接返回后面的 JSX为假时返回falseReact 忽略它什么都不渲染。这里有个经典小坑如果在前面放一个数字比如{count span.../span}当count是 0 时表达式的值是 0React 会老老实实把 0 渲染到页面上。你本意是count 大于 0 才显示结果页面上莫名多个 0。因为 0 在布尔判断里是 false但 React 渲染时只对false、null、undefined做忽略0 是会显示出来的。这就是为什么很多代码规范要求前面必须写成布尔表达式的原因。第三立即执行函数或者提前变量赋值。function StatusBanner({ status }) { if (status success) { return div classNamesuccess操作成功/div; } if (status error) { return div classNameerror操作失败/div; } return div classNameinfo请稍候/div; }多个分支条件时if/else是逃不掉的。这种结构清清爽爽比一堆嵌套三元表达式容易维护得多。我见过有人在 JSX 里写三层嵌套三元表达式缩进之后跟个金字塔一样读代码的人血压直接拉满。遇到这种场景拆出来写return往往更舒服。5.2 列表渲染的 key 到底是个什么说法列表渲染用map方法function TaskList({ tasks }) { return ( ul {tasks.map((task) ( li key{task.id}{task.title}/li ))} /ul ); }key是 React 用来追踪列表项身份的标识。列表项有增删、排序时React 靠 key 判断哪些元素是同一项、哪些是新建的、哪些该被移除。如果没有 key 或者用数组索引当 keyReact 只能通过位置去猜测性能会变差有时还会引发渲染错乱。我看过太多人直接把key{index}一写就完事而且完全意识不到有什么不对。我认真说一下如果列表是不变的、纯展示型数据用索引当 key 问题不大但如果列表项可以被增删、移动、或者内部有本地状态用索引会引发邪门 bug。用个具体场景举例一个可勾选的待办列表你用索引做 key勾选了第一项后来又删了第一项React 会基于位置做 diff第二项的内容被挪到第一项的位置但它的勾选状态是基于上一个 key遗留的于是界面出现勾选错乱。这件事我多年前第一次遇到时排查了好久最后发现就是 key 的问题。从那以后我写代码时 key 只用数据自带的 id、或者专门的标识字段绝不贪图省事用数组下标。5.3 渲染大列表时的一个性能思路如果列表特别长比如几百上千条每次状态变化整个列表都重新渲染性能会明显拉胯。这时候可以考虑把列表项封装成独立组件配合memo做浅比较优化。const TaskItem memo(function TaskItem({ task, onToggle }) { return ( li input typecheckbox checked{task.done} onChange{() onToggle(task.id)} / {task.title} /li ); }); // 父组件里 const handleToggle useCallback((id) { setTasks((prev) prev.map((t) (t.id id ? { ...t, done: !t.done } : t)) ); }, []); ul {tasks.map((task) ( TaskItem key{task.id} task{task} onToggle{handleToggle} / ))} /ulmemo的作用是如果传入的props和上次渲染时一样就跳过这次重新渲染。配合useCallback保持回调函数的引用稳定许多列表项就不需要白白再做一次 diff。这套组合拳是 React 性能优化里最常见也最实用的一招但初学者可以先有个印象不用急着全上。需要注意memo是浅比较如果 props 里有对象或数组每次父组件渲染都会产生新引用memo就失效了。所以真正稳定传下去的 props尽量用基础类型或者配合好useMemo。6. 组件通信与状态提升别再让数据“无家可归”组件多了以后最让人头疼的是数据放哪、怎么流。这里有几个重要的套路它们是 React 架构设计的地基。6.1 状态提升把数据放到最近的“公共祖先”如果两个组件需要共享同一份数据正确的做法不是让这两个组件自己各存一份副本而是把数据放到它们共同的父组件里通过 props 分发下去。这就是所谓的状态提升。举个例子一个搜索页面搜索框组件和搜索结果列表组件都需要关键词这份数据。如果两个组件各存各的就会出现一个改了另一个不知道的同步问题。把关键词存在父组件里搜索框通过 props 拿到值、通过回调函数上报修改意图列表组件通过 props 拿到最新的关键词去过滤这就是标准的状态提升。状态提升的核心是数据归属权越靠上组件之间的耦合越小。但也不要无脑把所有数据都提到顶层那样会让顶层组件变得臃肿。判断标准很简单——只有多个子组件真正共享的数据才需要提升组件私有的 UI 状态下拉框开合、弹窗是否显示就该留在组件内部。6.2 Context打破层层下达的“行政体系”props 逐层传递在小项目里没问题但组件层级深了以后中间层组件可能完全不关心某个数据却要帮忙一层层转发。这种透传写起来烦人改起来更烦人。这时候就可以用 Context 来跨层级传递数据。const ThemeContext React.createContext(light); function App() { return ( ThemeContext.Provider valuedark Toolbar / /ThemeContext.Provider ); } function Toolbar() { return ( div ThemedButton / /div ); } function ThemedButton() { const theme useContext(ThemeContext); return button className{btn-${theme}}Themed Button/button; }这个例子里ThemedButton不管身在何层直接拿到theme值中间组件完全不碰这份数据。Context 适合放那些全局性的数据比如当前登录用户、主题样式、语言包等。但这里必须泼盆冷水Context 不要滥用。它会让组件的复用性变差因为一旦用了useContext这个组件就依赖某个 Provider 存在。你把一个主题感知按钮放到别的项目里得连同 ThemeProvider 一起搬。很多团队把 Context 当状态管理工具用结果一个全局 Context 里塞了几十个字段任何字段变化都会导致所有消费组件重新渲染性能问题随之而来。状态管理是该用组件状态、还是 Context、还是第三方库如 Zustand/Redux得按场景权衡。6.3 组合优于继承组件复用的正确姿势初学者看了不少组件教程后容易冒出组件能用继承来复用吗的疑问。答案是不需要也不能。React 官方明说组件复用推荐用组合而不是继承。组合的模式说白了就是嵌套一个组件内部可以用另一个组件。React 组件天然的树状结构让组合变得极其自然。比如function Card({ title, children }) { return ( div classNamecard h3{title}/h3 div classNamecard-body{children}/div /div ); } function UserProfile({ user }) { return ( Card title{用户${user.name}} p邮箱{user.email}/p p城市{user.city}/p /Card ); }children就是父组件往子组件里传的插槽位。这种模式比继承灵活得多因为它体现的是拥有和包含的关系而不是是和等于的关系。我见过有人为了让一个按钮组件支持不同风格给它写了一大堆配置项 props结果每个 props 对应一种渲染分支代码异常臃肿。其实用组合的思路把不同风格的按钮直接作为子组件传入反而更清晰。7. JSX 进阶规则那些你逃避不了的细节基础打完之后还有几个 JSX 的细节值得单独展开。这些细节看似琐碎却在项目里长期影响代码质量和排错效率。7.1 一个根节点与 FragmentReact 组件的返回值必须有一个根节点包裹。早期 React 版本里你没法直接返回多个并列的 JSX 元素必须在外面包一层div或span。这导致一个问题每次为了结构正确页面 DOM 里多出一层无意义的嵌套。后来出了 Fragment 的写法就可以在不增加 DOM 节点的情况下包裹多个元素// 错误并列多个根节点 return ( h1标题/h1 p段落/p ); // 正确用 Fragment 包裹 return ( React.Fragment h1标题/h1 p段落/p /React.Fragment ); // 简写形式Fragment 还有语法糖版本 return ( h1标题/h1 p段落/p / );和/是 Fragment 的缩写写起来比完整写法顺手多了。唯一要注意的是如果需要给 Fragment 传 key比如在列表循环中使用的话就必须写完整的React.Fragment简写形式不支持 key。7.2 JSX 中的样式行内样式不是字符串原生 HTML 写内联样式是stylecolor: red; font-size: 14pxJSX 里则必须写成对象div style{{ color: red, fontSize: 14, marginTop: 8px }} 内容 /div注意最外层的大括号是 JSX 的传送门里面那个对象字面量才是样式对象。CSS 属性名要遵循驼峰命名font-size写成fontSizemargin-top写成marginTop。数值不带单位时React 会自动加上px某些属性如lineHeight、opacity、zIndex除外它们本身就是无单位属性。行内样式虽然方便但会带来性能问题组件反复渲染时每次都要创建新对象。建议把静态样式抽到 CSS 文件里行内样式只留给动态计算的值比如根据状态改变的颜色、宽度。7.3 受控组件 vs 非受控组件表单的两种哲学表单元素在 React 里是个特别的存在。默认情况下input、textarea、select这些元素用户输入会直接改变 DOM 值React 不感知。如果我们让 React 的 state 来驱动这些元素的值就会变成受控组件。function LoginForm() { const [username, setUsername] useState(); return ( div input typetext value{username} onChange{(e) setUsername(e.target.value)} / p当前输入{username}/p /div ); }这个例子里value是 state 的值onChange里更新 statestate 变化触发重新渲染渲染又回填到value。这个闭环让用户输入和页面显示永远同步。你是用 state 驱动表单的所以可以随时对输入值做校验、转换、联动处理。React 官方的推荐是大多数场景都用受控组件这也是我日常项目里的默认选择。非受控组件则是让 DOM 自己管理输入值React 只负责在需要时取个快照function SimpleForm() { const inputRef useRef(null); const handleSubmit (e) { e.preventDefault(); alert(输入内容${inputRef.current.value}); }; return ( form onSubmit{handleSubmit} input ref{inputRef} defaultValue预填内容 / button typesubmit提交/button /form ); }非受控组件适合极简场景你不需要实时知道输入值只要在提交那一刻取一下就行。用ref直接访问 DOM 节点省心省事。但它放弃了 React 对数据的掌控力所以功能一复杂起来就会捉襟见肘。我个人的经验是默认受控非受控只在你非常确定这个值的实时变化不重要时才用。7.4 转义、 dangerouslySetInnerHTML 与安全问题JSX 默认会对所有文本内容做转义这是 React 在安全设计上的一个重要防线。你写{someString}即使这个字符串里包含script标签React 也会把它输出为纯文本不会执行。但有些场景确实需要渲染 HTML 字符串比如后台返回的一段富文本。这时 React 提供了dangerouslySetInnerHTML这个接口div dangerouslySetInnerHTML{{ __html: htmlString }} /这个 API 的名字就自带警告它是强行关掉 React 的安全防护的意思。用之前务必确认这个 HTML 是你自己生成的、或者经过了严格的消毒处理。我处理过一个线上问题就是后台返回的富文本里有一小块带onerror的img攻击代码前端用dangerouslySetInnerHTML直接渲染结果脚本在用户浏览器里执行一顿操作猛如虎。从那以后凡是用户能编辑、能上传的文本走这个 API 前都先过一遍白名单过滤。8. 常见报错与排查技巧React 开发者的“避坑手册”没有哪个 React 开发者敢说自己从来没遇到过报错。下面这几个是实践里出现频率最高的我把排查思路和解决要点整理在了一起。8.1 “Adjacent JSX elements must be wrapped in an enclosing tag”这个报错通常在两个并列的 JSX 元素没有用根节点包裹时出现是初学者的初次见面礼。排查思路很简单看报错里指出的行号找到那个 return 下面的并列元素用 Fragment 或div包裹即可。但我有一次排查这类报错花了半小时原因是某个组件 return 里用了注释我把注释写在 JSX 外面了导致 React 解析时把注释也算成一个节点于是出现了并列结构。注释的正确位置是在大括号{/* */}里面这个问题视觉上很隐蔽要特别小心。8.2 “Uncaught TypeError: Cannot read properties of undefined (reading map)”这个报错十个里有八个和异步数据有关渲染时数据还没到data.map就执行了而data还是undefined。比如刚请求接口时数据字段是空的function ProductList({ products }) { return ( ul {products.map((p) ( li{p.name}/li ))} /ul ); }如果父组件在接口返回前把products传成undefined就会翻车。我自己的排查习惯是先确认数据源的初始状态然后用显式兜底{products?.map(...) // 可选链 // 或 {(products || []).map(...)}两种都可以前一种更简洁后一种语义上更明确。对于复杂的异步页面我还会在数据未就绪时渲染一个 loading 占位用户体验更好。8.3 “Each child in a list should have a unique key prop”这个报错 React 几乎是用把饭喂到嘴边的方式在调侃你。它说的就是列表渲染缺少 key 或者 key 重复。最常见的成因有两种忘了写 key或者 key 用了数组索引而列表中间发生过删除和插入导致索引对应关系错乱。看报错时不要只看是哪一行在 map要检查 map 出来后每个顶层元素有没有 key。如果你 map 里返回的是一个组件实例key 要写在这个组件实例上不是写在它的子元素上。8.4 状态更新了页面不变这是我收到的求助里排名前三的问题。最常见的成因是直接修改了对象或数组没有返回一个新引用。// 错误直接修改原对象React 感知不到 setUser((prev) { prev.name 新的名字; return prev; }); // 正确返回一个新对象 setUser((prev) ({ ...prev, name: 新的名字 }));React 的 state 更新靠的是引用比较只要引用没变它就认为数据没变不重新渲染。所以凡是涉及到对象或数组更新一定要记住创建新副本这个原则。数组的常见修改方式也需要按这个原则来新增用[...arr, item]删除用arr.filter(...)修改用arr.map(...)。刚开始不习惯多踩几次坑就能牢记在心。8.5 useEffect 里的死循环新手开始接触useEffect后会出现一种诡异现象页面疯狂刷新或接口疯狂请求。常见原因是在useEffect的依赖数组里传入了对象、数组等引用类型而这些引用每次渲染都会变化于是 effect 每次渲染都执行。function Profile({ userId }) { const [user, setUser] useState(null); useEffect(() { fetchUser(userId).then(setUser); // 如果依赖项是 user对象就会无限循环 }, [userId]); return div{user ? user.name : 加载中}/div; }排查思路是看 effect 内读取的所有外部变量确认依赖数组里列出的是稳定的、基础类型的值。如果确实需要在组件里定义一个依赖的对象可以用useMemo或useCallback稳定它的引用。这里面涉及 React 渲染和副作用时机的关系理解透了以后React 的状态逻辑会顺畅很多。9. 一套拿来即用的 React 项目代码组织建议学完语法和组件之后下一个实际问题是一个真实的 React 项目该怎么组织代码才能既好读又好改。9.1 目录结构的一个推荐分层很多初学者喜欢把所有组件堆在一个文件夹里文件多了以后就是一场灾难。我长期使用后觉得合理的一种分层思路是src/ components/ # 通用可复用组件 Button/ index.jsx style.css Modal/ index.jsx features/ # 业务功能模块 auth/ LoginForm.jsx authApi.js useAuth.js profile/ ProfileCard.jsx hooks/ # 自定义 Hook useDebounce.js useLocalStorage.js utils/ # 纯工具函数 format.js validate.js核心原则是通用组件和业务组件分开每个功能模块自己内部闭环组件、API、逻辑都在一起。这样要找人改登录功能时直接进features/auth/不用满项目找文件。我并不是说这是唯一正确的结构但它确实帮我避免了多次文件找不到、不敢动的尴尬时刻。9.2 组件编写的一个小清单写任何一个组件前先问自己几个问题可以让代码更干净这个组件的职责是否单一如果一个组件既负责展示用户信息又负责处理复杂的导出逻辑拆分可能更好。props 是否有默认值用defaultProps或在解构时赋值默认值避免 undefined 蔓延。数据获取和业务逻辑是否要和 UI 分离如果是自定义 Hook 可能是更合适的容器。有没有多余的中间状态如果某些状态能用现有 props 派生出来就不要额外存 state。比如一个显示全名的组件与其存firstName lastName拼接后的字符串不如直接由 props 里的两个字段派生出来。React 哲学里很重要的一条就是最小化状态凡是能算出来的就不要存。9.3 样式方案怎么选这个真叫百花齐放CSS Modules、Tailwind CSS、styled-components、Sass、普通 CSS。对新手来说我的建议是别在样式方案上纠结太久。无论是公司项目还是个人项目先选一个团队已经用的或者社区最主流的方案把精力放在组件和逻辑上。样式方案的迁移成本相对可控逻辑混乱才是真正的高成本。Tailwind 现在很火上手快样式内聚在类名里适合快速迭代和原型开发CSS Modules 更贴近传统 CSS 思维适合需要细粒度控制的场景styled-components 把样式写到 JS 里适合对主题化需求强的项目。就个人体验而言中小型项目用 Tailwind 或 CSS Modules 都很顺手大型项目有设计系统的话styled-components 或类似方案往往更灵活。千万别每天换方案朝着写完业务逻辑、样式不失控这个朴素的指标前进就行。10. 走向进阶从“会用”到“会设计”的桥梁基础语法、组件机制、JSX 规则都过了一遍接下来不是学更多 API 的时刻而是需要你建立设计意识的时刻。React 的上手曲线前端很平缓但中后段会突然陡峭起来这个陡峭感和 API 数量关系不大主要是心智模型问题。10.1 从对的状态管理到清晰的状态模型同样是写一个购物车初学者能跑资深者能撑住后续三个月的新需求。差别在哪状态建模。每次需要用useState时先问这个状态和别的状态是什么关系是独立的还是某个状态的派生值它能从服务端数据算出来吗还是说它本来就是一个独立的 UI 交互状态我会把项目里的状态分成几个类别服务端状态从接口获取的数据、客户端持久化状态本地存储的主题选择、UI 临时状态弹窗开合、派生状态由其他数据计算出来的展示文案。不同类型有各自的处理方式混在一起处理必然出问题。10.2 核心风险中的Hooks 规则在使用useState、useEffect、useContext这些 Hook 时有一个铁律只能在组件顶层调用 Hooks不能在条件语句、循环、嵌套函数里调用。原因是 React 靠调用顺序来记住每个 Hook 对应的 state。如果某次渲染时某个 Hook 因条件判断没被调用后面所有 Hook 的顺序都会错位state 就串了。这类 bug 不报错、不警告但表现诡异堪称隐形地雷。现代 React 有官方 lint 规则eslint-plugin-react-hooks可以自动检查这个约束。新项目建议直接把这个规则加进 ESLint 配置它会在你写错代码的第一时间高亮提醒省掉大量排查成本。10.3 学习路线上的下一站基础打完之后我建议按这个顺序往下走React Router多页面和路由跳转这也是实际项目绕不开的。状态管理方案从 useState 到 useReducer再到你想引入 Zustand 或 Redux Toolkit。网络请求如何组织 API 请求层如何处理 loading、error、success 三种异步状态。Next.js 或类似框架服务端渲染和全栈开发打通前后端协作。性能和测试React.memo、useMemo、useCallback 的适用场景以及基础组件的单元测试。每一步都去真实项目里做点东西。React 这门技术看看永远学不会动手踩坑才是最快的成长方式。回头总结一下我做 React 项目这几年的感受语法是皮组件是骨JSX 是肌肉。三者配合才能撑起一个完整的应用。刚开始磕磕绊绊很正常我到现在偶尔还会翻出文档确认某些 API 的细节。别急着追求一步到位先把手头的一个小页面写好、写稳再逐步扩大边界。遇到状态错乱、key 出问题这些经典 bug也不要打击自己的信心每个 React 开发者都在这条路上摔过无数次爬起来就真的把这条路走通了。
