应使用 composer remove 命令安全卸载包，它自动移除声明、删除 vendor 目录、更新 lock 文件和 autoload 映射；需人工清理代码中 use、配置、服务注册等残留，并验证依赖关系与运行时一致性。
如果您在 ThinkPHP 项目中引入了某个 Composer 包，但后续不再需要该功能，则需安全移除对应依赖。手动删除 vendor 目录或直接编辑 composer.json 可能导致 autoload 映射失效、类找不到、锁文件不一致等问题。以下是基于 Composer 2.2+ 官方机制的安全移除方法：
一、使用 composer remove 命令移除包
这是官方推荐的原子化卸载方式，它会自动识别包所在区块（require 或 require-dev），从 composer.json 中删除条目、清除 vendor 下对应目录、更新 composer.lock，并重建 autoload 映射，整个过程失败即回退。
1、进入 ThinkPHP 项目根目录（确保包含 composer.json 和 vendor 子目录）。
2、执行命令：composer remove vendor/package-name，例如移除 monolog/monolog：composer remove monolog/monolog。
3、若该包仅用于开发环境（如 phpunit/phpunit），可显式加 --dev 参数：composer remove --dev phpunit/phpunit；未加时 Composer 通常能自动识别其所在区域。
4、命令执行完毕后，立即验证：运行 composer show vendor/package-name 应返回 “Package not found”，且 ls vendor/vendor-name 应提示目录不存在。
二、处理被其他包依赖的包
当目标包被 ThinkPHP 核心组件或其他已安装包显式 require 时，composer remove 会中止并列出依赖者，这是保护机制而非错误，防止破坏框架功能一致性。
1、运行 composer why vendor/package-name 查看所有直接引用者，例如输出可能含 topthink/think-swoole requires vendor/package-name。
2、若确认上游包（如 think-swoole）也不再需要，可按 Composer 提示输入 y，接受其建议的降级或连带移除操作。
3、若仅为临时调试，可添加 --no-update 参数跳过实时依赖解析：composer remove vendor/package-name --no-update，之后再统一执行 composer update 重算完整依赖树。
三、清理代码中残留引用
composer remove 不会扫描或修改 PHP 源码，因此所有与该包相关的硬编码引用必须人工检查并删除，否则上线后将触发 Class not found 错误且无明确提示来源。
1、全局搜索项目内所有 use vendor\package-name\* 语句，并删除对应行。
2、检查 config/ 目录下配置文件（如 app.php、cache.php 等），移除对该包的配置项或驱动注册声明。
3、审查 app/Providers/ 或 service providers 中是否注册了该包的服务提供者，若有则注释或删除相关 register() 调用。
4、查找所有 new \Vendor\Package\Class 或静态调用，替换为替代实现或删除逻辑。
四、移除子依赖及孤儿包
Composer 默认仅清理无任何其他已安装包引用的子依赖。若某子依赖（如 psr/http-message）仅被刚移除的主包使用，则会在后续 composer update 阶段自动剔除；若被多个包共用，则保留。
1、若需强制连带移除你在 composer.json 中手动添加的直系依赖（非间接继承），可加 --with-dependencies 参数：composer remove --with-dependencies vendor/package-name。
2、执行后检查 vendor/ 目录是否仍存在疑似残留的子包目录，如发现，运行 composer why psr/http-message 验证其是否真为孤儿——若输出为空，说明无人引用，可安全删去。
3、为确保 autoload 映射精简，可额外执行：composer dump-autoload --optimize，强制重建优化后的自动加载规则。
五、验证移除结果与环境一致性
ThinkPHP 对自动加载和配置敏感，移除后必须交叉验证多个层面，避免 CI/CD 构建失败或运行时异常。
1、打开 composer.json，确认目标包已完全从 require 和 require-dev 区块中消失。
2、比对 composer.lock 文件中是否仍存在该包的哈希记录，若有，说明 lock 未同步更新，需重新执行 remove 或手动运行 composer update --lock。
3、在 ThinkPHP 应用中启动调试模式，访问任意接口，观察日志是否出现因缺失类引发的 Fatal Error。
4、运行 php think optimize:autoload（如 ThinkPHP 版本支持），触发框架级 autoload 优化指令，确认无报错。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
