JavaScript中慎用null，推荐使用undefined

在JavaScript现代开发中，应优先使用undefined而非null，因为undefined语义更自然（表示“未定义”或“缺省”）、与TypeScript类型系统深度契合（可选属性、解构默认值等均默认基于undefined）、运行时行为更一致且不易引发隐式错误；而null仅应在必要场景下谨慎使用——如遵循后端API规范、适配DOM原生返回值，或需明确区分“未设置”与“已清空”的业务状态。这并非教条禁令，而是兼顾语义清晰性、工具链支持和工程健壮性的务实实践。

在JavaScript现代开发中，应尽量避免显式使用 null，优先使用 undefined，但这不是绝对的教条，而是基于语义清晰性、工具链支持和运行时行为的一致性所作的实践建议。

语义上：undefined 表示“未定义”，null 表示“有意为空”

JavaScript 中 undefined 是语言原生的初始值：变量声明未赋值、函数无返回、对象属性不存在、函数参数未传入时，都会自然得到 undefined。它代表“此处本该有值，但还没给”。
null 则是开发者主动赋的值，语义是“这里明确地什么都没有”。但在实际工程中，这种区分常被模糊处理，导致类型判断混乱（比如 typeof null === 'object' 这个历史 bug 仍影响类型推导）。

• 用 undefined 表示“缺省”更符合语言直觉，TypeScript 的可选属性、解构默认值都默认与 undefined 对齐
• 若用 null 表示空状态，需在整个团队约定并严格贯彻，否则容易出现 null 和 undefined 混用、双重检查（val == null）等反模式

TypeScript 类型系统更友好地支持 undefined

TypeScript 默认开启 strictNullChecks 后，null 和 undefined 不再自动属于所有类型的子集。此时：

• 可选属性（name?: string）、可选参数、解构默认值，底层类型都隐含 | undefined
• 若强行用 null 替代，需反复写 | null，增加冗余；且 null 无法像 undefined 那样被解构默认值语法（{ name = 'anon' } = obj）自然捕获
• 现代库如 React、Zod、tRPC 等也倾向用 undefined 表示缺失值，与 TS 生态对齐更顺滑

运行时行为：undefined 更“安静”，null 更易暴露问题

两者在松散相等（==）下都等于 false，但严格相等（===）和类型操作表现不同：

• JSON.stringify(null) 得到 "null"，而 JSON.stringify(undefined) 在对象中会被忽略，在数组中变成 null —— 容易引发序列化不一致
• String(null) === 'null'，String(undefined) === 'undefined'，若用于日志或展示，语义泄露风险更高
• 现代 linter（如 ESLint 的 no-null 规则）和代码生成工具（如 OpenAPI 客户端）普遍将 null 视为需显式处理的异常路径，而把 undefined 当作自然控制流的一部分

何时可以/应该用 null？

并非完全禁用 null，关键看是否带来明确语义增益：

• 与后端 API 协议强约定时（如 Swagger/OpenAPI 明确某字段可为 null），前端保持一致可减少转换层
• DOM API 原生返回 null（如 document.getElementById()），直接沿用比转成 undefined 更合理
• 需要区分“未设置”和“明确清空”两个状态时（例如表单编辑器中，value: undefined 表示未碰过字段，value: null 表示用户点了“清空”），这时 null 是有意义的业务信号

今天关于《JavaScript中慎用null，推荐使用undefined》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！