eloquent性能问题90%源于字段控制、关系名拼写、分页方式和where位置四点：with()需严格匹配关联方法名；select()须同步控制主模型与关联模型字段；chunkbyid()仅适用于有索引的单调递增主键；where()应前置所有业务条件以利用数据库索引。
with() 预加载必须严格匹配关联方法名
写了 with() 却没生效？不是 Eloquent 坏了，是你写的关联名根本不存在。它不会报错，也不会警告，只会默默跳过，然后在循环里继续触发 N+1。
-
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()或闭包预加载
select() 必须同步控制主模型与关联模型字段
只在主查询写 select()，对关联表完全没约束。尤其当关联表含 TEXT 或 JSON 字段时，不加限制会导致内存暴涨、网络传输激增。
Laravel 13.2.0
下载
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
- 主模型字段：直接写
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() 基于 LIMIT OFFSET，在高并发或数据频繁变动的场景下极易跳行、重复、死锁。而 chunkById() 按主键范围推进，稳定但有硬性前提。
- 必须指定主键字段（默认
id），且该字段要有索引（通常是主键索引） - 不能用于无主键表，也不能用于复合主键表（除非手动指定单字段主键）
- 配合分块预加载更安全：
Post::chunkById(200, fn($posts) => $posts->load(['comments' => fn($q) => $q->select('id', 'post_id', 'content')->limit(10)])) - 别指望它能“自动适配任意字段”，它只认主键，且要求主键单调递增
where() 不是 if 的替代品，而是 SQL 意图的声明
把过滤逻辑从数据库层拖到 PHP 层，等于主动放弃索引和执行计划优化。比如 User::where('status', 'active')->get()->filter(...)，本质是把全表拉进内存再筛 —— 数据量一上万就卡死。
- 所有业务条件都应尽可能前置到
where()链中：where('last_login_at', '>', now()->subDays(30)) - 字段不存在、类型错位、关联未加载时，
where()不校验，只拼 SQL —— 报错会出现在执行阶段，比如Unknown column 'username' in 'where clause' - 用户输入的动态条件，务必做白名单校验或字段映射，避免注入或类型崩坏
- 复杂条件组合建议用
when()封装，而不是堆砌一堆if判断后手动拼where
