应使用 composer remove 命令卸载包，它会自动移除 composer.json 条目、删除 vendor 目录、更新 lock 文件并重建 autoload；手动删文件或改配置易致 autoload 错乱、类找不到、lock 哈希不一致。
直接用 composer remove，别手删 vendor 或改 composer.json
Composer 2.2+ 内置的 composer remove 就是专为卸载设计的原子操作——它不是“删文件”，而是反向安装：自动从 composer.json 的 require 或 require-dev 中移除条目、删除 vendor/vendor-name/package-name 目录、更新 composer.lock、重建 autoload 映射。整个过程失败即回退，安全可靠。
- 正确示例：
composer remove monolog/monolog（自动识别在require还是require-dev） - 错误做法：手动删
vendor/monolog/monolog，再删composer.json里那行，最后跑composer install→ 极易导致 autoload 错乱、类找不到、composer.lock哈希不一致 - 开发依赖也一样：
composer remove phpunit/phpunit会自动从require-dev清理，无需加--dev（除非同名包同时出现在两个区）
遇到 “package is required by another package” 别硬删
这不是报错，是 Composer 在拦你——比如你执行 composer remove guzzlehttp/guzzle，但 symfony/http-client 明确依赖它，Composer 就会中止并告诉你谁在用。强行绕过只会埋雷。
- 查依赖链：
composer why guzzlehttp/guzzle，输出所有直接引用者 - 接受提示降级/移除上游包（按 y 确认），比如先
composer remove symfony/http-client，再删 Guzzle - 临时调试可用
--no-update跳过实时解析：composer remove guzzlehttp/guzzle --no-update，之后再composer update让依赖树重算（慎用，可能遗漏冲突） - 绝对避免先删
composer.json再composer install，CI 构建大概率失败
删完必须人工扫三处残留
composer remove 只管声明和 autoload 配置，不管你的代码里还留着多少 use、new、配置项或服务提供者注册。这些不清理，上线就 Class not found。
- 全局搜
use语句：grep -r "use Monolog\" . --include="*.php"（注意反斜杠转义） - 检查配置文件：
config/logging.php（Laravel）、config/packages/monolog.yaml（Symfony）等是否还引用该包 - 确认服务提供者：
app/Providers/或config/app.php里是否注册了对应ServiceProvider - 额外检查：
composer.json的autoload.files或autoload.psr-4是否硬写了该包路径
验证是否真删干净：三个命令立刻确认
删完别急着提交，三秒验证是否真正清理到位：
-
composer show monolog/monolog应返回Package not found -
ls vendor/monolog应提示No such file or directory -
composer dump-autoload -o强制刷新映射，避免缓存误导判断 - 如果仍能
new出类，大概率是 autoload 缓存没清或路径残留，再跑一次composer clear-cache和composer dump-autoload
最常被忽略的是代码里那些 use 和配置项——它们不会随 remove 自动消失，得你自己动手，而且得在删包之前就搜一遍，否则上线才暴露就晚了。
