ThinkPHP 中 action() 函数自5.1起已废弃并移除，应将复用逻辑抽离为服务类、命令行指令或事件系统，而非跨控制器调用。
ThinkPHP 中 action() 函数已废弃，别再用了
从 ThinkPHP 5.1 开始，action() 函数被彻底移除；TP6 完全没有这个函数。如果你在文档或老项目里看到它，说明代码停留在 TP5.0 或更早，直接照搬会报 Call to undefined function action() 错误。
替代方案不是“找一个新函数名”，而是换思路：ThinkPHP 的设计原则是控制器职责单一、不鼓励跨控制器调用。真有复用逻辑，应该抽成服务类或中间件。
常见错误现象：
• 在控制器 A 里写 action('User/login')，运行直接报错
• 升级 TP5.0 → TP5.1 后原有功能突然失效，查日志只看到未定义函数
- TP5.0 支持
action()，但底层是通过反射实例化目标控制器并调用方法，性能差、不可控、绕过中间件 - TP5.1+ 推荐用
app()->invoke()或手动实例化 + 调用，但必须注意生命周期和依赖注入是否完整 - 如果只是想复用某个登录校验逻辑，别跨控制器调用，把它放进
app/service/AuthService.php更干净
app()->invoke() 怎么安全调用另一个控制器方法
这是 TP5.1+ 官方保留的底层调用方式，但它不是为“跨控制器跳转”设计的，而是用于框架内部调度。强行用来调用控制器方法，容易漏掉初始化逻辑。
立即学习“PHP免费学习笔记（深入）”；
使用场景：极少数需要在当前请求上下文中“模拟执行”另一个控制器动作（比如统一日志记录后触发通知控制器），且你清楚自己在绕过路由和中间件。
示例（不推荐日常用，仅说明机制）：
// 在 UserController.php 中
public function index()
{
// 注意：这不是重定向，只是执行另一段代码
$result = app()->invoke(['app\controller\Notify', 'sendMail']);
return json($result);
}
-
app()->invoke()第一个参数是数组[类名, 方法名]或字符串'app\controller\Notify@sendMail' - 它不会自动注入 Request、View 等依赖，控制器里若用了
$this->request，会报Call to a member function param() on null - 中间件、初始化方法（如
initialize()）完全不会执行 —— 这是最容易踩的坑 - 如果目标方法返回视图（
return view()），结果是字符串，不是响应对象，不能直接 return
真正该用什么代替跨控制器调用
95% 的所谓“跨控制器调用”，本质是业务逻辑耦合太紧。ThinkPHP 的控制器本就不该承担核心业务，它只是请求入口。
正确做法是把可复用逻辑下沉，而不是在控制器之间打洞。
- 提取为服务类：放在
app/service/下，用app(ServiceName::class)或依赖注入获取，天然支持单例、AOP、测试 - 封装成命令行指令：适合异步、定时、后台任务类逻辑，用
php think notify:send触发 - 用事件系统：在用户登录成功后触发
UserLoggedIn事件，多个监听器（邮件、短信、统计）各自响应，解耦彻底 - 如果非得“调用”，改用 HTTP 内部请求（
Http::post('http://localhost/api/notify/send')），虽然略重，但语义清晰、隔离性强、调试方便
为什么 __call() 或魔术方法不能救 action()
有人试过在基类控制器里加 __call() 拦截，然后手动 new 控制器再 call_user_func —— 这样确实能“跑起来”，但隐患更大。
典型问题：
- Request 对象丢失，
$this->request->param()报错 - View、Validate、Db 等 Facade 无法正常工作，因为 App 容器没完成绑定
- Session、Cookie 上下文错乱，尤其在多应用或多模块时
- TP6 的容器默认关闭了控制器自动解析，
app('app\controller\User')会失败，除非手动 bind
复杂点在于：你以为只是“调个方法”，实际上是在手动重建半个请求生命周期。这事不值得花时间 debug。
