应使用 composer remove 命令移除包，它会自动更新 composer.json、删除 vendor 中对应目录、同步 composer.lock 并重建 autoload 映射，全程原子化；手动删文件或修改配置极易导致 autoload 错乱、类找不到及锁文件不一致。
直接用 composer remove，别手删 vendor 或改 composer.json
它不是“删文件”，而是反向安装：自动从 composer.json 的 require 或 require-dev 里移除条目、删 vendor/vendor-name/package-name 目录、更新 composer.lock、重建 autoload 映射。整个过程原子化，失败即回退。
常见错误现象：
手动删掉 vendor/monolog/monolog，再删 composer.json 里那行，最后跑 composer install → 极易导致 autoload 错乱、类找不到、composer.lock 哈希不一致。
-
composer remove monolog/monolog就够了，不用加--dev（除非同名包同时在require和require-dev） - 开发依赖如
phpunit/phpunit，composer remove phpunit/phpunit会自动识别并处理 - 执行后立刻验证：
composer show monolog/monolog应报 “Package not found”，ls vendor/monolog应提示 “No such file or directory”
遇到 “required by another package” 别硬删，这是保护机制
比如运行 composer remove guzzlehttp/guzzle，但 symfony/http-client 明确 require 它，Composer 就会中止并列出谁在依赖它 —— 这不是报错，是防止你误删核心依赖。
- 先查清楚依赖链：
composer why guzzlehttp/guzzle - 若上游包（如
symfony/http-client）也确实不需要，可按提示确认降级或移除 - 临时调试可用
--no-update：composer remove guzzlehttp/guzzle --no-update，之后再composer update重算依赖树（慎用，可能遗漏冲突） - 绝对不要先手动删
composer.json条目再跑composer install，锁文件和实际目录极易脱节
删完必须人工扫三处残留，autoload 不会帮你擦屁股
composer remove 只管声明和 autoload 配置，不管你的代码里还留着多少 use、new、配置项或服务提供者注册。这些不清理，上线就 Class not found。
- 全局搜
use语句：grep -r "use Monolog\" . --include="*.php"（注意反斜杠转义） - 检查框架配置：Laravel 项目看
config/logging.php、config/app.php里的providers和aliases；Symfony 看config/bundles.php - 删了包但类还能 new 出来？大概率是 autoload 缓存没刷新，补一句：
composer dump-autoload --classmap-authoritative（Laravel 9+ 默认启用该模式）
批量删多个包、全局包、间接依赖怎么处理
一次删多个包，直接空格连写即可，composer.lock 只更新一次，更高效：
composer remove spatie/laravel-permission laravel/sanctum nunomaduro/collision
- 包名大小写敏感：
spatie/laravel-permission≠Spatie/Laravel-Permission - 全局包要用
composer global remove，别在项目目录下瞎敲 - 间接依赖（比如 A 依赖 B，你只删了 A）不会被自动清理，等下次
composer update自动处理；想主动清，可加--with-dependencies，但只对“只被刚删包引用”的子依赖生效 - 如果
composer.json的autoload.psr-4或autoload.files里硬写了已删包路径，得手动删掉，否则dump-autoload仍会尝试加载
最麻烦的从来不是命令本身，而是删完后代码里还藏着几处 use、一个没删的服务提供者、或者缓存里固化的旧类映射 —— 这些地方不扫，问题一定在部署时爆发。
