不建议在控制器中直接实例化并调用另一个控制器的public方法，因其依赖框架注入的请求上下文（如$request、$response），手动new会导致这些依赖为空，引发异常或逻辑错误；应将复用逻辑抽离至Service或Repository类，通过依赖注入使用。
直接调用另一个控制器的方法会出问题
不建议在控制器里直接实例化并调用另一个控制器的 public 方法。控制器不是工具类，它依赖框架注入的请求上下文（如 $request、$response、$session），手动 new 一个控制器会导致这些依赖为空，轻则逻辑异常，重则抛出 Call to a member function on null 错误。
常见错误现象：Undefined property: App\Http\Controllers\OtherController::$request，或路由参数、中间件状态丢失。
- 控制器生命周期由框架管理，手动 new 会绕过构造函数注入和中间件执行
- 如果只是想复用逻辑，说明职责没分清 —— 把业务逻辑抽到 Service 或 Repository 类里更合理
- 少数场景（如 Laravel 的
action()辅助函数）看似“调用控制器”，实际是触发新请求，开销大且不可控
Laravel 中用 app()->make() 获取控制器实例也不行
app()->make(OtherController::class) 确实能拿到实例，但它不会自动绑定当前请求对象，$this->request 仍是 null。框架不会为手动解析的控制器补全请求上下文。
使用场景：几乎不存在正当理由需要这么做。哪怕你只想跑一个方法，也该把它移出控制器。
- 参数差异：框架自动创建控制器时传入
Request实例；make()不传，也不会帮你补 - 性能影响：即使成功，也等于在一次 HTTP 请求里硬塞了两次控制器初始化流程
- 兼容性风险：Laravel 9+ 对控制器构造函数约束更严，
make()可能直接报Unresolvable dependency
真正该做的：把方法拆进 app/Services/ 或 app/Actions/
把原本写在控制器里的可复用逻辑，搬到 Service 类里，然后在两个控制器中都依赖它。这是 Laravel 官方推荐的解耦方式。
示例：用户导出逻辑被多个控制器需要
class UserExportService
{
public function exportAsCsv(array $users): string
{
// 实际导出逻辑
return implode("\n", array_map(fn($u) => "$u->name,$u->email", $users));
}
}
- 在控制器中通过构造函数注入：
public function __construct(private UserExportService $exportService) - 调用时直接用
$this->exportService->exportAsCsv($users)，干净、可测、无上下文污染 - 如果逻辑极简单（比如格式化时间），甚至可以做成独立的
Helper函数或enum方法，不必强套 Service
跨控制器跳转或数据传递，用重定向 + session 或 query 参数
如果你本意不是“调用方法”，而是“做完 A 后让 B 执行后续”，那属于流程编排，不是代码调用。应该用 HTTP 语义来表达：重定向，并附带必要数据。
例如：订单创建成功后跳转到支付页，并传订单号
- 用
redirect()->route('payment.show', ['order' => $order->id])，而不是在订单控制器里调用支付控制器的show() - 若需透传少量临时数据，用
with()存入 session：redirect()->route('xxx')->with('message', 'success') - 避免把敏感数据（如 token、密码）拼在 URL 里；大量数据不要靠 session 传，改用缓存 + key 传递
