null是明确表示“本该有对象但为空”的主动赋值，非通用空值；混用undefined、依赖typeof判断、滥用初始化及api返回null均属误区，应按语义精准使用。
JavaScript 中 null 的使用误区，核心在于把它当成“通用空值”随意混用，或依赖 typeof 判断导致逻辑出错。它不是 undefined，也不是假值替代品，而是一个有明确语义的主动赋值行为——表示“本该有对象，但此刻为空”。用错场景，轻则默认值失效、属性访问报错，重则引发隐蔽的运行时异常。
null 和 undefined 混用
两者语义不同：undefined 是“未赋值”，null 是“已赋值为空”。常见错误是函数参数传 null 却期望触发默认值，结果默认值不生效：
- 函数定义
function greet(name = '游客') { ... } - 调用
greet(null)→ name 得到null，不是'游客' - 同理，
greet('')、greet(0)、greet(false)都不会触发默认值
正确做法：只在明确表示“此处应为对象但暂无”时用 null；变量刚声明未赋值、函数少传参、属性不存在等场景，自然得到 undefined，无需手动设。
用 typeof 判断 null 导致逻辑误判
typeof null === 'object' 是历史 bug，但影响真实代码。比如：
-
if (typeof data === 'object') { data.id }—— 当data = null时，条件为 true，但data.id报错 - 错误根源：把类型检查和存在性检查混为一谈
安全写法必须显式排除 null：
if (typeof data === 'object' && data !== null)- 更推荐直接用
if (data != null)（兼容 null/undefined）或if (data !== null && data !== undefined) - 现代项目可配合可选链
data?.id或空值合并data?.id ?? 'default'
初始化对象变量时滥用 null
声明对象变量时，有人习惯写 let user = null;，看似“占位”，实则埋下隐患：
- 后续若忘记赋值，
user.name直接 TypeError - 不如用
let user;（初始为 undefined），语义更准确，且与解构、默认参数天然兼容 - 真正需要“主动清空对象引用”时才设 null，例如：销毁大型对象前
cache = null;，协助 GC
组件状态管理中（如 React），也倾向用 undefined 表示“未加载”，用 null 表示“加载完成但数据为空”（如搜索无结果）。
API 响应中过度返回 null
后端常把缺失字段设为 null，前端直接消费易出错：
- 响应
{ user: null }，前端写response.user.name必崩 - 理想设计：后端对可选字段不做 null 填充，保持字段缺失（即 undefined 语义）；或统一用空对象/空数组代替 null
- 前端适配层应做标准化处理，例如封装 fetch 工具，将 null 字段转为 undefined 或默认值
不复杂但容易忽略：null 是一个信号，不是占位符；它的存在，应当是有意为之的设计决策，而非填补空白的惯性操作。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
