用 composer remove 即可安全卸载包，不可直接删 vendor/ 或手动改 composer.json，否则会破坏 composer.json、composer.lock 与 vendor/ 的状态一致性，导致 autoload 错乱、类找不到或 CI 失败。
用 composer remove 就行，别删 vendor/ 或手动改 composer.json —— 后者大概率导致 autoload 错乱、类找不到、CI 构建失败。
为什么不能直接删 vendor/ 目录或硬改 composer.json
Composer 不是文件管理器，它靠 composer.json + composer.lock + vendor/ 三者状态一致才能正常工作。手动删目录或删配置行，会立刻打破这个一致性：
- 只删
vendor/monolog/monolog，但composer.lock还记着它的 hash → 下次composer install会把它拉回来 - 只删
composer.json里的条目，不运行安装命令 →vendor/和autoload完全不变，use MonologLogger还能用，但已是“幽灵依赖” - 两者都删了但没跑
composer install→autoload.php里仍保留旧路径映射，类可能加载成功，也可能在优化模式下直接报错
composer remove 的实际行为和参数控制
Composer 2.2+ 的 composer remove 是原子操作：它先校验依赖图，再同步更新声明、锁文件、自动加载映射，并触发 vendor 清理（默认行为）。关键点：
- 执行
composer remove monolog/monolog，它自动识别该包在require还是require-dev，无需加--dev（除非同名包同时出现在两个区） - 加
--no-update：只改composer.json，不碰vendor/和autoload，适合批量修改后统一重装 - 加
--with-dependencies：连带移除“只被该包引用”的子依赖（如guzzlehttp/promises），但不会动其他包的依赖树 - 遇到
Package is required by another package提示时，这不是错误，是保护机制 —— 运行composer why monolog/monolog查谁在用，再决定是否先卸载上游包
卸载后必须人工检查的三处残留
composer remove 只管依赖声明和自动加载配置，不管你的业务代码。以下地方不清理，上线必报 Class not found 或 Service not found：
-
use语句：grep -r "use Monolog\" . --include="*.php"（注意反斜杠转义） - 配置文件：Laravel 的
config/logging.php、Symfony 的config/packages/monolog.yaml等是否还引用该包 - 服务提供者注册：检查
config/app.php（Laravel）或app/Providers/目录下是否仍有对应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 --no-cache→ 强制重建映射，排除 autoload 缓存干扰；再试new MonologLogger()应直接报错
最容易被忽略的是：私有包或本地路径包（"type": "path"）卸载后，composer.lock 里可能残留 dist 引用，此时需配合 composer update --lock 或手动删 lock 文件中对应块再重装。
