ThinkPHP 6.1 主动移除 think-filesystem 是出于安全与解耦设计，并非安装遗漏；需手动安装扩展并注册服务提供者，或回退至 6.0.x 版本。
think-filesystem 在 6.1 中被移除是主动设计，不是安装遗漏
ThinkPHP 6.1.0 版本明确移除了对 topthink/think-filesystem 的核心依赖，这是出于安全与架构解耦的考虑，不是你漏装或 composer 拉包失败。官方更新日志写得清楚：“移除核心对 think-filesystem 库的依赖”。这意味着哪怕你 composer require topthink/framework:6.1.0 成功， hink acadeFilesystem 类也必然报错 —— 它在框架源码里已被删掉，autoload 根本找不到定义。
升级后 Class 'think\facade\Filesystem' not found 怎么办
这不是配置问题，是代码层必须适配的断裂点。有两条路可走：
- 退回到 6.0.x 系列（如
"topthink/framework": "6.0.15"），前提是项目不强依赖 6.1 的安全修复或 PHP 8.2 兼容性 - 保留 6.1+，但手动安装独立扩展：
composer require topthink/think-filesystem，然后确保在config/app.php的providers数组中显式注册服务提供者：think ilesystemServiceProvider::class - 检查是否用了
File::put()、File::exists()等原生thinkFile方法 —— 这些仍可用，但它们和Filesystemfacade 无关，别混淆
为什么 6.1 要砍掉内置 Filesystem
直接原因是安全风险积累：Filesystem 组件曾多次曝出反序列化利用链（如 CVE-2023-XXXX），且修复难度高、兼容性差。6.1 的策略是“默认不带，按需加载”，把责任交给使用者 —— 你用就装，不用就不暴露攻击面。这也导致一个现实问题：很多第三方扩展（尤其是 TP5 时代写的）硬依赖 Filesystem facade，一升级就崩，且错误提示不指向根本原因。
升级前最该检查的三件事
别急着 composer update：
立即学习“PHP免费学习笔记（深入）”；
- 搜全项目代码，grep -r "Filesystem" . —— 确认所有调用点，尤其是中间件、命令行类、上传逻辑
- 运行
composer prohibits topthink/think-filesystem，看有没有扩展（比如某个旧版 OSS SDK）在暗中冲突或强制降级 - 检查
runtime/目录权限和upload_tmp_dir配置 —— 6.1 下文件上传更依赖 PHP 原生临时目录稳定性，The file "/tmp/phpXXX" does not exist报错常因此触发，和 Filesystem 无关但容易误判
真正麻烦的从来不是装不上，而是你以为装上了，结果 facade 类存在但底层驱动没注册，或者上传逻辑因临时文件生命周期变化而偶发失败。
