Container::getInstance() 在 Swoole 长生命周期中会持续累积未释放的对象导致内存泄漏，因其单例不自动清理 bind/make 的 request-scoped 实例，需在 onRequest 中清空 bindings 和 instances 并保留核心绑定。
为什么 Container::getInstance() 在 Swoole 长生命周期里会吃内存
ThinkPHP 的容器默认是单例且全局共享的，Swoole Worker 进程不重启，Container 就一直活着。每次 HTTP 请求都往里面 bind、make、注入新实例（比如 Request、Response、Db），但没人主动清理——这些对象不会被 GC，尤其带闭包、静态引用或 PDO 连接的对象，会越积越多。
常见现象：memory_get_usage(true) 每次请求后持续上涨；用 top -p [pid] 观察 Worker 进程 RSS 占用缓慢爬升；日志里没报错，但跑两天就 OOM。
- 别在
onRequest回调里反复调用Container::getInstance()->bind()绑定 request-scoped 对象 - 避免在中间件或控制器里用
app('db')后又手动unset($db)—— 容器没释放，实例还在内部 registry 里挂着 - TP 6.0+ 的
think-swoole扩展默认不重置容器，得自己干预
如何在每次请求前重置 Container 实例
不能直接 new Container 覆盖，因为框架很多地方硬依赖 Container::getInstance() 返回的单例。正确做法是清空其内部状态，同时保留核心绑定（如 think\App、think\Env）。
推荐在 Swoole onRequest 回调开头插入重置逻辑：
立即学习“PHP免费学习笔记（深入）”；
use think\Container;
use think\App;
$container = Container::getInstance();
// 保留必要核心绑定，其余全清
$coreBindings = ['app', 'think\App', 'think\Env', 'think\Config'];
foreach ($container->getBindings() as $abstract => $concrete) {
if (!in_array($abstract, $coreBindings)) {
$container->forget($abstract);
}
}
// 清空已解析过的实例缓存（关键！）
$container->setInstances([]);
-
$container->forget()只删 binding 定义，不删已实例化的对象；必须配合setInstances([])才真正释放内存 - 不要清空
app绑定，否则后续app('request')会报错 - 如果用了自定义服务提供者（Provider），需在重置后重新 register，或改用 request-aware 的 lazy binding
static::$instance 和 $_SERVER 全局污染怎么隔离
TP 默认把 Request、Response 等塞进 static::$instance 或 $_SERVER['REQUEST_TIME_FLOAT'] 这类全局位置，Swoole 复用进程时它们不会自动失效，下次请求读到的是上一次残留的数据。
典型错误：用户 A 登录后，用户 B 请求拿到 A 的 session ID；或者 Request::instance() 返回旧的 URL 和参数。
- 禁用 TP 的全局实例缓存：在入口文件（如
swoole_server.php）中加define('APP_USE_STATIC_INSTANCE', false); - 改用依赖注入获取 request/response：
public function index(Request $request)，而不是Request::instance() - 手动清理 $_SERVER 中的 TP 相关键：
unset($_SERVER['HTTP_X_REAL_IP'], $_SERVER['REQUEST_URI']);（根据实际用到的 key） - 别在模型或服务类里用
input()、session()这类函数——它们底层依赖全局 state，应传参或注入
DB 连接和 Redis 实例为何越跑越卡
TP 的 Db 类默认复用连接，Swoole 下一个 Worker 里所有请求共用同一个 PDO 实例。但 MySQL 连接可能超时断开，PDO 不会自动重连；Redis 实例（如 think\Cache 底层的 Predis\Client）也可能因网络抖动残留无效 socket。
这不是容器问题，而是资源管理缺失。光重置容器没用，得让连接池或重连机制接管。
- 用
think-swoole的ConnectionPool替换原生 Db：配置'pool' => ['min' => 2, 'max' => 10] - Redis 改用
co\Channel+ 连接池，或直接切到swoole_redis协程客户端 - 避免在
__destruct里 close 连接——Swoole Worker 不一定会触发析构，得靠显式 release - 检查
mysql.ping是否开启（TP 6.1+ 默认关），建议设为 true 并配mysql.ping_interval=30
最麻烦的从来不是重置容器，而是那些你以为“只读”其实偷偷写全局状态的第三方扩展——比如日志驱动里缓存了 formatter 实例，又绑进了 container。得一个个翻源码确认是否线程/协程安全。
