沙箱模式不自动清除所有全局状态，仅按预设resetter清理容器内绑定组件；登录态串、配置错乱或内存泄漏源于未重置auth静态实例、自定义单例、共享session、协程不安全db/redis连接及全局静态变量。
沙箱模式不是“开了就自动安全”的开关，它只在请求生命周期内生效，且依赖你主动配合重置逻辑；不清理静态状态、不关闭共享 Session、不处理协程不安全的 DB/Redis 实例，照样会污染容器。
为什么沙箱模式下还会出现登录态串、配置错乱或内存泄漏
沙箱模式本身不自动抹除所有全局状态——它只按预设的 Resetter 清理注册过的组件。常见漏点包括：
-
Auth::user()或Auth::guard()->user()的实例被缓存在静态属性里，沙箱不重置AuthManager以外的 guard 状态 - 自定义单例（如
App\Services\PaymentClient）未加入pre_resolved或未实现重置逻辑，导致复用旧连接 -
Session被配置为跨请求共享（'session' => ['driver' => 'file']+enable_session开启），而 Swoole Worker 是常驻的，文件锁或路径冲突直接引发 500 - 手动调用
config(['app.debug' => true])后没恢复，该修改会持续到下一个请求
如何正确启用并验证沙箱模式是否真正在工作
关键动作不是“启动服务”，而是确认三件事：配置加载、重置器注册、请求隔离验证。
- 运行
php artisan vendor:publish --tag=laravel-swoole，确保config/swoole_http.php存在且'sandbox' => true - 检查配置中
'resetters'数组是否包含BindRequest::class、ResetConfig::class、ResetSession::class（默认已配好，但自定义配置可能删掉） - 在中间件里加一行日志：
Log::info('request_id: ' . request()->id(), ['memory' => memory_get_usage()]);，连续发两个请求，观察日志里memory值是否明显回落（说明容器重建而非复用） - 故意在第一个请求里执行
config(['cache.default' => 'redis'])，第二个请求里查config('cache.default')—— 若返回file（原始值），说明ResetConfig生效
哪些组件必须手动重置，沙箱模式不管
沙箱模式只管 Laravel 容器内显式绑定的对象和框架核心服务。以下情况需你额外干预：
- 数据库连接：原生
pdo_mysql不支持协程，必须用co\MySQL或hyperf/database封装，且每次查询前不能复用上一个协程的$connection实例 - Redis 客户端：停用
Predis\Client和phpredis，改用co\Redis，并在go(function () { ... })内创建新实例 - 全局静态变量：比如
MyHelper::$cache = []，沙箱不会碰它，必须在Resetter中手动清空，或改用容器绑定+请求作用域 - 第三方 SDK 单例（如
AlipayAopClient）：若通过app()->singleton()绑定，需确保其构造函数无副作用；否则应在BindRequest后重新 resolve
沙箱模式真正起效的前提，是你清楚哪些状态是“容器内的”、哪些是“进程级的”。混淆这两者，再完整的重置器列表也救不了请求间污染。最易被忽略的是：协程上下文里的资源句柄（如 co\MySQL->connect() 返回的连接）根本不在容器管理范围内，它们只属于当前协程，出作用域即销毁——所以别存成类属性，更别塞进 static $conn。
