User::factory()->create()报错主因是工厂未被发现或未关联：路径须为database/factories/UserFactory.php，命名严格匹配，Laravel 9+需继承Factory基类；create()写库并触发事件，make()仅内存构造；unique()仅单次调用链内有效，批量创建才保唯一。
直接用 User::factory()->create() 报错？大概率不是代码写错了，而是工厂类压根没被 Laravel 找到或没正确关联上模型。
工厂类找不到：路径、命名、自动发现全失效
从 Laravel 8 开始，工厂类必须放在 database/factories/ 根目录下，且文件名要严格匹配模型名（如 UserFactory.php 对应 User 模型）。嵌套子目录（比如 database/factories/User/UserFactory.php）会导致自动发现完全失效。
- 检查
composer.json的"psr-4"配置是否包含"DatabaseFactories\": "database/factories/"，改完必须运行composer dump-autoload - Laravel 9+ 不再支持旧式闭包工厂，必须继承
IlluminateDatabaseEloquentFactoriesFactory，别用错基类 - 如果用了自定义命名空间（如
AppFactoriesUserFactory），得在模型里重写newFactory()方法显式返回它
create() 和 make() 的行为差异直接影响测试稳定性
这两个方法看起来只差一个字母，但底层行为完全不同：create() 写入数据库并触发 creating/created 事件；make() 只构造内存对象，$model->exists === false。误用会污染事务、引发主键冲突或让依赖 $model->exists 的逻辑出错。
- 测表单验证、属性赋值逻辑？优先用
make()，快、干净、无副作用 - 测关联查询、软删除、事件监听？必须用
create() -
factory(User::class)->count(5)->make()返回的是Collection，不是数组；而create()才真正插入 5 条记录
unique() 不是全局去重，它只在单次工厂调用链内有效
Faker 的 unique() 是懒加载机制，每次调用 User::factory()->create() 都是新实例，不会记住上次生成的 email。所以循环中反复调用，大概率报 Integrity constraint violation: 1062 Duplicate entry。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 批量创建才安全：
User::factory()->count(10)->create()，此时unique()覆盖全部 10 次生成 - 单条创建需手动兜底：用
$this->faker->uuid . '@example.com'或加 retry 逻辑 - 更可靠的做法是在数据库迁移里给字段加
unique()约束，提前暴露重复问题
关联数据生成时外键约束失败的常见原因
用 has() 或 for() 生成关联数据时，报外键约束错误（如 SQLSTATE[HY000]: General error: 1452 Cannot add or update a child row），通常是因为关联模型没按预期顺序创建。
-
User::factory()->has(Post::factory()->count(3))->create()是安全的，Laravel 会先建 User，再用其 ID 填充 Post 的user_id - 但
Post::factory()->for(User::factory()->create())->create()就危险：如果User::factory()->create()在工厂执行前就跑，可能因事务未提交导致外键校验失败 - 稳妥做法是把关联模型创建逻辑放到
afterCreating回调里，或确保父模型已存在且已提交
最常被忽略的一点：工厂本身不负责清理数据。哪怕你用了 refreshDatabase，它也只清空迁移定义的表，不会处理工厂里通过 has() 创建的深层关联表——这些得靠级联删除或手动清理。
