当路由只对应一个明确动作且不涉及完整资源周期时，应使用__invoke；如触发后台任务、健康检查、渲染独立页面或处理Webhook。
什么时候该用 __invoke 而不是传统控制器？
当路由只对应「一个明确动作」，且这个动作不涉及增删改查完整资源周期时，__invoke 才真正省事。比如：触发某项后台任务、返回健康检查状态、渲染一个独立页面（如首页、维护页）、处理 Webhook 回调——这些场景下，写 index 或 handle 方法反而多此一举。
反例：用户列表页 + 搜索 + 分页 + 导出按钮 → 这是多个逻辑入口，硬塞进 __invoke 会快速膨胀成条件判断地狱，此时就该用标准控制器。
Route::get('/health', [HealthController::class]) 的隐含约定
Laravel 在注册单动作控制器路由时，会自动绑定到 __invoke 方法，但前提是：必须显式传入类名数组，不能写成字符串形式（如 'HealthController'），否则会报 Class name must be a string 错误。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- ✅ 正确：
Route::get('/health', [HealthController::class]); - ❌ 错误：
Route::get('/health', 'HealthController');（Laravel 9+ 已弃用字符串控制器语法） - ⚠️ 注意：依赖注入在
__invoke中照常生效，构造函数注入和方法参数注入都支持，但别在__invoke参数里重复写Request又在构造函数里再注入一次，容易混淆生命周期
和 Closure 路由比，__invoke 控制器的优势在哪？
Closure 路由写起来快，但一旦需要单元测试、中间件复用、或依赖服务（比如 NotificationService），就会立刻变脆弱。而单动作控制器天然支持：
- 通过
php artisan make:controller HealthController --invokable快速生成骨架 - 在
__invoke方法里直接类型提示接口，享受容器自动解析（如public function __invoke(HealthChecker $checker)） - 可单独为该路由加中间件：
Route::get('/health', [HealthController::class])->middleware('throttle:10,1'); - 测试时可直接 new 实例或从容器解析，无需模拟整个请求生命周期
容易被忽略的性能与维护陷阱
单动作控制器不是“更轻量”的代名词。如果它内部开始做大量数据预加载、多次 DB 查询、或调用外部 API，那它和普通控制器在性能上毫无区别，甚至更难优化——因为缺乏明确的方法边界，缓存策略、日志埋点、异常分类都容易模糊。
真正该警惕的是：当某个 __invoke 方法超过 20 行、出现 if/else 分支处理不同请求参数、或开始返回多种 HTTP 状态码（如 200/400/503 混用），说明它已经超出了“单动作”范畴，是时候拆了。
