必须为JOIN中的SELECT字段加表前缀并用AS重命名，因多表同名列会导致歧义报错或结果不可控；ON子句也需前缀，NATURAL JOIN和省略AS均不可取。
SELECT * 必须被干掉，id、name、created_at 这类通用字段必须带表前缀并用 AS 重命名——这不是风格问题，是执行层面的硬性要求。
为什么 SELECT * 在 JOIN 里一定会崩？
多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）遇到多表同名列时会直接拒绝：column reference "id" is ambiguous；MySQL 5.7+ 默认禁用歧义 *；旧版 MySQL 虽能跑，但结果里只留最后一个同名列，且顺序不可控——row["name"] 取到的可能是 users.name 或 orders.name，完全看运气。
- 别信“我刚试了能跑”，加个字段、换环境、升级版本就挂
-
DESCRIBE users和DESCRIBE orders对比字段，手动确认重名项，比临时改 SQL 更快 - ORM（如 SQLAlchemy）可能自动加前缀，但原始 SQL 不会——别指望框架兜底
ON 子句漏表前缀，比 SELECT 冲突更危险
ON user_id = id 这种写法不是“少打几个字”，而是让数据库彻底失智。它无法判断 user_id 属于哪张表、id 是 users.id 还是 orders.id，轻则报错，重则退化成笛卡尔积或索引失效。
- 必须写成
ON u.id = o.user_id或ON users.id = orders.user_id - 哪怕某字段当前只存在于一张表（如
orders.status），也建议加前缀——防止后续加表后突然崩 -
NATURAL JOIN看似省事，实则更糟：它按同名列自动匹配，表结构一动（比如新增updated_at），行为就失控
用 AS 重命名不是可选，是唯一出口
SELECT u.id, o.id 可以执行，但结果集里两个列都叫 id，客户端解析时必然丢一个；SELECT u.id AS id, o.id AS id 在 PostgreSQL 和多数驱动里直接报错，MySQL 8.0+ 也会拒绝。
- 必须用语义化别名：
u.id AS user_id、o.id AS order_id、o.created_at AS order_created_at -
AS在列别名中不能省——u.id user_id虽语法允许，但易读性差，团队协作中容易漏看 -
WHERE和ORDER BY里不能用AS别名，因为 SQL 执行顺序是FROM → WHERE → GROUP BY → SELECT → ORDER BY，那些别名还没生成 - 想复用重命名逻辑，封装进子查询或视图：
(SELECT u.id AS user_id, o.id AS order_id FROM users u JOIN orders o ON u.id = o.user_id) t，外层直接用t.user_id
重复数据本身不是 bug，但混淆列名就是事故
一对多 JOIN 导致行数膨胀是正常行为，但列名冲突会让整个结果集不可信——你根本分不清 id 是用户 ID 还是订单 ID，name 是用户名还是商品名。这种模糊性在调试时难发现，上线后才暴露，修复成本远高于写 SQL 时多敲几个字符。
最常被忽略的一点：别名作用域仅限当前查询，AS 不改变原表结构，也不影响后续子句；而表别名（users u）必须全程贯穿 FROM、ON、SELECT、WHERE——漏一处，就等于没做。
