parseInt('') 返回 NaN 而非 0，因为空字符串不满足解析条件；正确做法是先 trim 判断空值再转 0，避免用 || 0 掩盖问题，注意 null/undefined 需初始化归一，区分展示兜底与数据语义。
input value 为空字符串时，parseInt 返回 NaN 而不是 0
很多人以为 parseint('') 会返回 0，结果在表单提交或计算逻辑里突然崩掉——它其实返回 nan，后续参与加减就会让整个结果变 nan。
根本原因是 parseInt 遇到空字符串、空白符或非数字开头时直接放弃解析，不兜底。
- 正确做法是先判断是否为空/空白：
value.trim() === ''，再决定是否转0 - 别依赖
parseInt(value) || 0：因为parseInt('0x10')是16，但parseInt('00')是0，而parseInt(' ')是NaN，|| 0会掩盖真实问题 - 如果业务只要整数，用
Number(value) || 0更直白；但注意Number('')是0，Number(' \t\n ')也是0，行为比parseInt更“宽容”
后端传 null 或 undefined，前端 value 绑定后显示为空但类型不是字符串
比如从接口拿到字段 amount: null，绑定到 <input v-model="form.amount">（Vue）或 value={this.state.amount}（React），输入框看起来是空的，但实际值是 null，不是 ''。这时直接调 parseInt 会得到 NaN，且 value.trim() 会报错。
- 初始化时统一做“空值归一”：
amount: data.amount ?? 0（推荐用空值合并操作符） - 不要等用户输完再处理：在数据进入表单状态前就转换，而不是在提交时才
parseInt - 如果必须保留原始类型（比如区分“未填写”和“填了 0”），那就用独立的
displayValue和rawValue两套字段，避免混用
用户删光输入内容后，onBlur 或 onChange 里没重置为 0
常见场景：用户输入 123 → 失焦 → 正常；再点进去全删 → 失焦 → 值变成 ''，但代码没拦截，导致后续计算出错。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 在
onBlur里检查：if (value === '' || value.trim() === '') { setValue(0); } - 别只在提交时校验：交互过程中就要保证状态干净，否则中间状态可能被其他 hook 或 computed 误读
- 注意防抖：如果用了防抖的
onChange，删空后立即失焦，可能触发两次（一次空值 onChange，一次 onBlur），要确保两者逻辑不冲突
数据库字段允许 NULL，但前端硬塞 0 导致语义丢失
比如“折扣金额”字段，NULL 表示“未设置折扣”，0 表示“明确设为 0 折扣”。前端一律转 0，后端就收不到“未设置”的意图了。
立即学习“前端免费学习笔记（深入）”；
- 先确认业务语义：这个字段是否需要区分“空”和“零”？如果是，前端就不该自动转
0，而应传null或保留undefined - 若 UI 上必须显示为
0（比如输入框 placeholder 或默认值），可用displayValue = rawValue ?? 0，但提交时仍传原始值 - 后端 API 文档必须明确定义每个字段对
null/0/''的处理逻辑，前端不能靠猜
空值处理从来不是“填个 0 就完事”，关键在分清哪里是展示兜底、哪里是数据语义、哪里是交互反馈。漏掉任意一层，都会在某个深夜的线上日志里看到 NaN 默默飘过。
