应使用 composer remove 卸载包，它自动更新 composer.json、清理 vendor 和 autoload 映射；Class not found 主因是代码中残留 use/new、autoload 缓存未清或 OPcache 未刷新。
composer remove 后为什么还报 Class not found？
这不是 Composer 没卸干净，而是它根本不管你的代码——composer remove 只动 composer.json、vendor/ 目录和 autoload 映射，不碰任何 use 语句、new Xxx() 调用、配置文件或服务注册。
常见干扰点：
-
grep -r "Monolog\Logger" app/ src/ config/ --include="*.php"找出所有硬编码引用，尤其注意大小写和命名空间缩写（如use MonologLogger;vsuse MonologHandlerStreamHandler;） - Laravel 项目里检查
config/app.php的providers和aliases，Symfony 项目查config/services.yaml中的class:或factory: - 某些包注册了中间件、事件监听器或 Artisan 命令，这些不会随
remove自动注销，得手动删app/Http/Kernel.php或EventServiceProvider.php
autoload 映射残留导致“假存在”
执行 composer remove 后运行 composer show vendor/package-name 报 “Package not found”，但 new PackageClass() 仍能实例化——大概率是 vendor/composer/autoload_*.php 里还存着旧路径，或者 OPcache 缓存了旧映射。
必须补的操作：
- 强制重建自动加载：
composer dump-autoload -o（加-o是关键，否则 classmap 不会刷新） - 检查
vendor/composer/autoload_psr4.php和autoload_classmap.php，搜索包名确认条目已消失 - 清除 PHP 缓存：
opcache_reset()（CLI 下可直接调用），或重启 Web 服务器（Apache/Nginx + PHP-FPM） - Docker 环境中，别只
docker exec -it php bash进去跑命令——确保你操作的是实际运行容器里的文件，不是挂载卷外的副本
全局 bin 文件劫持新安装的命令
重装 Composer 后运行 laravel new project 报错或行为异常？很可能是旧版 laravel 二进制还在 PATH 里，它指向已删除的 ~/.composer/vendor/autoload.php。
验证和清理步骤：
- 运行
which laravel，如果输出/home/user/.composer/vendor/bin/laravel，说明残留 - 运行
ls -l ~/.composer/vendor/bin/看是否还有laravel、phpunit、bowler等可执行文件 - 直接删：
rm ~/.composer/vendor/bin/laravel（别用composer global remove，它不处理这个目录） - 检查 shell 配置：
grep -n "export PATH=.*composer" ~/.zshrc ~/.bashrc，删掉类似export PATH="$HOME/.composer/vendor/bin:$PATH"的行
composer.lock 锁定版本引发的兼容性误判
卸载一个包后，composer install 却拉来一堆“无关”更新，甚至提示 symfony/console v6.4 conflicts with monolog/monolog ^3.0？问题不在你刚删的包，而在 composer.lock 里还锁着旧依赖关系，Composer 试图维持整个图的一致性。
正确做法是分两步走：
- 先确认目标包已从
composer.json的require或require-dev中彻底移除（包括大小写、vendor 名拼写） - 再运行
composer install --no-cache（跳过本地缓存，强制按当前composer.json重算依赖树） - 若仍卡住，临时删掉
composer.lock再跑composer install（仅限开发环境，生产环境务必保留 lock 文件） - 绝对不要在没删
composer.lock的情况下，仅删vendor/后跑composer update——这会导致哈希校验失败或版本漂移
最常被忽略的是：Composer 的兼容性判断基于整个依赖图，不是单个包。残留的 lock 条目、未清理的全局 bin、以及 autoload 缓存，三者叠加会让“已卸载”变成“看似卸载”。
