whereHas 中可使用 like 模糊匹配，但需正确书写语法（如 "%{$v}%"），避免误用 =；orWhereHas 易破坏逻辑分组，应统一用 where 闭包包裹；多关键词需分词并为每个词单独 orWhere 闭包；分页不准时优先确保 paginate 在最后调用，或改用 cursorPaginate。
whereHas 里不能直接用 like 模糊匹配？
可以，但必须写对语法。常见错误是把 like 写成 =，或漏掉百分号导致查不到数据。比如想查「附件名含关键词」的文章，whereHas('files', function ($q) use ($v) { $q->where('filename', 'like', "%{$v}%"); }) 才有效；写成 $q->where('filename', $v) 就是精确匹配，根本不是模糊。
另外注意：MySQL 默认不区分大小写，PostgreSQL 默认区分。如果要用不区分大小写的模糊匹配（如搜 “pdf” 匹配 “PDF”），PostgreSQL 得用 ilike，MySQL 可加 LOWER()：whereRaw('LOWER(filename) LIKE ?', [strtolower("%{$v}%")])。
orWhereHas 和 whereHas 混用时为什么结果不对？
因为 orWhereHas 会把整个条件“拉平”到主查询的 OR 层级，容易破坏原有逻辑分组。例如：
$articles = Article::where('title', 'like', '%a%')
->orWhereHas('files', function ($q) { $q->where('filename', 'like', '%b%'); })
->get();
这等价于 WHERE title LIKE '%a%' OR (files exists AND filename LIKE '%b%') —— 看似合理，但一旦前面有其他 where 条件（比如状态筛选），就可能意外放行不符合状态的数据。
更安全的做法是统一用 where 包一层：
$articles = Article::where(function ($q) use ($v) {
$q->where('title', 'like', "%{$v}%")
->orWhere('description', 'like', "%{$v}%")
->orWhereHas('files', function ($sub) use ($v) {
$sub->where('filename', 'like', "%{$v}%");
});
})->get();
- 避免
orWhere与where混用导致优先级错乱 - 所有模糊字段都放进同一个闭包，语义清晰、逻辑可控
- 后续加新字段（比如 tags.name）也只需在闭包内追加
orWhereHas
搜索多个关键词（如“iPhone 15”）怎么拆分处理？
用户输“iPhone 15”，不能只查 LIKE '%iPhone 15%' —— 这样只能匹配字段里连续出现这两个词的记录，漏掉“iPhone Pro”或“15 Plus”。
正确做法是先分词，再为每个词构建独立的 OR 组：
$keywords = collect(explode(' ', $request->input('q')))
->filter()
->map(fn($k) => trim($k));
$articles = Article::where(function ($main) use ($keywords) {
foreach ($keywords as $kw) {
$main->orWhere(function ($q) use ($kw) {
$q->where('title', 'like', "%{$kw}%")
->orWhere('description', 'like', "%{$kw}%")
->orWhereHas('files', fn($sub) => $sub->where('filename', 'like', "%{$kw}%"));
});
}
})->get();
- 用
collect()->filter()去掉空格、空字符串，防止"% %"这种无效条件 - 每个关键词单独套一层
orWhere，保证“任一词命中任一字段”即返回 - 不要在循环里反复调用
orWhereHas而不包裹闭包——否则会变成 AND 逻辑
关联表模糊搜索后分页总数不准？
这是因为 paginate() 默认执行 COUNT(*)，而 whereHas 或 orWhereHas 在 COUNT 阶段可能被忽略，尤其当闭包里用了 select 或 join 时。
最稳妥的方式是确保分页前所有条件已完整构建，并且不提前调用 select、withCount 等影响主表结构的操作：
$articles = Article::with('files') // 预加载，非必需但防 N+1
->where(function ($q) use ($v) {
$q->where('title', 'like', "%{$v}%")
->orWhere('description', 'like', "%{$v}%")
->orWhereHas('files', fn($s) => $s->where('filename', 'like', "%{$v}%"));
})
->paginate(15); // paginate 必须放在最后
如果仍不准，说明关联条件太重，建议改用 cursorPaginate()（需按 id 排序），或加数据库全文索引 + MATCH AGAINST 替代 LIKE。
真正容易被忽略的是：whereHas 的子查询在 COUNT 时依然执行，但若子表数据量大、没索引，COUNT 就会变慢甚至超时——这不是写法问题，是架构边界。
