composer remove 不会自动删除未被 require 的包，它仅移除明确指定的包，不分析代码使用情况或间接依赖关系。
composer remove 会自动删掉未被 require 的包吗
不会。 composer remove 只负责移除你明确指定的包（比如 composer remove guzzlehttp/guzzle），它不扫描项目里哪些包“实际没被用到”。所谓“未使用”，指的是代码里没调用、也没被其他依赖间接依赖——Composer 本身不分析 PHP 代码，只管 composer.json 的依赖图和 autoload 规则。
常见错误现象：删完一个包后运行 composer install，发现其他包报错找不到类——说明它其实是被间接依赖了，或者你的代码里还留着调用。
- 先确认是否真没被用：
grep -r "use.*GuzzleHttp" app/ src/ --include="*.php"（替换成你要查的命名空间） - 检查是否被其他已安装包依赖：
composer show -t | grep -A5 "your/package-name" - 别直接删生产环境的
vendor/，先在 dev 环境跑一遍composer update看是否破坏依赖树
怎么安全地识别并清理真正冗余的包
靠人工翻 composer.json 和代码太容易漏，得用工具辅助定位“装了但没用”的包。核心思路是：先生成当前项目实际加载的类列表，再对比 vendor/ 里所有包提供的类，找出没被任何 autoload 或运行时引用的包。
推荐用 roave/better-reflection + 自定义脚本，但更轻量的做法是用 composer-unused：
- 安装：
composer global require composer-unused/composer-unused - 运行：
composer-unused --no-dev（加--no-dev避免把require-dev里的包误判为冗余） - 注意它默认只检查
src/和tests/，如果你的业务代码在app/或lib/，得加--path=app/ - 输出里标
[unused]的包，才是可安全删的；标[indirect]的说明被其他包依赖，删了会断
删包后 vendor/autoload.php 没更新？检查 autoload 配置
删完包，vendor/autoload.php 有时没同步清理对应 PSR-4 映射，导致后续 class_exists() 还能返回 true，但实际文件已不存在——这是 Composer 缓存或 autoload 配置残留导致的。
典型表现：Class 'Foo\Bar' not found 错误消失，但类明明删了却还能“存在”；或者 composer dump-autoload 后报 Warning：“Class XXX is not autoloadable”。
- 执行：
composer dump-autoload --optimize（强制重建 autoload 映射） - 删掉
vendor/composer/autoload_*.php手动清缓存 - 检查
composer.json的autoload和autoload-dev字段，确认没有残留的路径映射指向已删除包的目录 - 如果用了
classmap，记得删掉对应条目，否则composer dump-autoload仍会尝试扫描不存在的路径
为什么 vendor/bin 下的二进制文件还在
删包后，vendor/bin/ 里对应的命令（比如 phpunit、phpcs）可能还在，因为 Composer 默认不会自动清理这些软链接。它们指向的源文件虽然没了，但链接本身没被删，下次运行就报 Command not found 或 No such file or directory。
这不是 bug，是设计行为：Composer 认为 bin 文件属于“用户主动使用的工具”，不随包删而删。
- 手动清理：
rm vendor/bin/phpunit（替换成实际名字） - 或者用
composer bin --list查看哪些 bin 是哪个包注册的，再针对性删 - 如果用了
bin-compat插件，还得检查vendor/bin/是否有重复或冲突的同名命令
最麻烦的其实是那些通过 scripts 在 composer.json 里硬编码调用的命令——删包后 CI 就直接挂，得同步改 scripts 里的 phpunit 为 ./vendor/bin/phpunit 或直接删掉整行。
