1. 条件渲染不只是操作符这么简单
写 React 组件写了几年之后，我对“组件条件渲染”这件事最大的体会是：它表面上就是一直写if、三元、&&，但真正决定代码质量的东西根本不是语法本身，而是你在什么场景下选择哪种写法，以及你是否意识到每种写法背后藏着的坑。
任何一个 React 开发者，从第一天就在做条件渲染。列表页的加载 loading、空状态的占位、用户权限不同展示不同按钮、表单校验错误提示、弹窗的开合。这些都叫条件渲染。但很多人写了几个项目之后，代码里到处都是&&和三元运算符，遇到了 bug 也只想得到“加个判断试试”，却不知道为什么有时候界面显示了一个0，为什么切换条件之后组件内部状态被清空了，为什么同一个组件变量会在某些数据源下渲染到错误的 UI。
这篇文章我想从条件渲染的底层逻辑讲起，梳理我在实战中使用过、放弃过、后来重新审视图腾的所有写法，把每一种方案在什么场景下选型、会遇到什么运行时问题、怎么封装才能避免重复写烂代码，一次性说清楚。适合对 React 已经有一定基础、希望把代码质量和排错能力往上提一档的朋友，也适合那些被0 && <Component/>坑过、想知道来龙去脉的人。
条件渲染的本质，是把“UI 该渲染什么”这一个问题，拆解成“数据状态下如何映射到界面内容”。你有 N 种数据状态，UI 就有 N 种可能的分支，组件要做的就是在每次渲染时，根据当前状态选择正确的分支去执行。
这听起来再简单不过了，但实际项目里之所以会出现各种花式 bug 和难维护的代码，就是因为大家常常用“顺手”代替“合理”，用“能跑”代替“正确”，然后在一个不合适的层级写了一个错误的判断表达式。接下来的内容我会一层一层把这些事拆开。
2. 五种写法的适用场景与底层逻辑
条件渲染的写法搜一下能搜出来一堆，但核心无非就是if/else、三元运算符、&&短路运算符、switch枚举映射、以及把判断提炼成函数或组件的方案。很多人不明白为什么需要这么多种写法，其实不是写法多，而是每一种写法在可读性、表达式能力、分支数量、渲染时机控制上有不同的侧重。
2.1 大段落 if/else：函数体内的控制流
直接在组件函数内部写if/else是最朴素的做法。它适合的场景是：分支逻辑比较复杂、每个分支需要执行多行代码，或者需要在 return 之前做一些数据的预处理。
function OrderList({ orders, loading, error }) { if (loading) { return <Loading />; } if (error) { return <ErrorPage message={error.message} />; } if (orders.length === 0) { return <EmptyState />; } return <OrderTable orders={orders} />; }这种写法的优势在于直白，任何开发者一眼就能读懂组件的状态机。而且它是真正的控制流：一旦命中某个if分支，函数直接返回 JSX，后面的代码不再执行，这在理解上非常符合大脑的线性逻辑。
但它的劣势也很明显，它不属于 JSX 表达式，所以没法直接嵌入到return的 JSX 结构内部。你只能在函数体顶层用，更多的场景是配合提前返回的组件结构来使用。
我自己的习惯是：组件的外层状态判断，比如 loading、error、empty、normal 这种属于“页面级状态机”的，全部用if/else 提前返回来处理。因为这种状态互斥，而且每个分支往往有完全不同的 JSX 结构，提前返回可以让主逻辑（normal 状态）不被一堆嵌套的三元表达式污染。
2.2 三元运算符：内联双分支的首选
三元运算符解决的问题是在 JSX 内部、在表达式的行内做出二选一的渲染决定。
<div> {user.isVIP ? <VipBadge /> : <NormalBadge />} </div>它的价值在于可以把条件渲染作为表达式嵌入到任何 JSX 位置。这个能力是if/else不具备的，因为 JSX 内部的{}只能放表达式，不能放语句。
实际使用中我的选型标准很简单：如果分支只有两个，且每个分支的 JSX 不长，就用三元。如果分支数量超过两个，就尽量避免嵌套三元，因为三层以上的三元表达式在阅读上基本就是一场灾难。
// 这种代码就是替未来的维护者挖坑 {status === 'success' ? <Success /> : status === 'error' ? <Error /> : <Pending />}嵌套三元的问题不是技术上的，是认知上的。人类的短期记忆对嵌套结构的处理能力有限，你写的时候觉得清晰，两个月后回来看就是一场灾难。更好的替代方案是后面的枚举映射方案。
还有一个小细节：三元运算符可以作为return的表达式来写，这时候它的地位等同于条件返回，但要注意类型一致性。两个分支如果返回不同类型的 JSX 值，在某些 TypeScript 严格模式下会引发类型推导问题。
2.3 && 短路运算：最优雅也最容易翻车的写法
&&写法使用得非常频繁，它利用的是 JavaScript 逻辑运算的短路规则：如果左侧表达式为假，右侧根本不会执行，整个表达式返回左侧的值；如果左侧为真，返回右侧的值。
{user.isAdmin && <AdminPanel />} {loading && <Spinner />} {unreadCount && <Badge count={unreadCount} />}前两行在大多数情况下表现优雅、简洁、无负担。但第三行就是一个经典的坑。unreadCount如果是0，表达式返回的是0而不是false，React 在渲染时会把数字0直接渲染到页面上。于是界面上出现了一个孤零零的0。
这个 bug 很多人面试的时候背过答案，但没有真正理解它背后的机制。逻辑与运算是 JavaScript 的表达式语义，它忠实返回的是“左侧假值时它就是假值本身”还是“右侧值”，而不是帮你把结果统一转成布尔值。React 的渲染管线中，false、null、undefined会被忽略不渲染，但0和空字符串""是合法的渲染内容，会被输出到 DOM。
所以到了实际项目里，我习惯在&&左侧永远是布尔值，而不是可能为0的数字或者长度值。
{unreadCount > 0 && <Badge count={unreadCount} />} {list.length > 0 && <List data={list} />}这不仅仅是为了避免显示数字0，更是为了让代码的意图显式化。左侧的表达式本身就是明确的判断条件，读代码的人一眼就知道“你是在判断数组是否有数据”，而不是在猜list && <List/>中的list到底是数组还是空数组。
2.4 switch 与状态枚举：多分支映射的正确打开方式
当同一个状态变量有多个可能值，且每个值对应不同 UI 时，switch或者对象枚举映射是比嵌套三元合适得多的方案。
function OrderStatus({ status }) { const statusMap = { pending: <PendingTag />, paid: <PaidTag />, shipped: <ShippedTag />, completed: <CompletedTag />, cancelled: <CancelledTag /> }; return statusMap[status] ?? null; }这种写法把“状态到 UI”的映射关系做成了一个表格，清晰且易于扩展。以后加一个新的状态，只需要在statusMap里加一行。如果加一个状态后逻辑变了，虽然要处理映射关系，但整体代码的复杂度不会像嵌套三元那样指数上升。
?? null的作用是给意外状态一个兜底。如果后端返回了一个你没定义的状态，statusMap[status]是undefined，此时返回null是最安全的降级方案，避免页面直接崩掉。
使用对象枚举的另一个好处是它天然适合 TypeScript。给 statusMap 做类型标注后，拥有哪些状态的枚举、每个状态对应的组件是什么，全部在编译器层面有保障。
2.5 提炼函数与组件：消除重复判断的更高层抽象
如果你的条件判断不仅仅是渲染一个标签，而是涉及一段复杂的业务筛选逻辑——比如权限组合判断、多个字段同时参与的复杂条件——把这些判断提炼成纯函数，效能比放在 JSX 表达式里高得多。
function canEditOrder(order, user) { if (order.status !== 'pending') return false; if (user.role === 'admin') return true; if (user.id === order.creatorId && user.role === 'operator') return true; return false; } function OrderActions({ order, user }) { if (!canEditOrder(order, user)) return null; return <EditButton order={order} />; }这样做的核心收益是：把条件逻辑从渲染表达式中抽离出去后，它变成了纯业务逻辑，可以独立写单元测试，可以复用到其他组件，也可以在需求变化时单点修改判断规则而不触碰 UI 渲染逻辑。
更进一步，当一段需要判断的 JSX 分支结构很重、内部还嵌套了自己的状态逻辑时，直接把它拆成独立组件才是正道。
{hasPermission('export') ? <ExportPanel /> : <ApplyPermissionHint />}这里的ExportPanel和ApplyPermissionHint应该各自独立成组件，而不是在父组件里写一大堆内部嵌套。条件渲染的粒度越往组件层走，代码的复用性和可维性就越好，这也是 React 组件化思想的核心：把决策留在上层，把实现留给下层。
3. 进阶技巧：条件渲染与运行时正确性
条件渲染写对甚至比写出来难得多。很多人只关心“我该用if还是三元”，却忽略了一个更根本的问题：条件渲染的结果不仅取决于哪个分支被选中，还取决于 React 的运行时机制如何对比、复用、丢弃那些已经渲染过的组件实例。这个部分我集中讲几个从实际项目里踩出来的技巧。
3.1 动态组件与 defineComponent 模式
有一类常見需求是同一个位置，根据不同的配置渲染不同的组件。很多人会写成：
{type === 'text' ? <TextBlock /> : type === 'image' ? <ImageBlock /> : <VideoBlock />}这种写法的可维护性只比嵌套三元好一点点，而且扩展起来需要改动现有分支。换一种思路，把类型与组件的映射提升为配置表，然后动态渲染。
const blockRenderers = { text: TextBlock, image: ImageBlock, video: VideoBlock, chart: ChartBlock, }; function BlockRenderer({ type, data }) { const Component = blockRenderers[type]; if (!Component) return null; return <Component data={data} />; }这个模式的核心是const Component = blockRenderers[type]，你拿到的是组件构造函数本身，而不是组件实例。然后你就可以像使用普通标签一样<Component />去渲染它。这在 CMS 区块渲染、表单控件类型渲染、消息类型渲染这类场景中非常实用，扩展新类型只需要往配置表里加一项，不触碰渲染逻辑本身。
要注意一点：动态组件必须大写开头。小写开头的变量在 JSX 中会被当作原生 DOM 标签来解析，比如<component />会被渲染成 HTML 的<component>标签，然后浏览器就会一脸懵，因为根本没有这个标签。这是 JSX 语法本身的约定，与组件无关。
我在项目里踩过一次：配置表是后端下发的，前端用rendererMap[type]动态取值后直接<renderer />渲染，页面上什么都没有渲染，也没有报错，排查了半天才发现是大小写的问题。
3.2 条件渲染中的状态丢失问题与 key 的关键作用
条件渲染最容易让人困惑的现象之一是：切换分支后，组件重新渲染了，但它的内部 state 却“复活”了上一次的值，或者反过来，明明没做什么变化，组件状态却被重置了。这两种现象看似矛盾，其实都指向同一个核心机制：React 对组件的身份识别。
React 在协调（reconciliation）过程中，判断两个组件是否是同一个，靠的是组件类型和它在组件树中的位置。当条件表达式在同一个位置渲染不同类型的组件时，React 会卸载旧组件，挂载新组件，所以新组件内部的state是全新的初始值。
{isEdit ? <EditForm initialData={data} /> : <ReadOnlyDetail data={data} />}isEdit从false变成true时，ReadOnlyDetail被卸载，EditForm从零开始挂载，所有内部 state 自然是干净的。这个行为通常情况下正是我们想要的。
但问题出在同类型组件的复用上：
{isEdit ? <UserForm user={user} /> : <UserCard user={user} />}假设UserForm和UserCard内部都渲染了一个<input />，并且用户已经在输入框里输入了内容。当条件切换时，React 发现组件树中的<input />类型和位置都没有变化，就认为这是同一个输入框，会直接复用这个 DOM 节点并保留其内部状态。结果就是你从编辑态切换到展示态时，展示态的输入框里还残留着用户刚才编辑值。
解决这个问题的标准手法是key。给条件分支两端的组件加上不同的key，强制 React 认为这是两个完全不同的实例。
{isEdit ? <UserForm key="edit" user={user} /> : <UserCard key="view" user={user} />}这个技巧在 Tab 切换类的场景中尤其重要。不同的 Tab 如果内部有带状态的组件，如表格筛选条件、表单输入、滚动位置等，通常都需要通过key把它们区隔开。否则你会看到，“用户切到另一个 Tab 再切回来，上次填的东西还在”，这个现象可能被当成 bug，也可能在某些场景下又变成“误打误撞的需求”（比如切回来时表格应该保留筛选条件），但不管怎样，都应该由你来决定状态是保留还是重置，而不是交给 React 的复用机制随机裁决。
3.3 使用渲染函数代替 JSX 级别判断
有些复杂组件的条件判断会散落在 JSX 树的各个层级，那个组件就会变得又长又乱。一个实用的可维护性技巧是把局部渲染逻辑封装成组件内的方法或独立函数。
function Dashboard({ user, stats }) { function renderWelcome() { if (!user) return <GuestGreeting />; if (user.isFirstVisit) return <FirstVisitGuide />; return <WelcomeBack name={user.name} />; } function renderStatsArea() { if (stats.loading) return <StatsSkeleton />; if (stats.error) return <StatsError retry={refetch} />; return <StatsGrid data={stats.data} />; } return ( <div> {renderWelcome()} {renderStatsArea()} </div> ); }这种写法其实就是把大段的if/else逻辑从内联 JSX 中提取出来，让 JSX 变得更加扁平清晰。函数名本身就提供了自文档化的能力，阅读者不需要深入到 JSX 内部去推导条件分支的语义。
但也要提醒一点：这种函数如果是定义在组件内部的普通函数，每次渲染都会重新创建一个新函数引用。如果这个函数作为 prop 传给子组件，且子组件是memo包裹的，那 memo 的缓存就失效了，因为每次父组件渲染都会传入一个新的函数引用。
所以，如果你的渲染逻辑函数是纯函数、不依赖组件内部 state、不需要访问组件内部闭包变量，可以考虑把它提取到组件外部，或者在组件内部用useCallback缓存起来。实际项目里，我更倾向于把这种渲染函数提升到组件外部，作为纯函数使用，这样既减少组件体积，也避免引起子组件的重复渲染。
4. 条件渲染与性能：避免不必要的渲染开销
条件渲染的另一个维度是性能。很多 React 性能问题的根源并不在于组件渲染本身有多慢，而在于你触发了不该触发的渲染。条件渲染作为数据状态到 UI 的桥梁，天然就是渲染行为的决策点，怎么在这个决策点上减少无效的渲染，是资深开发者会刻意关注的地方。
4.1 useMemo 缓存条件计算结果
有些条件判断不是廉价的布尔比较，而是需要遍历数组、计算复杂对象、执行格式化或权限组合校验，这种计算放在 JSX 表达式里会随着每次渲染反复执行。如果这些计算本身并不依赖每次可能变化的数据，就可以用useMemo缓存结果。
const visibleRows = useMemo(() => { const query = searchKeyword.trim().toLowerCase(); return rows.filter(row => { return row.title.includes(query) || row.tags.some(tag => tag.includes(query)); }); }, [rows, searchKeyword]); { visibleRows.length > 0 ? <Table rows={visibleRows} /> : <EmptySearchResult keyword={searchKeyword} /> }useMemo的第二个参数是依赖数组。只有当rows或searchKeyword变化时才会重新计算。渲染过程中如果父组件发生了与这两者无关的重渲染，visibleRows直接复用上一次计算出来的数组引用，不需要再次过滤。
把这个计算缓存住，本质上是把“计算操作”和“渲染操作”解耦。你明确了这段计算只在依赖发生变化时执行，从而在数据量较大的场景下避免了无意义的循环过滤。
不过要泼一盆冷水：useMemo并不是银弹，它本身也需要开销（依赖比较、缓存读取）。如果条件判断只是一个简单的arr.length > 0、flag === true，那完全没有必要用useMemo，写了反而多了一层无意义的封装。只有计算代价明显高于 memo 本身的比较代价时，才值得引入。
4.2 结合 React.lazy 做组件级别的条件加载
条件渲染还有一个很容易被忽略的应用：按需加载。当你的应用体量变大，某些功能模块（比如管理后台的高级设置页、图表分析页）并不需要在首屏全部加载，就可以用条件渲染配合React.lazy实现真正意义上的“用到才加载”。
const AdvancedSettings = React.lazy(() => import('./AdvancedSettings')); function SettingsPage({ showAdvanced }) { return ( <div> <BasicSettings /> {showAdvanced && ( <Suspense fallback={<SettingsSkeleton />}> <AdvancedSettings /> </Suspense> )} </div> ); }只有showAdvanced为true时，AdvancedSettings这个组件才会被加载和渲染。React.lazy配合Suspense，在代码层面实现了模块的异步加载，切换条件时的加载过程由fallback里的占位内容覆盖。
这个写法极度推荐在路由级页面和后台管理系统中使用。把不常用的重型页面组件拆成独立的 chunk，显著减小首次打包体积和首屏加载时间。
条件渲染在这里扮演的角色，就是“加载开关”。它让组件的加载时机、渲染时机与用户的交互行为完全绑定。这不是一个炫技的优化，而是大型前端项目必备的基建手段。
4.3 shouldComponentUpdate 时代的遗产：React.memo 与条件渲染的关系
有一些团队还在大量使用React.memo来避免子组件的无意义渲染。这里有一个容易被误解的点：React.memo做的是渲染结果的缓存，它和条件渲染是并行的两回事。
const MemoizedChild = memo(ChildComponent); function Parent({ condition, data }) { return ( <div> {condition && <MemoizedChild data={data} />} </div> ); }父组件每次都重新渲染，但只要传给MemoizedChild的data引用不变、condition的值不变，MemoizedChild就不会重新执行。这里的条件是父组件级别的，子组件是否重新渲染由 props 比对结果决定。
在实际使用中要注意：React.memo是浅比较。如果你传给子组件的data是父组件里每次重新创建的对象字面量，即使内容一模一样，memo也会认为引用变了，进而重新渲染子组件。条件渲染本身并不会帮助你规避这个问题，你需要做的仍然是要么把数据引用稳定下来（useMemo或状态提升），要么调整 props 结构。
我的经验是：不要遇到性能问题就想着给所有组件包一层memo。先分析这个组件在正常交互中重新渲染几次、渲染的代价多大、是否因为频繁的父组件 setState 导致它被连带渲染。如果 90% 的渲染其实是无意义的，才考虑memo；如果组件本身就轻量，加memo反而增加维护认知负担。
5. 常见问题排查与实际避坑
条件渲染的坑其实高度集中，很多项目里出现的问题翻来覆去就那几个模式。我把这几年见过的实际案例整理了一下，按出现频率排了个序，每一个都配上具体的排查思路和修复方式。这部分的价值在于你踩过一次，以后看到症状就能直接定位问题，不用再花半天时间从头排查。
5.1 页面上出现一个 0 或空字符串
最经典的问题，没有之一。
{unreadCount && <Badge count={unreadCount} />} // unreadCount 为 0 时页面渲染 0 {keyword && <SearchTip text={keyword} />} // keyword 为空字符串时页面可能渲染空排查思路：如果你的页面某个角落莫名其妙出现了0或者一个几乎看不见的空白占位，优先怀疑&&左侧是否存在“假值但是非布尔”的情况。0、NaN、空字符串''都属于这一类。
修复方式是在&&左侧使用显式的比较表达式：
{unreadCount > 0 && <Badge count={unreadCount} />} {keyword.length > 0 && <SearchTip text={keyword} />}同时也提一个类似的坑：||右侧。value || <Fallback/>这种写法在value为0或空字符串时，会把0或空字符串本身渲染出来，而不是渲染Fallback。正确方式是value ?? <Fallback/>或者value !== '' && value !== null && ...。
5.2 条件应隐藏但副作用仍被触发
有一种很隐蔽的 bug：条件渲染后 UI 看起来正确，但某些副作用函数仍然在背后执行。比如：
{isOpen && <ChartModal token={token} />}如果isOpen为false，ChartModal不渲染，这个没问题。但如果ChartModal内部有useEffect在挂载时调用某个上报接口，这里的条件是“渲染时才会执行”，理论上没问题。那是什么场景出了问题？
答案是：JSX 中的表达式会被求值，即使最终没有被渲染。比如：
{hasPermission && <ExpensiveComponent data={computeExpensiveData()} />}computeExpensiveData()这个函数在hasPermission为false时也会被执行，因为 JSX 内部的所有表达式都在渲染阶段被求值了。条件渲染只是决定是否把结果渲染到界面上，但表达式的计算不会跳过。
这也是为什么复杂计算需要放进组件内部、用条件判断包裹，而不是直接写在 JSX 的花括号里。如果你的条件分支里有副作用或重量级计算，正确姿势是把判断提前到表达式求值之前：
let content = null; if (hasPermission) { const data = computeExpensiveData(); content = <ExpensiveComponent data={data} />; } return <div>{content}</div>;5.3 切换条件后 DOM 元素复用引发的残留
前面提到过key的问题，这是最容易被忽视、也最容易让开发者困惑的一类问题。具体表现是：同一个位置的输入框，在条件切换后没有清空内容；Tab 切换回来时表格还保持着上次的状态，而需求是希望切回来时回归默认状态。
如果你确认了这是状态残留，排查的路径是这样的：
先检查条件分支的组件类型和位置是否相同。如果两个分支最终都渲染了一个类型相同的组件（比如都是一个input或者都是一个Table），那 React 就极有可能复用它们。给分支外层包一个不同的key是最简单直接的解法。
<div key={activeTab}> {activeTab === 'list' ? <OrderTable /> : <OrderChart />} </div>这里key加在父级div上，整个容器会被视为不同的节点，React 会卸载整个子树再重新创建。
需要警惕的是key加得过于粗暴也会带来副作用，比如宝贵的组件内部状态被完全清空，如果那个状态正好是你希望跨条件保留的，那就会适得其反。所以改动之前务必想清楚你的业务到底需要哪一种行为。
5.4 条件渲染时报错：组件不是一个函数
有一种运行时错误会莫名出现：“Element type is invalid: expected a string or a class/function but got: object”。排查方向里有一个很常见的原因是动态组件渲染时的取值错误。
比如：
const blockRenderers = { text: TextBlock, image: ImageBlock, }; function BlockRenderer({ type }) { const Component = blockRenderers[type]; return <Component />; }如果type传进来的值是'TEXT'或者'text '（带空格），blockRenderers[type]就是undefined，然后你尝试渲染undefined，React 就会报这个错。此时正确姿势是加上兜底判断：
const Component = blockRenderers[type]; if (!Component) return null; return <Component />;5.5 渲染条件与数据异步更新不同步
最后一个常见问题出现在异步数据场景。很多新人会这样写：
function Profile({ userId }) { const [user, setUser] = useState(null); useEffect(() => { fetchUser(userId).then(setUser); }, [userId]); return user ? <UserProfile user={user} /> : <Loading />; }这段代码本身没问题，但它在userId快速变化时会出现陈旧数据的问题：如果你从userId=1切到userId=2，上一次请求可能比下一次请求晚返回，导致user最终被设置成前一个人的数据。
常规解法是清除过期请求的状态，比如使用一个标识符：
useEffect(() => { let cancelled = false; fetchUser(userId).then(data => { if (!cancelled) setUser(data); }); return () => { cancelled = true; }; }, [userId]);条件渲染在这里的体现在于：你其实是在“有数据”和“无数据”之间做条件切换。如果数据本身是过期的，那渲染出来的也就是过期的 UI。这也是条件渲染的边界条件之一——不要只关心“什么时候渲染什么”，还要关心“渲染的输入数据是否是当前上下文一致的最新数据”。
6. 我从条件渲染演进中看到的 React 设计思路
从函数组件的角度重新审视条件渲染，会发现 React 本身对“条件”的处理不是简单地在语法层给你几个操作符，而是把“条件的判定”与“UI 的表达”分别摆在两个层面：render阶段求值、提交阶段真实操作 DOM。这个设计决定了你的条件渲染写法如何影响真实渲染结果。
React 18 之后新增的并发特性，对条件渲染的影响比很多人感知到的要大。并发渲染下，React 可能提前准备 UI 但未必马上提交它。如果组件在准备阶段读取了外部状态，然后提交时那个状态又变了，React 会丢弃准备阶段的渲染结果，重新渲染一次。这对你的条件渲染代码是透明的，你不需要让它适配并发模式，但你要理解一个原则：条件渲染的判定必须以提交时为准，而不是以某个时序阶段的快照为准。因此你的条件判断反复依赖同一个数据源、且那个数据源可能存在多个不一致的副本时，要格外小心。
还有一个方向值得关注：React 编译器（自动记忆化）的出现会改变我们手动优化条件渲染中计算的方式。未来编译器会帮你自动完成一部分useMemo的工作，但条件渲染本身的语义、对组件身份的控制、对 key 的使用，依然需要开发者理解原理。工具可以优化内存化，但无法替你决定业务上的条件逻辑是什么。
作为一个写了多年 React 的开发者，我个人体会最深的一点是：条件渲染的代码质量，基本能反映一个人对 React 运行机制的理解深度。写操作符不难，写对场景、写对边界、写到自己和队友都看得舒服，才是真正的经验所在。如果你在工作中遇到条件渲染相关的疑难问题，不妨回头从“表达式会被求值吗？”“React 会复用这个节点吗？”“数据源和条件是否一致？”这三个角度去审视，大多数问题都能快速定位。
