__invoke 方法仅适用于“单入口、无状态、职责收敛”场景，如纯api端点、cli封装、不可拆分资源创建及第三方回调；滥用会增加理解与维护成本。
__invoke 方法确实好用，但只在明确符合“单入口、无状态、职责收敛”场景时才值得用。盲目替换传统控制器反而增加理解成本和维护负担。
什么时候该用 ProvisionServer 这类可调用控制器
它不是语法糖，而是对「一个请求 = 一个动作」的显式建模。适合以下情况：
- API 端点逻辑纯粹：比如
/webhook/stripe只做签名验证 + 事件分发，不涉及页面渲染或跳转 - CLI 命令封装：用
Route::post('/trigger-backup', BackupRunner::class)暴露一个 HTTP 触发入口，背后复用 Artisan 命令逻辑 - 资源创建类操作：如
/server、/tenant，整个流程不可拆分，且不需复用其中某一步 - 第三方服务回调路由：所有字段校验、幂等处理、业务响应都在一个函数里闭环，避免分散到多个方法再拼凑
make:controller --invokable 生成的代码藏着什么坑
生成器只给你空的 __invoke，但实际使用中容易忽略三件事：
- 无法直接复用
ValidatesRequeststrait 的validate()—— 因为它依赖$this->request，而可调用控制器默认不自动绑定请求对象；得手动加public function __invoke(Request $request)并声明类型提示 - 中间件执行顺序仍按路由定义走，但你不能再用
middleware('auth')->only('store')这种写法，必须全局或通过Route::middleware()显式包裹 - 测试时不能像传统控制器那样 mock
show()或update()方法，得完整模拟一次请求，断言更重
和传统控制器比，性能差多少
几乎没有差异。框架底层对 __invoke 的调用是直接反射执行，不额外创建实例或代理。但要注意两个隐性开销点：
- 如果你在
__invoke里手动 new 了五个 service 类，又没走容器注入，那和写在store()里一样慢 —— 问题不在控制器形态，而在依赖管理方式 - IDE 和静态分析工具（如 PHPStan）对
__invoke的支持弱于命名方法，类型推导容易失败，尤其当参数未类型提示时 - 日志里记录的 action 名会变成
ProvisionServer::__invoke，而不是ProvisionServer@store，某些监控系统靠这个字段聚合，可能漏报
真正难的是「边界判断」
单动作控制器最大的陷阱，不是技术实现，而是团队对「什么算一个动作」没有共识。比如用户注册：
- 如果只是存用户 + 返回 JSON →
RegisterUser::class合理 - 如果还要发邮件、初始化权限、触发 welcome flow → 这已经不是「一个动作」，而是「一个业务流程」，应拆成 Action 类或 Pipeline 处理，控制器只负责调度
- 一旦开始往
__invoke里塞if ($request->has('skip_email'))或match($type)分支，就该立刻停手，退回传统控制器 + 提取私有方法
__invoke 当快捷键用。它是个信号，告诉协作者：“这段逻辑不接受拆解，也不打算复用内部步骤”。用错地方，比不用还糟。
