API中不应返回undefined，因JSON不支持，实际传输的空值只能是null；null表示字段存在但为空，字段缺失则表示未定义或不适用，语义清晰可降低客户端容错成本。
在 API 设计中，undefined 和 null 不应混用，它们传递的语义完全不同——前者表示“字段未提供、未定义”，后者表示“字段存在但明确为空”。这个区别直接影响客户端如何解析响应、是否触发默认逻辑、是否需要报错或降级处理。
API 响应中该返回 undefined 还是 null？
严格来说，JSON 标准不支持 undefined：序列化时会被自动忽略（如 { name: undefined } → {}），所以真实 HTTP 接口里几乎**不会出现 undefined**。所有可传输的空值都必须是 null。
- 后端返回
"user": null→ 明确告知客户端：“用户数据查不到，但该字段本应存在” - 后端省略
user字段 → 客户端收到的 JS 对象中obj.user是undefined，语义是：“这个字段压根没发过来，可能前端没传 ID，或后端逻辑跳过了它”
何时用 null：表达“有定义，但为空”
当一个字段在接口契约中是可选但语义明确时，用 null 更安全、更易维护：
- 用户头像字段
avatar：存在但未上传 → 返回"avatar": null - 搜索接口的分页参数：
next_cursor已到末页 →"next_cursor": null，而非不返回该字段 - 关系型字段如
manager_id：当前员工无上级 → 显式返回"manager_id": null，避免客户端误判为“字段缺失需重试”
何时让字段缺失（即隐含 undefined）：表达“不适用或未参与”
适合那些仅在特定条件下才存在的字段，不强制要求客户端处理：
立即学习“Java免费学习笔记（深入）”；
- 错误响应中的
data字段：成功时存在，失败时直接省略，让response.data自然为undefined - 条件性扩展字段，如
extra_info：仅当include_extra=true时返回，否则不出现 - 权限隔离字段：普通用户看不到
salary，后端干脆不返回，而不是返回"salary": null（后者反而暴露字段存在）
客户端判断建议：优先用 ?? 而非 == null
现代 JS 应统一用空值合并操作符 ?? 处理两种空态，它只在 null 或 undefined 时生效，且语义清晰：
-
const name = user.name ?? '匿名用户'—— 安全覆盖字段缺失或显式为空 - 避免
user.name || '匿名用户'：若name是''或0也会触发默认值 - 避免
user.name == null：虽能同时捕获两者，但模糊了语义差异；仅在兼容旧环境且无需区分时使用
设计 API 时，关键不是技术能不能返回 undefined，而是你希望告诉调用方什么。用 null 表达“我确认这里没值”，用字段缺失表达“这事与你无关”。语义清晰，才能减少下游的猜测和容错成本。
