ThinkPHP 接口请求结束后残留上下文是因为其默认按单次 HTTP 请求生命周期设计，CLI/Swoole 等长连接场景需手动调用 App::destroy() 并清理静态资源。
为什么 ThinkPHP 接口请求结束后还会残留上下文？
因为 ThinkPHP 默认使用单例容器 + 静态属性管理请求上下文（比如 Request、Response、App 实例），而 CLI 或长连接场景下，PHP 进程复用导致这些静态引用不会自动释放。不是框架“忘了清”，而是它默认按「一次请求生命周期」设计，没预料到你让一个进程跑多个请求。
常见错误现象：memory_get_usage() 持续上涨；同一进程第二次调用接口时，input() 返回上一次的参数；session_start() 报「headers already sent」。
- 只在
Http请求模式下自动清理，CLI、Swoole、Workerman等需手动干预 -
App::destroy()是核心清理入口，但它不递归销毁所有静态引用，比如第三方扩展注册的全局钩子可能漏掉 - 若用了
think-swoole，得配合Swoole\Http\Server的onRequest生命周期做重置，不能只靠框架原生逻辑
App::destroy() 该在哪儿调用才真正生效？
调用位置错了等于没调——它必须在「当前请求所有业务逻辑执行完毕、响应已发出、但 PHP 进程尚未退出」这个窗口期执行。早了会中断输出，晚了就进不了回调。
典型可用位置：
立即学习“PHP免费学习笔记（深入）”；
-
app()->after('AppEnd')事件里（推荐，框架预留的清理时机） -
register_shutdown_function()中，但要加判断：仅当是 CLI/Swoole 且非异常终止时才执行App::destroy() -
Swoole场景下，在onRequest回调末尾显式调用（注意：别在中间件里调，中间件可能被复用）
别在控制器方法末尾写 App::destroy() —— 响应还没发出去，Response 对象还在被持有，清理不彻底。
哪些对象不随 App::destroy() 自动释放？
App::destroy() 主要重置容器和部分核心实例，但以下三类常被忽略，是内存泄漏主因：
-
think\facade\Cache、think\facade\Log等门面类底层持有的静态连接池（如Redis连接、日志Handler），需单独调用Cache::clear()或关闭Handler - 自定义的全局单例（比如
MyHttpClient），如果用Container::set()注册过，得手动Container::delete()；如果只是static $instance，就得自己写reset()方法 -
think\db\Connection实例默认启用查询日志缓存，Db::getLog()不清空会导致 SQL 字符串越积越多，建议在AppEnd里加Db::clearQueryLog()
CLI 脚本调用接口时如何模拟请求生命周期？
直接 new App 然后 run()，不手动收尾，就是泄漏温床。CLI 下没有「请求结束」信号，全靠你定规则。
实操建议：
- 每个脚本任务封装成独立函数，函数末尾强制执行：
App::destroy(); Container::clear(); Log::close(); - 避免在循环中反复
new App()，改用App::useApp()复用实例（v6.1+），再配App::flush()清除请求相关状态 - 检查是否启用了
debug模式 ——APP_DEBUG=true会让Debug类长期持有 trace 数据，CLI 下务必关掉
最易被忽略的是 think\helper\Str 等工具类里的静态缓存，它们不走容器，也不会被 App::destroy() 触及，但一般影响小；真要严控，就别用带静态缓存的辅助函数，或定期 ReflectionClass 强制重置。
