JavaScript 中 null 在数据库交互中需严格区分语义：SQL NULL 映射为 JS null 而非 undefined，应显式判断 === null、避免隐式转换，统一空值处理策略并结合 TypeScript 类型标注确保类型安全。
JavaScript 中的 null 在数据库交互中常被误用或忽略，导致前端显示异常、逻辑错误甚至崩溃。关键在于：数据库字段允许为 NULL，而 JavaScript 的 null 与 undefined 行为不同，且多数 ORM 或驱动（如 PostgreSQL 的 pg、MySQL 的 mysql2）会把 SQL 的 NULL 映射为 JS 的 null，而非 undefined。处理时需明确区分语义、统一转换策略，并避免隐式类型转换陷阱。
明确 null 与 undefined 的语义差异
SQL 的 NULL 表示“未知值”或“缺失值”，对应 JS 的 null 更贴切；undefined 则多表示“未声明”或“未赋值”，不应混用。数据库返回的空字符串 ''、数字 0、布尔 false 都是有效值，不能因“假值”就转成 null。
- 读取数据后，不要用
value == null同时判断null和undefined，应优先用value === null - 向数据库写入前，若业务上“空”应存为
NULL，就显式传null；若字段不允许为空，应提前校验并抛错或提供默认值 - 避免在模型层自动把
null转成undefined，否则丢失了“数据库明确置空”的语义
后端 API 层统一做空值归一化
REST API 返回 JSON 时，可约定将数据库中的 NULL 统一转为 null（保持原样），但对敏感字段（如手机号、邮箱）可按需转为空字符串或特定占位符，前提是前端知晓规则。
- 使用 Express + pg 示例：查询后遍历结果对象，对已知可能为 NULL 的字段做映射：
user.phone = row.phone ?? ''（仅当业务允许空字符串） - 避免全局递归替换所有
null—— 比如时间字段为null表示“未设置时间”，转成''反而增加解析负担 - 配合 TypeScript 接口定义，让
phone?: string | null明确表达可空性，比phone?: string更准确
前端渲染与表单提交时主动处理
用户输入控件（如 <input type="text">）的 value 永远是字符串，即使为空也是 ''；而 select 的未选中项可能返回 '' 或 ''，需根据后端要求决定是否转 null。
立即学习“Java免费学习笔记（深入）”；
- 表单提交前，对“可为空”字段做显式转换：
data.phone = formData.phone || null（注意：不能用formData.phone ?? null，因为''是真值） - 渲染时，用
{user.phone ?? '未填写'}安全读取，避免user.phone.length报错 - 使用类如
class User { constructor({ phone = null }) { this.phone = phone; } }，让默认值语义清晰
ORM 与查询构造器中的注意事项
Sequelize、Prisma、Drizzle 等工具对 null 处理策略不同。例如 Prisma 默认将数据库 NULL 映射为 null，且字段定义含 ?（如 phone String?）即表示可空；而 Sequelize 的 allowNull: true 字段在实例中仍可能为 undefined，需查文档确认行为。
- 使用 Prisma 时，查询结果中
user.phone类型就是string | null，可直接解构使用 - 用 Knex 构造查询时，
.whereNull('phone')生成WHERE phone IS NULL，不可写作.where('phone', null)（会变成= NULL，永远为 false） - 批量更新时，避免用展开运算符无差别覆盖：
updateUser({...old, phone: newPhone})若newPhone为undefined，可能意外清空字段；应只传变更字段
