with()预加载必须严格匹配模型中定义的关联方法名（含大小写），否则静默失效，导致n+1查询；select()需同步控制主模型与关联模型字段，多对多需显式选pivot字段。
with() 预加载必须写对关系名，否则静默失效
预加载不是“写了就有效”，Eloquent 对关系名大小写和拼写完全敏感。写错一个字母或大小写不匹配，with() 就会直接忽略该关系，不报错、不警告，但 N+1 照常发生。
常见错误现象：循环中访问 $user->posts 仍触发上百次查询，toSql() 显示只有一条主查询；DB::enableQueryLog() 查看实际执行语句，发现根本没有关联表的子查询。
-
User::with('posts')有效，前提是模型里定义了public function posts() -
User::with('Posts')、User::with('post')、User::with('PostsList')全部无效 - 嵌套预加载如
with('posts.comments.author')，每一级方法都必须存在且返回合法关系对象（HasMany、BelongsTo等） - 带参数的关系方法（如
activePosts($status = 'published')）无法被with()调用，此时应改用whereHas()+withCount()或闭包预加载
select() 必须同步控制主模型和关联模型字段
只在主查询写 select()，对关联表毫无约束。尤其当关联表含大字段（TEXT、JSON），未限制字段会导致内存暴涨、网络传输激增。
使用场景：列表页展示用户头像、昵称及最近 3 篇文章标题，不需要文章全文或创建时间戳。
- 主模型字段：用
User::select('id', 'name', 'avatar')->with('posts') - 关联模型字段：必须用闭包语法，且包含外键，否则映射失败：
with(['posts' => fn ($q) => $q->select('id', 'title', 'user_id')]) - 多对多关联（如
roles）需显式选 pivot 字段：select('id', 'name', 'role_user.level') - 避免
select('*')，哪怕只加一个字段也要明确列出，防止未来表结构变更引入意外字段
chunkById() 替代 chunk() 处理大批量数据
chunk() 基于 LIMIT OFFSET，在高并发或频繁删除/插入场景下极易死锁、跳行、重复处理。而 chunkById() 按主键范围推进，稳定可靠，但有硬性前提。
常见错误现象：后台任务跑着跑着卡住不动，日志显示某一批次反复重试；分页结果漏掉中间几条记录。
- 必须使用带索引的整型自增
id，UUID 或字符串主键不支持 - 不能配合
orderBy('created_at')使用，它内部固定按id ASC推进 - 若业务强依赖时间顺序，可建联合索引
(created_at, id)，再手写WHERE created_at > ? AND id > ?分页逻辑 - 示例：
User::chunkById(500, fn ($users) => $this->processBatch($users))
orWhere 分组不当会彻底破坏查询逻辑
orWhere() 不是简单追加 “OR” 条件，它和 where() 混用时受 SQL 运算符优先级影响，容易产出意料外的结果集。
典型问题：想查 “状态为 active 且邮箱含 gmail，或者角色为 admin”，却查出一堆非 active 的普通用户。
- 错误写法：
where('status', 'active')->where('email', 'like', '%@gmail.com')->orWhere('role', 'admin')→ 实际等价于(status = active AND email LIKE ...) OR role = admin - 正确写法：用闭包包裹 AND 组合，再外层
orWhere：where(fn ($q) => $q->where('status', 'active')->where('email', 'like', '%@gmail.com'))->orWhere('role', 'admin') - 所有涉及混合 AND/OR 的动态条件，必须显式分组，不能靠链式调用默认顺序
- 调试时用
toSql()和getBindings()看最终生成的 SQL，比凭经验猜更可靠
最易被忽略的是：预加载关系名拼写错误和 select() 忘记约束关联模型字段——这两处不报错，但性能损耗是静默且线性的，数据量一上来就暴露无遗。
