composer-unused 命令未找到需全局安装 composer-global require composer-unused/composer-unused 并将对应 bin 目录加入 PATH；扫描漏判因 autoload 未覆盖 tests/ 等目录，需手动配置；--no-dev 不影响 require-dev 包的“dev-only”标记，可白名单跳过；删包前须检查 class_exists 等动态加载及全量测试。
composer-unused 找不到命令？先确认是否全局安装
运行 composer-unused 报错 command not found，大概率是没装对位置。它不是 Composer 官方插件，不能用 composer global require 直接装（新版 Composer 会拒绝非 Composer 官方源的全局包）。必须用 composer global require composer-unused/composer-unused，且确保 ~/.composer/vendor/bin（Linux/macOS）或 %APPDATA%Composer endorin（Windows）已加入系统 PATH。
- 装完后执行
which composer-unused或where composer-unused验证路径是否生效 - 如果项目里用
vendor/bin/composer-unused，得先composer require --dev composer-unused/composer-unused - 别用
sudo composer global require，权限混乱会导致后续命令找不到二进制文件
扫描结果全是“used”？检查 autoloading 配置是否覆盖到测试/命令类
composer-unused 默认只分析 autoload 和 autoload-dev 声明的命名空间 + 入口文件（如 bin/ 下脚本），不会自动扫描 tests/、commands/ 或 src/Command/ 这类未被 autoload 映射的 PHP 文件。结果就是：你明明在 tests/FeatureTest.php 里用了 monolog/monolog，但扫描显示 “unused”。
- 手动把测试目录加进
autoload-dev.ps4的"psr-4"或"classmap"里（例如"Tests\": "tests/"） - 如果项目有 artisan 命令、Symfony console 命令，确保它们的类路径也被 autoload 覆盖，否则依赖会被误判
- 不推荐临时加
"files"引入单个文件——它会让整个扫描变慢，且容易漏掉动态加载的类
为什么 vendor/bin/composer-unused --no-dev 仍显示 dev 依赖？
--no-dev 只控制是否加载 autoload-dev 部分，**不影响依赖声明本身的来源判断**。只要某个包出现在 require-dev 区块里，即使它被生产代码直接 use，composer-unused 也会标记为 “dev-only”，并默认归为“可删”。这不是 bug，是设计逻辑：它认为 dev 依赖不该被主代码链路依赖。
- 想让
phpunit/phpunit这类工具包不被扫出来？把它从require-dev移到require—— 但要小心循环依赖风险 - 更稳妥的做法是加白名单：
composer-unused --whitelist="phpunit/phpunit,doctrine/instantiator" - 注意：白名单只跳过检测，不改变依赖用途判断；如果某包既在
require又在require-dev，它仍会被视为 production 依赖
删完依赖后 vendor/autoload.php 报错 Class not found？
直接 composer remove xxx/yyy 后跑测试失败，常见原因是：该包提供的是运行时必需的 trait、interface 或抽象基类，而 composer-unused 只静态分析 use 和 new，没法识别 class_exists()、interface_exists() 或反射调用。
- 删之前先跑
grep -r "class_exists.*xxx|interface_exists.*xxx" . --include="*.php" - 检查是否有
if (class_exists('SomeClass')) { ... }这种防御式加载逻辑 - 某些包（如
symfony/polyfill）虽无显式use，但被框架底层通过function_exists检测调用，删了会崩
静态分析永远有盲区，删依赖前务必跑全量测试 + 关键业务路径验证，尤其留意异常处理、序列化、事件监听器这类隐式依赖场景。
