Composer无内置命令自动识别“无用依赖”；所谓冗余需人工界定：未声明却在vendor中的是必要传递依赖，不可删；已声明但代码未调用的才可安全移除，需结合grep、PHPStan等验证实际使用，并注意模板、构建脚本等间接依赖。
Composer 没有内置的 composer remove 命令能直接删掉“无用依赖”——它只认你手动声明的 require 和 require-dev，不会自动判断某个包是否被代码实际引用。所谓“冗余”，得靠人来定义：是没在 composer.json 里声明却出现在 vendor/ 中？还是声明了但项目代码根本没 use 或 require_once 它？这两类情况处理方式完全不同。
哪些包会被 composer install 拉进来却不在 composer.json 中？
这类包几乎全是“传递依赖”（transitive dependencies）：你 require 了 A，A 的 composer.json 里 require 了 B，那么 B 就会进 vendor/，但你自己的 composer.json 不会记录 B。它们不是冗余，而是必要链路。强行删掉会导致 A 运行时报 Class not found。
- 不要手动删
vendor/下未声明的目录——Composer 不会帮你修复 autoload 映射 -
composer update时会自动清理已不存在的传递依赖（比如 A 升级后不再 require B），但不会主动剔除仍被需要的旧传递依赖 - 想最小化 vendor，可尝试
composer install --no-dev --optimize-autoloader，但这不等于“去冗余”，只是减少加载开销
如何安全识别并移除真正未被使用的 require 包？
先确认这个包是否还在 composer.json 的 require 或 require-dev 里。如果在，就不是 Composer 认为的“冗余”，而是你项目显式依赖的——删之前必须验证代码中是否还有调用。
- 用
grep -r "use.*PackageName" . --include="*.php"或更准的phpstan/psalm扫描实际使用痕迹 - 临时注释掉
composer.json中某条"vendor/package": "^x.y"，再运行composer update vendor/package—— 如果报错Package vendor/package is not required in your composer.json，说明它已被移除；如果没报错且vendor/里也没它了，才表示成功卸载 - 执行
composer remove vendor/package（Composer 2.2+ 支持）等价于：从composer.json删除该行 + 运行composer update vendor/package，但它**不会检查代码里是否还用了这个包**
删完之后 vendor 目录残留文件怎么办？
正常情况下 composer remove 或 composer update 会自动清掉对应目录。如果发现 vendor/vendor-name/package-name 还在，大概率是：
- 该包被另一个已安装的依赖间接 require，所以 Composer 保住了它（查看
composer show -t vendor/package看谁依赖它） -
composer.lock还记着旧版本，导致vendor/没同步更新——删掉composer.lock和vendor/后重跑composer install - 你用了
composer install --ignore-platform-reqs或自定义 installers，导致某些包没走标准流程卸载
rm -rf vendor/ rm composer.lock composer install
真正难的是界定“无用”：一个包可能没被 PHP 代码直接调用，但被 Twig 模板、Webpack 构建脚本或 PHPUnit 数据提供器用到。别只盯着 use 语句，得结合整个构建和运行链路看。
