ZCode 中的 React 条件渲染规范：用显式三元表达式替代 ``，杜绝渲染出 0 与 NaN-育师

人工智能
大模型
代码智能体
AI Agent
桌面应用
后端
前端
CLI

【免费下载链接】ZCode

ZCode 是 AI 编程工作台，提供桌面应用、浏览器界面和终端 Agent。本仓库包含客户端、后端服务、共享 UI，以及 Agent CLI 与运行时源码。

本文面向在 ZCode（AI 编程工作台）仓库中编写、评审或重构 React 组件的开发者与 AI Agent，讲解一条来自 Vercel Engineering、被收纳进仓库技能体系.agents/skills/react-best-practices的渲染层规则：当条件可能是0、NaN等可渲染的 falsy 值时，必须用显式三元表达式（? :）替代&&做条件渲染。读完本文，你将掌握 JSX 中 falsy 值的渲染语义、&&条件渲染的典型踩坑场景，以及一套可复制、可测试的正确改写方案，并看到它在 ZCode 自身 UI 源码中的实际印证。

规则速览：一条来自 Vercel 的渲染性能规范

本规则对应仓库中的规则文件 rendering-conditional-render.md，其 frontmatter 定义如下：

title：Use Explicit Conditional Rendering
impact：LOW
impactDescription：prevents rendering 0 or NaN
tags：rendering, conditional, jsx, falsy-values

这条规则隶属于.agents/skills/react-best-practices技能包。根据 SKILL.md，该技能包由 Vercel Engineering 维护，按影响级别对 70 条规则进行了 8 大类排序，其中第 6 类Rendering Performance（渲染性能）的默认影响级别为 MEDIUM，文件前缀为rendering-，本规则即归入此类；而 AGENTS.md 作为"合并参考文档"（combined reference），在第 6.9 节完整收录了与规则文件完全一致的正文内容。也就是说，规则文件是"单条规则的详细解释"，AGENTS.md 是"全部规则展开后的合订版"，两者必须保持同步（README.md 中明确要求：修改任一规则时，需同步更新其单文件与合订版中的对应章节）。

单条规则的文件结构由 rules/_template.md 约定：frontmatter（标题、影响级别、影响描述、标签）+ 规则说明 + 错误示例 + 正确示例；所有规则再按 rules/_sections.md 定义的分区（Eliminating Waterfalls / Bundle Size Optimization / Server-Side Performance / Client-Side Data Fetching / Re-render Optimization / Rendering Performance / JavaScript Performance / Advanced Patterns）组织。

需要强调的是，这条规则的影响级别虽是 LOW（属于"增量优化"层级），但它的失败模式——界面上凭空出现一个0或NaN——是用户肉眼可见的 UI 缺陷，修复成本极低、收益非常直接，因此适合在代码评审与自动重构中优先落地。

为什么`&&`条件渲染会把 0 和 NaN 渲染出来

要理解这条规则，先要理解 JSX 对"表达式作为 children"的渲染语义。当你在{expression}中放入一个值时，React 会按照如下规则决定是否渲染：

表达式结果	渲染结果
`true`	什么都不渲染（有效 child，但无输出）
`false`	什么都不渲染
`null`	什么都不渲染
`undefined`	什么都不渲染
`""`（空字符串）	无可见输出
`0`	渲染字面量`0`（问题所在）
`NaN`	渲染字面量`NaN`（问题所在）
对象 / 数组	渲染其内容

关键在于：0和NaN都是 falsy 值，但 React 并不会像对待false/null/undefined那样把它们当作"无输出"跳过——它们会以文本节点的形式真实出现在 DOM 中。于是，经典的&&短路表达式就产生了漏洞：

{count && <span>...</span>}

当count为真（如 5）时，表达式返回<span>，正常渲染；当count为0时，表达式返回0这个数值本身，React 便把它作为文本渲染出来——界面上多了一个孤零零的0。

这还不是唯一场景。NaN同样危险：任何"未定义算术结果"都可能产生NaN，比如0/0、parseInt('')、'a' - 1等，一旦它出现在&&左侧，界面上就会渲染出NaN字样。

另一个高频踩坑点是数组长度判断：

{items.length && <p>{items.length} items</p>}

当items为空数组时，items.length等于0，界面会渲染出0而不是预期的空内容——这是列表页最常见、也最容易被忽视的 bug 之一。

错误示例逐行解析

规则文件中的错误示例正是上面说的场景，直接引用如下：

