ThinkPHP模块加载机制本身是攻击面，因Loader会动态拼接并尝试加载任意符合命名规范的类路径；废弃模块若残留路由、控制器或服务提供者，可能成为未经审计的入口，被攻击者利用触发反序列化或未授权访问。
为什么ThinkPHP的模块加载机制本身就是攻击面
ThinkPHP 的 Loader 和自动加载规则（尤其是 think\Container 对类名的动态解析）会把任意符合命名规范的类路径拼接后尝试加载。如果项目里留着未使用的模块（比如废弃的 wechat、pay、oss 扩展包），而这些模块又自带路由或控制器，就等于在生产环境里埋了未经审计的入口。攻击者不需要破解核心逻辑，只要发现 vendor/topthink/think-wechat 存在且未被禁用，就能顺着它的回调路由触发反序列化链或未授权访问。
如何确认哪些模块实际被启用
别信 composer.json 里写了什么，要看运行时是否真被加载：
- 执行
php think debug:route，检查输出中是否存在你没主动注册的路由，比如/wechat/callback或/pay/notify - 在入口文件
public/index.php开头加一行：var_dump(array_keys(\think\facade\App::getContainer()->getBindings()));，观察是否有wechat.sdk、oss.client这类绑定项 - 检查
config/目录下是否存在对应模块的配置文件（如wechat.php），哪怕内容为空，只要文件存在，框架就可能尝试初始化
禁用模块不是删 vendor 就完事
直接删 vendor/topthink/think-wechat 可能导致依赖报错或 Composer 锁文件冲突；更危险的是，有些模块通过 service_provider 自动注册，删了代码但没清理配置，框架仍会尝试加载已不存在的类，抛出 Class not found 错误——这反而暴露了模块曾经存在过，给攻击者提供线索。
正确做法是：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/provider.php中注释或删除对应服务提供者的类名（如think\wechat\WechatServiceProvider::class） - 清空
runtime/container/目录，避免容器缓存残留绑定 - 若模块带独立路由，在
route/app.php或对应路由文件中显式移除全部Route::import()或Route::rule()调用
ThinkPHP 8.1+ 的模块安全开关在哪
8.1 版本起新增了模块白名单机制，但默认不生效。必须在 config/app.php 中显式设置：
'module_whitelist' => ['app', 'api'], // 只允许加载 app 和 api 模块
注意：module_whitelist 是数组，值为模块目录名（不是命名空间），且必须包含当前主应用模块（如 app）。漏掉会导致整个应用无法启动；写成 ['*'] 或留空等于没设。
这个配置只控制 App::module() 动态加载行为，对 vendor 包里的类无影响——所以仍需配合前面的服务提供者清理。
public/static/wechat/）可能仍可被直接访问，且 Nginx/Apache 规则若没同步更新，就会形成“代码禁了，文件还在”的假安全状态。 
