composer remove：你以为的“卸载”和真正的“清理”
先明确一个核心观点：执行 composer remove 远不是依赖清理的终点，它更像是一个信号，标志着手动清理工作的正式开始。 这个命令只负责处理依赖声明和自动加载映射，至于代码里残留的引用、配置文件中的注册项，或是运行时的各种“幽灵”，它一概不管。如果就此收手，那么“Class not found”或“Driver not supported”这类错误，几乎注定会在上线后的第一时间找上门来。
composer remove 的职责边界：删什么，不删什么
当你运行 composer remove vendor/package-name 时，Composer 会忠实完成以下几件事：
- 从
composer.json文件的require或require-dev区块中，精准移除对应的包声明（它会自动识别位置，通常无需额外指定--dev参数）。 - 彻底删除
vendor/vendor-name/package-name这个物理目录。 - 更新
composer.lock文件，并重写vendor/autoload_*.php系列映射文件。
然而，它的“不作为”清单同样重要，必须牢记：
- 它不会清理你业务代码中的
use导入语句、new实例化操作或任何静态方法调用。 - 它不会动框架的配置文件，比如 Lara vel 项目里
config/app.php中的服务提供者（providers）或门面别名（aliases）数组。 - 它不会移除环境变量（
.env）、数据库迁移文件、缓存键名前缀，或是前端资源引用（例如通过mix()函数加载的 JS/CSS 资源）。 - 它也极少会触发包自带的
post-remove脚本——因为绝大多数包开发者并没有实现它。
删除后的必修课：三处必须手动检查的关键残留
千万别以为看到 composer remove 执行成功就高枕无忧了。下面这三处地方如果不进行手动清理，持续集成（CI）流程或线上部署几乎肯定会失败：
- 全局搜索包名关键词：在 IDE 或终端里执行类似
grep -r "vendor/package-name\|package-name" . --include="*.php" --include="*.js" --include="*.env"的命令。重点排查config/、app/Providers/、routes/目录以及.env文件。 - 检查服务提供者与门面注册：对于 Lara vel 项目，务必打开
config/app.php，仔细检查providers和aliases数组；如果是 Symfony 项目，则需要查看config/bundles.php。 - 验证 Artisan 命令是否依然存在：运行
php artisan list | grep -i "package-name"命令。如果还有输出，说明对应的命令类未被清除，或者其服务提供者仍有残留。
遇到“Package is required by another package”怎么办？
出现这个提示不是错误，而是 Composer 在保护你的依赖树完整性。强行绕过只会导致依赖关系断裂。正确的处理姿势是：
- 先查明依赖者：运行
composer why vendor/package-name，它会列出所有直接依赖这个包的上级包。 - 如果上游包（例如
symfony/http-client）也确实不再需要，就按照提示先移除它：composer remove symfony/http-client。 - 如果只是临时调试需要移除，可以使用
composer remove vendor/package-name --no-update跳过实时依赖解析，事后再通过composer update统一重新计算依赖树（需谨慎使用，可能会掩盖潜在的冲突）。 - 绝对要避免的做法是：直接删除
composer.json中的条目，然后运行composer install。这会导致composer.lock文件中的旧哈希值被保留，从而在 CI 构建时报出“lock file is not up to date”的错误。
自动加载没刷新？别猜了，直接 dump
删除了包之后，发现代码里还能 new 出来，或者运行时报“Class not found”却找不到引用点？这大概率是自动加载器的缓存没有更新。尤其是在 Docker 环境、CI 流程中，或者启用了 --classmap-authoritative 优化模式的情况下：
- 首先，补上这个标准操作：
composer dump-autoload。 - 如果项目使用了优化模式（Lara vel 9+ 默认开启），则必须加上参数：
composer dump-autoload --classmap-authoritative。 - 记住，
vendor/autoload.php只是入口文件，其背后依赖vendor/composer/autoload_classmap.php等生成的映射文件。删除包目录，并不等于这些映射文件会自动重写。
最后，还有一个最容易被忽略的角落：composer remove 完全不会处理 config/ 目录下那些硬编码的驱动名、中间件别名，甚至是 phpunit.xml 里指定的测试套件路径。这些地方如果不人工核对，问题百分之百会在应用上线后的第一分钟暴露出来。
