laravel 的 where 无法作用于 as 定义的字段别名，因 sql 执行顺序为 from→where→select，where 阶段别名尚未生成；正确做法是用 whereraw 重写拼接条件或拆解为原字段查询。
直接说结论：Laravel 的 where 无法直接作用于 SQL 中用 AS 定义的字段别名，因为别名在 WHERE 执行之后才生成 —— 这是 MySQL（及绝大多数 SQL 引擎）的执行顺序决定的，不是 Laravel 的限制。
为什么 where('full_name', 'like', '%john%') 在 SELECT CONCAT(first_name, " ", last_name) AS full_name 后不生效？
SQL 执行顺序是：FROM → WHERE → GROUP BY → SELECT → ORDER BY。也就是说，WHERE 子句运行时，full_name 这个别名根本还不存在，数据库只认原始字段（如 first_name、last_name）。Laravel 的查询构造器生成的 SQL 遵循这个规则，所以你在 selectRaw() 里加了 AS，再对那个别名调用 where()，实际发出的 SQL 会报错或查不到结果（取决于是否开启严格模式）。
搜索带拼接字段的正确做法：用 whereRaw() 或 HAVING
想按“全名”模糊搜索，必须把条件写进 SQL 表达式本身，而不是当成普通字段名处理：
- 用
whereRaw()直接拼条件：适用于 WHERE 阶段能完成的逻辑（比如拼接后 LIKE） - 用
havingRaw()：仅当已使用GROUP BY且需对聚合/别名字段过滤时才适用；单纯拼接字段不用它
示例（搜索全名含关键词的用户）：
$users = User::selectRaw('CONCAT(first_name, " ", last_name) AS full_name')
->whereRaw('CONCAT(first_name, " ", last_name) LIKE ?', ["%{$keyword}%"])
->get();
注意：whereRaw() 中重复写了拼接逻辑 —— 这是必须的，不能偷懒复用别名。也别用 DB::raw() 包裹参数值，否则会被当字面量处理（导致 SQL 注入风险或匹配失败）。
更安全灵活的替代方案：用 whereBetween、orWhere 拆解条件
如果拼接逻辑复杂（比如要处理 NULL、多字段、空格清理），硬写 whereRaw 易出错且难维护。推荐拆成多个原生字段条件：
- 用
where('first_name', 'like', "%{$keyword}%")ORwhere('last_name', 'like', "%{$keyword}%") - 或更精准地：用
whereRaw("(first_name LIKE ? OR last_name LIKE ?)", [$kw, $kw]) - 若必须保证“全名中连续出现”，且字段非空，可考虑
whereRaw("CONCAT(COALESCE(first_name,''), ' ', COALESCE(last_name,'')) LIKE ?", ["%{$keyword}%"])
这样既避免 SQL 注入，又兼容不同数据库（CONCAT 在 SQLite 中行为略有差异，COALESCE 更稳妥）。
别名只在 SELECT 和 ORDER BY 有效，别指望它参与筛选
Laravel 中所有基于别名的链式调用（如 orderBy('full_name')）是合法的，因为 ORDER BY 在 SELECT 之后执行；但 where()、whereIn()、whereNull() 全部无效。有人试过 withCount() 后用别名 where，同样失败 —— 原因一致。记住一个判断标准：只要你想“靠别名缩小结果集”，就得回到原始字段或用 whereRaw 重写表达式。
最常被忽略的是：Eloquent 的 when() 或作用域里如果用了别名字段做条件，也会静默失效，得提前检查 SQL 日志确认实际发出的语句。
