必须为每个可能冲突的字段显式加表前缀并重命名，只靠AS不写前缀等于没做，因为多表同名列在结果集层面会被覆盖或报错，WHERE/ON等子句无法识别SELECT中定义的别名，且跨数据库兼容性差，唯有全程统一使用带前缀的原始名或通过子查询/视图隔离作用域才能彻底规避歧义。
必须为每个可能冲突的字段显式加表前缀并重命名，只靠 AS 不写前缀等于没做。
为什么 SELECT u.id AS id, o.id AS id 依然报错或取值错乱
多数数据库（如 PostgreSQL、SQL Server）和客户端（psycopg2、JDBC）在结果集层面只认列名字符串。两个 AS id 会被视为同名列，后一个覆盖前一个——最终你拿到的 row["id"] 永远是右表的值，且无法预测顺序。
- MySQL 5.7+ 默认拒绝这种写法，直接报
Column 'id' in field list is ambiguous - 即使 MySQL 8.0 允许执行，
fetchall()返回的元组里也只剩一个id字段 - ORM（如 Django 的
values()）会因字段名重复而抛出FieldError
WHERE 和 ORDER BY 中不能用 SELECT 里的别名
SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT → ORDER BY，WHERE 阶段根本看不到 SELECT 里定义的 AS 别名。
- 错误写法：
SELECT u.id AS user_id FROM users u WHERE user_id = 123→ 报Unknown column 'user_id' in 'where clause' - 正确写法：
WHERE u.id = 123或WHERE users.id = 123 -
ORDER BY虽然标准 SQL 允许用SELECT别名，但跨数据库兼容性差；更稳妥的是统一用u.created_at或序号（如ORDER BY 2），但后者易随字段增减失效
ON 条件里漏表前缀比 SELECT 更危险
ON 是 JOIN 的逻辑核心，这里字段解析失败不会“默默跳过”，而是直接中断或退化成笛卡尔积。
- 错误写法：
ON user_id = id→ 若users和orders都有id和user_id，数据库无法判断左右归属 - PostgreSQL 直接报
column reference "user_id" is ambiguous - MySQL 可能隐式匹配，但一旦字段类型不一致（如
BIGINTvsINT），索引失效，查询变慢数倍 - 正确写法：
ON u.id = o.user_id，两边都带前缀，无歧义
嵌套查询或视图是唯一能“隔离”别名作用域的方式
子查询或视图内部完成重命名后，外层看到的只有已处理过的字段名，彻底规避作用域混乱。
- 子查询示例：
SELECT * FROM (SELECT u.id AS user_id, o.id AS order_id FROM users u JOIN orders o ON u.id = o.user_id) t WHERE t.user_id > 100 - 视图创建时
AS是强制的：CREATE VIEW user_orders AS SELECT u.id AS user_id, ... - 注意：视图字段名以定义时为准，后续基表改名不影响视图输出结构
最常被忽略的一点：别名不是“写一次就完事”的装饰，它必须贯穿整个查询的所有子句——SELECT、ON、WHERE、GROUP BY、ORDER BY 全部要同步更新，漏掉任意一处都可能让前面的重命名白费功夫。