function Badge({ count }: { count: number }) { return <div>{count && <span className="badge">{count}</span>}</div>; } // When count = 0, renders: <div>0</div> // When count = 5, renders: <div><span class="badge">5</span></div>

逐行分析：

count是number类型，其取值范围天然包含0，而0是 falsy 值；
count && <span>...</span>在count = 0时短路返回0，JSX 将其渲染为文本节点<div>0</div>；
只有当count为真值（如 5）时才返回<span>，渲染出预期的徽标。

这里还隐含一个容易被忽略的点：即便你明确知道"count 不会是 0"，只要组件对外接受number类型的 props，它的调用方就可能传入0或计算得出0。条件渲染的写法必须对类型定义内的所有合法取值都安全，而不是只对"我设想中的取值"安全。

正确写法：显式三元表达式

规则给出的正确写法如下：

function Badge({ count }: { count: number }) { return <div>{count > 0 ? <span className="badge">{count}</span> : null}</div>; } // When count = 0, renders: <div></div> // When count = 5, renders: <div><span class="badge">5</span></div>

要点拆解：

用显式布尔比较count > 0代替隐式真值判断：布尔表达式的结果只有true/false，而这两个值在 JSX 中都不会产生可见输出，天然安全；
两个分支都显式给出：真分支返回<span>，假分支返回null（也可以返回false或undefined），杜绝了"表达式自身作为渲染内容"的路径；
语义更精确：count > 0还顺带表达了"只有当 count 为正数时才显示徽标"的业务意图，可读性优于模糊的count &&。

需要指出的是，这条规则并不要求把所有&&一律改写成三元——它的适用前提是"条件可能为0、NaN或其他会被渲染出来的 falsy 值"。这正是其 impactDescription 写prevents rendering 0 or NaN的原因。

在 ZCode 仓库 UI 源码中的印证

这条规则并非纸上谈兵——在 ZCode 的 React 前端（packages/ui）中，可以同时看到"安全用法"与"应避免的隐患模式"两类代码。

安全用法的例子（左侧是对象、布尔值，不会渲染出意外内容）：

conversation.tsx 中的{icon && <div ...>{icon}</div>}与{description && <p ...>{description}</p>}——icon是元素/对象、description是字符串，均无渲染0的风险；
prompt-input-buttons.tsx 中的{shortcut && <span ...>{shortcut}</span>}——shortcut为字符串或 undefined，安全。

而像{count && <span>{count}</span>}这类"数值直连&&"的写法，在仓库中一旦出现就属于需要按本规则改写的反模式——尤其当它出现在徽标、计数、进度这类以数字为核心的 UI 上时。从源码结构看，ZCode 将这份 Vercel 规范以技能（skill）形式收纳进.agents/skills/react-best-practices，正是为了让 Agent 在生成新组件、评审既有代码时自动套用此类规则，从源头避免0/NaN渲染缺陷。

如何在 ZCode 项目中应用这条规则

按照 SKILL.md 的定义，该技能会在"编写新 React 组件、评审代码性能问题、重构既有 React/Next.js 代码、优化包体与加载时间"时被触发。落地方式建议如下：

评审时对照检查：在.tsx/.ts文件中用正则（如\{[\w.]+\.length\s*&&、\{[\w.]+\s*&&\s*<）定位可疑的&&条件渲染，逐一确认左侧操作数是否可能为0/NaN；
改写时套用模板：按 rules/_template.md 的"错误示例 + 正确示例"结构，把数值条件改写为显式布尔比较 + 三元表达式；
保持文档同步：若你修改了规则文件本身，务必同步更新 AGENTS.md 中第 6.9 节对应内容（README 中明确要求两者一致）；
理解定位后理性取舍：本规则影响级别为 LOW，属于低成本、易自动化的增量优化；当条件操作数确定是对象/布尔值时，保留&&并不违反规则。

小结

{count && <span>...</span>}这类写法之所以是反模式，根源在于 JSX 对 falsy 值的渲染语义存在不对称性：false/null/undefined不渲染，而0/NaN会被渲染成可见文本。ZCode 仓库中收纳的 Vercel React 最佳实践技能将"使用显式条件渲染"固化为一条独立的 LOW 影响级规则，给出了count > 0 ? <span>...</span> : null的标准改写方案。在编写、评审任何以数字为条件的 React 组件时，先写出显式布尔比较，就能从根上杜绝0与NaN出现在界面上的隐患。