在initialize()中调用app()->make()危险，因它绕过容器生命周期管理，导致中间件重复执行、请求上下文错乱、无法mock，破坏可测试性与可维护性。
不能直接用，会绕过容器生命周期，破坏可测试性。
为什么 initialize() 里调用 app()->make() 是危险操作
initialize() 是控制器生命周期中“初始化阶段”的入口，此时控制器已实例化、依赖已注入（$this->request、$this->app 等全部可用），但框架后续的中间件、参数绑定、响应处理等流程尚未结束。你在里面手动调 app()->make()，相当于在“正在上岗的员工”中途又叫来另一个“临时工”，而这个临时工没走入职流程——没有触发其自身的 initialize()、没经过中间件过滤、也没被纳入当前请求上下文。
- 它绕过了容器对类的生命周期管理（比如单例复用、销毁钩子）
- 若该服务本身也依赖
$this->request或其他请求上下文对象，可能因上下文不完整而报错或返回异常结果 - 单元测试时无法 mock 这个手动 make 的实例，导致测试耦合、难隔离
什么情况下你其实“不得不”用 app()->make()？
典型场景是跨模块调用另一个控制器（比如从 app\controller\Admin\User 调 app\controller\Api\Order），且你明确需要它的完整生命周期（包括 initialize() 执行）：
- 用
controller('Api/Order')—— 框架模拟一次伪请求，自动触发__construct → initialize → action - 用
app()->make('app\controller\Api\Order')—— 只执行__construct，initialize()不会自动调；如果你依赖它做权限校验，必须手动补：$ctrl->initialize(); - 绝不要在
initialize()里再用app()->make()去造另一个控制器——这会造成嵌套初始化，中间件重复执行、请求上下文错乱
替代方案：把逻辑拆出去，让容器自然注入
真正该放在 initialize() 里的，是轻量、无副作用的预处理。重逻辑（如数据加载、权限检查）应封装成独立服务，通过构造函数注入：
class UserController extends Controller
{
protected UserService $userService;
public function __construct(UserService $userService)
{
$this->userService = $userService;
parent::__construct();
}
protected function initialize()
{
// 这里只做简单判断，比如跳过登录校验的白名单路由
if (!$this->request->isGet()) {
$this->checkAuth();
}
}
protected function checkAuth()
{
// 权限逻辑已由 $this->userService 封装，不依赖手动 make
if (!$this->userService->hasPermission($this->request->action())) {
$this->error('权限不足');
}
}
}
这样既保持 initialize() 干净，又让依赖可测、可换、可复用。
容易被忽略的关键点
很多人以为 app()->make() 是“万能取服务”方法，但在 initialize() 里用，等于主动放弃框架对对象生命周期的管控。真正要警惕的不是“能不能用”，而是“用了之后，谁来负责它的初始化、中间件、销毁和测试”。ThinkPHP 的设计哲学是“约定优于配置”，initialize() 的定位就是轻初始化，重逻辑请交给服务层——这个边界一旦模糊，后续维护成本会指数级上升。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
