推荐用 php artisan make:controller PostController --resource 快速生成带 CRUD 方法的控制器；路由应使用 [PostController::class, 'index'] 语法以支持依赖注入；参数校验优先用表单请求类；数据操作应下沉至 Repository/Service 层，避免控制器中直接 new 模型或 DB 查询。
直接用 php artisan make:controller 就能创建控制器，但默认生成的类不带构造函数注入、不带资源方法模板、也不自动注册路由——这些得自己补，否则容易写完跑不起来。
怎么用命令行快速生成常用控制器
最常用的是带资源方法（index、show、store 等）的控制器，适合 CRUD 场景：
php artisan make:controller PostController --resource
如果只需要空壳类（比如纯 API 逻辑或自定义方法），去掉 --resource 即可：
php artisan make:controller Api/V1/UserController
-
--api参数会跳过create和edit方法（Laravel 认为 API 不需要视图） - 路径中含斜杠（如
Api/V1/UserController）会自动创建嵌套命名空间和目录结构 - 生成的类默认在
app/Http/Controllers下，命名空间为App\Http\Controllers
路由绑定控制器时常见的 4 种写法差异
Laravel 路由指向控制器有多种语法，行为和兼容性不同：
-
Route::get('/posts', [PostController::class, 'index']);—— 推荐，支持依赖注入、中间件、PHP 8+ 属性路由 -
Route::get('/posts', 'PostController@index');—— 旧写法，Laravel 9+ 已弃用，IDE 不识别类型，无法自动补全 -
Route::resource('posts', PostController::class);—— 自动生成 7 个 RESTful 路由，但需控制器含对应方法名（index、store等） -
Route::prefix('api')->group(function () { ... });—— 套一层前缀后，控制器方法仍需手动绑定，别指望自动加/api
控制器里怎么安全地接收和校验请求参数
别再用 $request->input('xxx') 手动取值 + validate() 分开写了。Laravel 提供了更稳的方式：
- 用表单请求类（
php artisan make:request StorePostRequest）封装验证规则，控制器方法直接类型提示即可 - 控制器方法签名示例：
public function store(StorePostRequest $request) { $validated = $request->validated(); // 自动通过验证后的数组 // 后续逻辑 } - 如果只是简单验证，也可用
$request->validate([...])，但它会中断执行并返回 422，不适合需要 fallback 处理的场景 - 注意：所有通过
$request获取的数据默认已过滤 XSS（Laravel 会自动调用strip_tags等），但数据库写入前仍需按字段做严格类型转换（比如intval($request->id)）
为什么控制器里不能直接 new Model() 或调用 DB::table()
不是语法错误，而是破坏了 Laravel 的可测试性和解耦原则：
- 硬编码
new Post()会让单元测试无法 mock 模型行为 - 直接写
DB::table('posts')->where(...)绕过了 Eloquent 的事件、访问器、强制作用域（globalScopes） - 正确做法是把数据操作下沉到 Repository 或 Service 类，控制器只负责协调流程和返回响应
- 如果真要快速写，至少用依赖注入方式获取模型实例：
public function __construct(private Post $post) {}，这样测试时可轻松替换 mock 实例
控制器不是万能胶，它该轻、该快、该一眼看清流程。真正复杂的业务逻辑藏在哪，比怎么写 return view() 更值得花时间想清楚。
