laravel 自带 artisan 命令是最常用、最可靠的生成器，无需额外插件；核心是熟练使用 make:model -mfc 等组合参数批量生成模型、迁移、工厂和控制器，并理解各命令产出物及依赖关系。
直接说结论：Laravel 自带的 Artisan 命令就是最常用、最可靠的生成器，不需要额外装插件；所谓“框架生成器”本质上是 php artisan make: 系列命令的组合使用，关键在理解每个命令的产出物和依赖关系。
怎么用 make:model 同时生成迁移和工厂
很多新手以为模型、迁移、工厂要一个个手敲命令，其实 make:model 支持批量生成：
-
php artisan make:model Post -m：生成Post模型 + 对应的迁移文件（create_posts_table） -
php artisan make:model Post -mf：再加一个-f，连工厂类PostFactory.php也一起建好 -
php artisan make:model Post -mfc：再加-c，顺手把资源控制器PostController也生成（含--resource）
注意：-m 生成的迁移默认只带 id 和时间戳字段，表结构还得手动编辑 up() 方法；如果想跳过这步，可配合 --table=posts（但仅适用于已有表反向生成，不推荐新手用）。
make:migration 的两种典型用途和坑点
迁移文件不是只能用来建新表——它本质是“数据库变更脚本”，常见用法有两类：
- 新建表：
php artisan make:migration create_users_table→ 生成空迁移，需手动写Schema::create() - 修改已有表：
php artisan make:migration add_phone_to_users_table→ 文件名含add_或drop_是约定俗成的信号，up()里应写Schema::table('users', ...)，千万别误用create()
容易踩的坑：make:migration 不检查表是否存在，也不校验字段名是否合法；比如写 $table->string('email')->unique()，但数据库没装 innodb_file_per_table，MySQL 5.7+ 可能报错 Specified key was too long —— 这时候得回退迁移、改 string('email', 191) 再重跑。
什么时候该用 make:controller --api 而不是 --resource
选哪个取决于你的路由设计意图，不是“API 就一定用 --api”：
-
php artisan make:controller ApiController --api：生成 5 个方法（index,store,show,update,destroy），且默认不包含create/edit—— 因为纯 API 不需要返回 HTML 表单页 -
php artisan make:controller WebController --resource：生成全部 7 个方法，适合传统 Web 页面（create返回create.blade.php，store处理提交）
混淆后果：用 --api 写管理后台，结果发现缺 create 方法，硬塞进去又和 REST 规范冲突；或者用 --resource 写前后端分离项目，多出两个无用方法还可能被误调用。
自定义生成器命令的边界在哪
Laravel 官方 make: 命令覆盖了 90% 场景，但遇到复杂需求（比如“一键生成模型+迁移+API控制器+测试+Policy”），有人会去装第三方包如 laravel-ide-helper 或 laravel-generator。这些包的问题在于：
- 升级 Laravel 版本后常失效，比如 Laravel 11 移除了
app/Http/Controllers下的BaseController，某些生成器仍强行继承它，导致运行时报Class not found - 生成的代码风格不统一，比如自动加
use App\Models\User;，但你项目约定用App\Entities\User - 真正省时间的是“明确知道每行生成代码的用途”，而不是追求“一次生成全栈”——多敲几遍
make:modelmake:controllermake:request，比调试一个黑盒生成器快得多
所以，别迷信“全自动”，重点盯住 make: 命令输出的路径和文件名是否符合你项目的目录规范，比如模型是否进了 app/Models、请求类是否在 app/Http/Requests —— 这些路径一旦错位，后续 phpstan 或 IDE 自动补全就全乱了。
