laravel 5.8+ 应优先使用 wheredoesntexist() 实现“不存在”查询，需显式 select()、用 wherecolumn 关联字段、避免同名表别名、不支持 eloquent 作用域；它生成标准 not exists 子查询，语义清晰、性能优、逻辑严格，优于 doesnthave()。
whereDoesntExist() 是 Laravel 5.8+ 的标准解法
直接用 whereDoesntExist()，别绕弯。它底层生成标准 NOT EXISTS 子查询，语义清晰、性能可控、SQL 可预测。
常见错误是漏掉子查询里的 select() —— 不管选什么，哪怕 DB::raw(1)，都必须显式调用，否则 Laravel 报 QueryException: SQLSTATE[HY000]: General error。
- 关联字段必须用
whereColumn('posts.user_id', 'users.id')，不能写成where('posts.user_id', 'users.id')（后者把字符串当值，查不到） - 子查询里禁止出现和外层同名的表别名，比如外层是
users，子查询里再写from('users')会冲突 - 子查询中不支持 Eloquent 作用域、
withTrashed()等链式方法，它们不会被带入 raw SQL
示例：
$users = User::whereDoesntExist(function ($query) {
$query->select(DB::raw(1))
->from('posts')
->whereColumn('posts.user_id', 'users.id')
->where('posts.published', true);
})->get();
低版本 Laravel（
低于 5.8 就没 whereDoesntExist()，必须自己拼 NOT EXISTS，但风险高：参数不走绑定就容易 SQL 注入，表别名错位就关联失败。
关键不是“能不能写”，而是“怎么写才不出错”：
-
whereRaw()第二个参数必须是数组，如[true]，硬编码进字符串里（比如'posts.published = true'）等于裸奔 - 子查询中的表名要和外层完全一致，
users.id不能写成user.id或User::class对应的表名，Eloquent 不做自动映射 - 子查询里不能调用模型方法或关系，只认原生查询构造器
示例：
$users = User::whereRaw(
'NOT EXISTS (SELECT 1 FROM posts WHERE posts.user_id = users.id AND posts.published = ?)',
[true]
)->get();
别用 doesntHave() 替代 whereDoesntExist()
doesntHave('posts') 看起来像，但它生成的是 LEFT JOIN ... WHERE posts.id IS NULL，不是 NOT EXISTS。两者在语义和性能上都不等价。
尤其当子查询带复合条件时（比如 published = true AND created_at > ?），doesntHave() 会把条件塞进 JOIN ON，可能漏掉本该排除的记录；而 whereDoesntExist() 的子查询是独立执行的，条件全在子查询 WHERE 里，逻辑更严格。
- 如果已定义
posts()关系且只需简单无关联判断，doesntHave()更简洁 - 但只要涉及子表字段过滤（非仅存在性），优先选
whereDoesntExist() - 大数据量下，
NOT EXISTS在多数数据库中比LEFT JOIN + IS NULL更易利用索引
子查询里字段为空值时要小心
如果子表关联字段本身允许 NULL（比如没设外键约束），whereNull('tasks.job_number') 就不可靠——你分不清这个 NULL 是“没匹配到”，还是“业务上故意留空”。
这时候不能依赖 LEFT JOIN + whereNull，也别硬套 doesntHave()，得回到 whereDoesntExist() 或手写 whereRaw()，确保子查询逻辑只响应“是否存在匹配行”，而不是字段值是否为空。
最容易被忽略的一点：这种场景下，子查询里的 WHERE 条件必须包含所有业务上有效的筛选项，否则可能把“有数据但不满足条件”的记录误判为“不存在”。
