“Column 'xxx' in field list is ambiguous”是PostgreSQL和MySQL 8.0+在SQL解析阶段触发的硬性报错，表明数据库无法确定裸写列名xxx归属哪张表，必须用表别名（如u.id、o.id）显式限定，否则拒绝执行。
因为数据库在解析字段时根本没法判断你写的 id、name 或 created_at 到底属于哪张表——这不是警告，是直接拒绝执行的硬性报错。
“Column 'xxx' in field list is ambiguous” 是什么信号
这是 PostgreSQL 和 MySQL 8.0+ 的标准语法拦截，不是运行时异常，而是 SQL 解析阶段就失败。只要你在 SELECT、ON、WHERE、GROUP BY 或 ORDER BY 中裸写了多张表都有的列名（比如 id），数据库就会卡在这一步。
- 常见触发点：
SELECT id FROM users JOIN orders ON user_id = id—— 这里两个id都没带前缀，ON里的id更是完全无法定位 -
SELECT *在多表 JOIN 中基本等于主动求报错：MySQL 5.7+ 默认禁用，PostgreSQL 直接拒绝 - 应用层用
row["name"]取值时，实际拿到的是哪个表的name，取决于执行计划和字段顺序，毫无保障
ON 子句漏表前缀比 SELECT 更危险
ON 是 JOIN 的逻辑定义位置，这里字段解析失败不会提示“请加别名”，而是可能退化成笛卡尔积，或静默匹配到错误列。
- 错误写法：
ON user_id = id——user_id可能被解析为左表、右表甚至第三张隐式引入的表 - 正确写法：
ON u.id = o.user_id，左右两侧都必须显式带前缀，不能省略任一侧 - 如果字段名不一致（如
users.uid↔orders.owner_id），两边都得写全：ON u.uid = o.owner_id - 即使某字段当前只存在于一张表（如
orders.status），也建议加前缀——防止后续加表后突然崩
AS 别名不能解决结果集层面的冲突
很多人写 u.id AS id, o.id AS id，以为加了 AS 就万事大吉。其实多数客户端（psycopg2、JDBC）和 ORM（Django values()）只认最终列名字符串，两个 AS id 会被后一个覆盖，row["id"] 永远只返回右表的值。
- 真正安全的做法是用带上下文的别名：
u.id AS user_id、o.id AS order_id -
WHERE和GROUP BY中不能用SELECT里的别名——SQL 执行顺序是FROM → WHERE → GROUP BY → SELECT → ORDER BY，WHERE阶段根本看不到AS定义 - 子查询必须带别名：
SELECT * FROM (SELECT id, email FROM users) AS t，否则报Every derived table must have its own alias
最常被忽略的细节是别名拼错一个字母（比如把 o.order_id 写成 oo.order_id），错误往往不出现在那行，而是在后续引用该别名的地方才爆发，且报错信息可能指向完全无关的子句——这种延迟反馈会让问题排查成本翻倍。
