coalesce严格按参数顺序返回首个非null值，不支持隐式层级；所谓“多层级默认值”实为将业务优先级映射为参数排列，并需配合nullif处理空字符串、显式cast统一类型、限定字段名防歧义，且仅适用于select投影阶段。
COALESCE 本身不支持“层级”概念，它只是严格按参数顺序取第一个非 NULL 值；所谓“多层级默认值”，本质是把业务优先级翻译成参数排列顺序，再配合类型统一和空字符串清洗来实现。
COALESCE 参数顺序 = 业务优先级规则
你写的顺序就是执行逻辑，没有隐含的“智能降级”。比如用户昵称 > 真实姓名 > 邮箱前缀 > '访客'，就得写成：COALESCE(nickname, real_name, SUBSTRING(email FROM 1 FOR POSITION('@' IN email) - 1), '访客')。顺序错一位，结果就可能完全偏离预期。
- 字段名必须带表别名，避免
status在多表中歧义 - 子查询或函数调用可作为参数，但只要前面有非 NULL，后面根本不会执行——这点可用于控制副作用
- 不要假设空字符串
''会被跳过，它不是 NULL，COALESCE(NULL, '', 'fallback')返回的是''
空字符串和 NULL 必须分开处理
数据库里 '' 和 NULL 是两种完全不同的值，COALESCE 对前者照单全收。如果业务上认为两者都算“无效”，得先用 NULLIF 转换：
COALESCE(NULLIF(TRIM(phone), ''), NULLIF(TRIM(mobile), ''), 'not provided')
-
TRIM()防止前后空格干扰判断 - 每个字段单独套
NULLIF(col, '')，不能只在最外层包一次 - 如果字段本身是 NULL，
NULLIF(NULL, '')还是 NULL，不影响短路逻辑
类型兼容性不是“差不多就行”，而是硬约束
所有参数必须能被数据库推导出一个公共类型，否则 PostgreSQL 直接报错，MySQL 8.0+ 严格模式下也会失败。常见翻车点：
-
COALESCE(price, 0)：price 是 DECIMAL(10,2)，0 是整数，可能触发隐式升精度为 DECIMAL(10,3)，下游报表列宽突变 -
COALESCE(updated_at, '1970-01-01')：字符串字面量在 SQL Server 中转成 DATETIME，精度丢失，应写CAST('1970-01-01' AS DATE) -
COALESCE(name, 'N/A')：name 是 VARCHAR(50)，但'N/A'可能被推导为 VARCHAR(3)，导致视图定义固化长度，后续插入超长名被截断
WHERE 或 ON 里别用 COALESCE 做兜底逻辑
这是最容易被当成“优雅”实则埋雷的操作。例如：WHERE COALESCE(status, 'active') = 'active' 表面看覆盖了 NULL，实际让 status 列彻底无法走索引，全表扫描风险极高。
正确写法是显式拆解：WHERE status = 'active' OR status IS NULL。JOIN 条件中同理，ON COALESCE(a.id, b.fallback_id) = c.id 会破坏索引、让执行计划不可控，且语义混乱——NULL 值本就不该参与匹配。
真正需要“多层级缺省”的地方，几乎都在 SELECT 投影阶段；JOIN 逻辑和过滤逻辑，必须靠原始字段和明确条件来表达。
