在 PostgreSQL 日常开发里，COALESCE 几乎人手必备，但用错的案例比比皆是。先说一个最基础的认知偏差：很多人以为把三列塞进一个 COALESCE 就能互相填补，结果发现它只是把多列压成了一列——字段结构直接塌了。这背后真正的陷阱是什么？往下看。
COALESCE 不能自动对齐多列空值，必须显式指定每列的回退逻辑
举个典型场景：你想在 SELECT 里保持原有三列结构，又想让每列各自有兜底值，很多人想当然写成 SELECT COALESCE(name, nickname, email), age FROM users。本意是“任一字段有值就显示”，结果只输出一个字段，其他列凭空消失——这不是 bug，而是 COALESCE 的本质：它只返回单个标量值，绝不会替你“对齐”多列。
- 正确做法是对每一列单独套一层 COALESCE：
SELECT COALESCE(name, '未知姓名'), COALESCE(nickname, name, '匿名'), COALESCE(email, '未绑定邮箱') FROM users - 回退链的顺序非常关键：比如
COALESCE(nickname, name, '匿名')表示优先昵称、其次用户名、最后兜底，颠倒了逻辑就全乱套 - 如果某列需要拿另一列做备选（比如 nickname 缺失时 fallback 到 name），必须显式写出该列名——COALESCE 不会跨列自动关联，别指望它聪明到能猜出你的心思
LEFT JOIN 后字段为空时，COALESCE 必须作用于具体别名或表前缀字段
多表联查是 COALESCE 最常用的场景之一：右表字段因为无匹配变成了 NULL，你需要给个默认值。但这里有个容易翻车的细节：COALESCE 不认“模糊引用”，必须明确告诉它从哪张表来。
常见错误：在两张表都有 status 字段时写 COALESCE(status, 'pending')，直接报错或返回意外值；或者漏写表别名导致语义歧义。要避开这些坑，记住这几条：
- 始终带表前缀：
COALESCE(t1.status, t2.status, 'pending') - 如果字段可能是空字符串而非 NULL，先用 NULLIF 洗一遍：
COALESCE(NULLIF(t2.phone, ''), t1.mobile, '暂无电话') - 别把 COALESCE 塞进 ON 或 WHERE 条件里试图影响连接逻辑——它只在 SELECT 投影阶段生效，不会帮你补行
聚合查询中用 COALESCE 填充空组结果，必须包裹聚合函数本身
空组（即某分组无数据）是另一个新手集中翻车的区域。有些人写成 COALESCE(amount, 0) 再 SUM，结果每行 NULL 先被转成 0 再求和，数值被严重放大；还有人对空分组期望自动补 0，结果依然没有行返回。
正确姿势很简单：把 COALESCE 包在聚合函数外面——COALESCE(SUM(amount), 0)。先聚合出 NULL（空组或全 NULL 列），再兜底。如果非要每个分组都存在（哪怕没数据也显示 0），必须配合维表或 GENERATE_SERIES 补行，单靠 COALESCE 做不到。
另外注意类型一致性：COALESCE(A VG(score), 0.0) 里的 0.0 必须是 numeric 类型，写成 0（整型）的话 PostgreSQL 可能拒绝隐式转换，直接报错。
COALESCE 参数类型不兼容时，PostgreSQL 会直接报错而非静默转换
MySQL 或 SQL Server 有时容忍弱类型混用，但 PostgreSQL 对类型极为严格。一旦参数类型无法统一，查询立刻失败，不会尝试隐式转成文本或数字。比如 COALESCE(created_at, 'never') 会报错 operator does not exist: timestamp with time zone = text；COALESCE(price, 'N/A') 因 numeric 和 text 不兼容直接中断。
唯一可靠的方式是显式转换：COALESCE(TO_CHAR(created_at, 'YYYY-MM-DD'), 'never') 或 COALESCE(price::TEXT, 'N/A')。避免在参数链中混用不同精度类型——smallint 和 bigint 通常可兼容，但 numeric(10,2) 和 integer 在某些上下文中可能触发警告。子查询作为参数时，务必确认它返回单值且类型确定，否则 COALESCE 无法评估。
最后再补充一个容易被忽略的点：COALESCE 的短路特性只对表达式求值起作用，不会改变 SQL 执行计划中的实际计算开销。如果某个靠前的参数是慢子查询，它每次都会执行——哪怕后面参数早该命中。所以把高命中率、低开销的字段放在最左，不是风格问题，而是性能必修课。
