Seeder类不存在需检查路径、命名、命名空间并运行composer dump-autoload；db:seed默认只执行DatabaseSeeder，子Seeder需在其中显式调用；大数据量插入应分块、批量、禁事件以避免超时。
seed 命令执行后没反应或报错 Class xxxSeeder does not exist
这是最常遇到的问题：Laravel 找不到你写的 Seeder 类。根本原因不是代码写错了，而是类没被自动加载器识别。
实操建议：
- 确认你的 Seeder 文件放在
database/seeders/目录下（Laravel 8+），且文件名与类名严格一致（如UserSeeder.php→class UserSeeder） - 运行
composer dump-autoload，强制刷新类映射 —— 很多人漏掉这步，尤其在手动新建文件后 - 检查命名空间是否为
Database\Seeders（Laravel 8+），旧项目升级后容易残留Database\Seeds - 如果用了自定义路径或 PSR-4 映射，
composer.json中的 autoload 配置必须包含该路径
php artisan db:seed 只跑 DatabaseSeeder，不执行自己写的子 Seeder
Laravel 默认只调用根种子类 DatabaseSeeder，它本身是个“调度器”，不会自动发现并运行其他 Seeder —— 这不是 bug，是设计逻辑。
实操建议：
- 在
DatabaseSeeder::run()方法里显式调用：$this->call(UserSeeder::class)、$this->call(PostSeeder::class) - 不要依赖文件顺序或命名规则，Laravel 不扫描目录自动注册
- 如果想按需执行单个 Seeder，直接用命令：
php artisan db:seed --class=UserSeeder - 注意
--class参数值必须是完整类名（含命名空间），比如Database\Seeders\UserSeeder
Seeder 中插入大量数据时卡死或超时
用 DB::table()->insert() 或 Eloquent create() 循环插入几千条数据，很容易触发 PHP 超时、内存溢出，或 MySQL 的 max_allowed_packet 限制。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
实操建议：
- 批量插入优先用
DB::table('users')->insert($data)，而不是循环User::create()—— 后者会触发模型事件、类型转换、验证等开销 - 分块处理：用
collect($data)->chunk(1000)拆成小批次，每批单独 insert - 临时关闭模型监听：在 Seeder 开头加
User::unsetEventDispatcher()，避免 save 时触发 observer 或 event - 生产环境禁止在 Seeder 中调用
factory()（已废弃），改用User::factory()->count(100)->create()，它内部做了优化
测试环境下跑 seed 导致重复数据或主键冲突
开发或测试中反复执行 db:seed，又没做去重或清空逻辑，很快就会遇到唯一索引冲突、主键重复、测试断言失败等问题。
实操建议：
- Seeder 里别假设表为空 —— 在
run()开头加DB::table('users')->truncate()或User::query()->delete()（后者会触发 deleting 事件） - 用
upsert()替代insert()（Laravel 9+），支持冲突时忽略或更新：DB::table('settings')->upsert($data, ['key'], ['value']) - 避免在
DatabaseSeeder中无条件调用所有子 Seeder；按环境判断，比如只在app()->environment('local')下运行示例数据 - 数据库迁移中更适合放结构变更，种子只负责“初始业务数据”，别混进测试用的随机数据
Seeder 看似简单，但和 migration、factory、model event、数据库事务边界都咬得很紧。最容易被忽略的是 autoload 刷新和 truncate 时机 —— 多数问题其实出在这两步没做，而不是逻辑写错了。
