必须统一声明表别名并全程使用，否则字段引用失效；主表、JOIN表均需显式别名，避免混用LEFT/INNER JOIN，跨前缀表必须用数组语法跳过前缀拼接，子查询须重命名字段。
JOIN 表别名没统一声明就开写，字段引用直接失效
只要表名没在 FROM 或第一个 JOIN 里显式声明别名，后续所有 ON、WHERE、SELECT 中的字段引用都会变成“猜谜游戏”。MySQL 可能侥幸跑通，PostgreSQL 和 SQL Server 会立刻报 Column 'id' in field list is ambiguous；更糟的是，某些旧版 MySQL 会静默取最后一个同名列，导致数据错位却无报错。
- 必须在每个
JOIN的第一个参数中写死别名，格式只接受两种：'users u'或['users' => 'u']（后者用于跳过 ThinkPHP 前缀拼接） - 主表也得加别名：
Db::table('users')->alias('u')后，所有字段必须写成u.id，不能裸写id - 别名缩写要一致且有意义：用
u就全程u.name，别中间穿插users.name或usr.name
LEFT JOIN 和 INNER JOIN 混用时别名被框架复用错乱
ThinkPHP 5.1 早期版本在连续调用 leftJoin() 和 join() 时，会错误复用前一个表的别名，导致 ON 条件里字段找不到所属表。比如先 leftJoin('orders o') 再 join('products p')，生成的 SQL 可能变成 ON o.user_id = p.order_id——但 o.user_id 根本不存在，因为 orders 表实际没被选中。
- 避免混用：要么全用
join()，要么全用leftJoin()；如必须混合，中间插入->where('1=1')断开链式调用 - 手动检查生成 SQL：
echo $query->buildSql();，确认每张表的别名在FROM、JOIN、ON三处完全一致 - 升级到 TP6 或手动改用原生 SQL，绕过框架 JOIN 解析逻辑
跨前缀表 JOIN 时字符串别名触发自动补前缀
当你要关联一张不带默认前缀的表（比如 so_lines_all），而数据库配置了前缀（如 fa_），ThinkPHP 会把 'so_lines_all e' 当成模型表，自动拼成 fa_so_lines_all 并报错 Table 'xxx.fa_so_lines_all' doesn't exist。这不是别名写错了，是字符串写法被框架当成“需补前缀”处理了。
- 必须用数组语法：
->join(['so_lines_all' => 'e'])，而不是字符串->join('so_lines_all e') - 所有非主表，只要前缀不一致，都得走数组写法；哪怕只是临时查一张系统表（如
information_schema.columns）也一样 - 别名本身不解决前缀问题——
'so_lines_all e'加了别名照样崩，只有数组才能跳过前缀拼接
子查询或视图里别名没重命名，外层一 JOIN 就崩溃
子查询返回两个 id 字段（比如 (SELECT id FROM users) u 和 (SELECT id FROM orders) o），外层再 JOIN，结果集就含两个未命名的 id。多数客户端（如 Python 的 cursor.fetchall()）只保留后一个，取值时 row['id'] 永远拿不到用户 ID。
- 子查询内必须重命名：
(SELECT id AS user_id, name AS user_name FROM users) u - 视图定义中
AS是强制的，否则 PostgreSQL/SQL Server 直接建失败，MySQL 虽建成功但字段名固化不可靠 - 别指望 ORM 自动修：Django 的
select_related或 SQLAlchemy 的joinedload默认不加前缀，上线前必须手检生成 SQL
FROM 开始声明，贯穿 ON、SELECT、WHERE、GROUP BY 全流程，且子查询、视图、ORM 输出都要各自独立处理。最容易被忽略的，是数组语法对前缀的绕过作用，以及混用 JOIN 类型时框架底层别名复用的黑盒行为。 
