控制器构造函数仅用于声明依赖，不可执行查询、重定向或响应生成等副作用操作；应注入 userrepositoryinterface、notificationservice 等服务类，禁用 request/response/session 等请求生命周期对象。
控制器构造函数只适合放依赖声明，不是逻辑执行入口。 它会被 Laravel 服务容器自动调用并注入类型提示的依赖，但你不该在里面做查询、重定向、响应生成或任何副作用操作——这些必须挪到具体方法里。
哪些依赖可以安全注入
构造函数是声明「这个控制器需要什么才能工作」的地方。Laravel 会按类型提示自动解析它们，前提是这些类已绑定到服务容器（比如接口绑定实现类）：
-
UserRepositoryInterface：用于隔离数据访问，方便测试和替换实现 -
NotificationService：封装通知逻辑，避免在show或store里重复 new 实例 -
ValidatorFactory：如果要用自定义验证器工厂，而不是直接调Validator::make() -
Cache或RateLimiter实例：当多个方法共用同一缓存策略或限流规则时
注意：Request、Response、Session 这类请求生命周期对象不能在构造函数中注入——它们尚未初始化，会导致 Target class [request] does not exist 或空值问题。
为什么不能在构造函数里写业务逻辑
Laravel 控制器实例可能在路由匹配前就被创建（比如中间件提前触发），也可能被反复复用（如单例绑定错误）。常见踩坑现象：
- 构造函数里调
User::find($id)→ 报错Undefined variable: id，因为$id是路由参数，只传给具体方法 - 构造函数里写
return redirect()->back()→ 直接中断响应流程，后续中间件和方法不执行，且报Headers already sent - 构造函数里查数据库并赋值
$this->users = User::all()→ 所有请求都走一遍全量查询，无法按需懒加载，也破坏了请求隔离
真正该执行的逻辑，比如根据 $id 查用户、校验权限、触发通知，全部得放在 show()、update() 这类动作方法里。
中间件和构造函数的协作边界
你可能会想：“那权限检查能不能放构造函数？” 答案是否定的。原因很实际：
- 中间件运行时机早于控制器实例化（除非你手动 new 控制器），所以构造函数根本等不到中间件的结果
- 即使强行在构造函数里调
Auth::user()，它返回的是当前请求用户，但此时还没过auth中间件，可能为 null - 正确做法是用中间件控制访问权（如
middleware('can:view,user')），构造函数只管“我需要什么服务来完成后续操作”
换句话说：中间件决定“能不能进”，构造函数只负责“进门后手边有哪些工具”。两者职责不能混。
最易被忽略的一点：构造函数注入的依赖默认是每次请求新建实例（除非显式 singleton() 绑定）。如果你没意识到这点，又在构造函数里做了耗资源操作（比如连接外部 API），就等于每个请求都触发一次——而这不是 Laravel 的本意，也不是构造函数该承担的职责。
