roave/composer-unused 可识别未被代码引用的包，安装后运行 vendor/bin/composer-unused 即可报告疑似冗余包，需人工确认动态加载、CLI 工具等场景，不可依赖不存在的 composer show --unused。

如何用 composer unused 找出未被引用的包

Composer 本身不自带检测冗余依赖的功能，但社区工具 roave/composer-unused 能有效识别 vendor/ 中安装了却没在代码里 use、new 或调用的包。它扫描整个项目（含 src/、tests/ 等），比单纯看 composer.json 更可靠。

安装后运行：

composer require --dev roave/composer-unused</code><br><code>vendor/bin/composer-unused

它会列出所有疑似“死包”的名称，并标注是否被自动加载器注册、是否出现在 autoload 配置中。

• 注意：它不会误删，只做报告；若某包仅用于 CLI 工具（如 phpunit）或配置驱动（如 symfony/dotenv），需人工确认是否真冗余
• 某些包通过字符串动态加载（如 class_exists('Some\Class') 或 DI 容器反射），会被误判为未使用，要结合业务逻辑判断
• 建议搭配 --no-dev 参数跑一次生产环境视角：vendor/bin/composer-unused --no-dev

为什么 composer show --unused 不可用

很多人搜到 composer show --unused，但这个命令根本不存在——这是对 Composer 命令的常见误解。官方 composer show 只支持 -i（已安装）、--platform（PHP 扩展）等参数，没有内置冗余检测逻辑。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• Composer 的设计原则是“声明式依赖”，它只管按 composer.json 安装，不管代码里有没有用
• 所谓“未使用”是静态分析问题，必须借助外部工具，比如 roave/composer-unused 或 composer-require-checker
• 试图用 composer depends <package> 查谁依赖某个包，只能看到直接依赖链，无法反推该包是否被实际调用

删包前必须检查的三个地方

盲目 composer remove xxx 可能导致运行时错误，尤其在框架或插件生态中。删之前务必确认：

• composer.json 的 require 和 require-dev 是否真不需要它——有些包虽未直接调用，却是其他包的间接依赖（composer show -t 可查依赖树）
• 项目中是否存在 include/require 绝对路径引入（如 require __DIR__.'/vendor/autoload.php' 后又手动加载某类），这类写法绕过 Composer 自动加载，工具无法识别
• 是否被 PHP 扩展、.env 配置、CLI 脚本或部署脚本隐式依赖（例如 doctrine/migrations 可能只在部署时用，但代码里不出现）

composer update --with-dependencies 不等于瘦身

有人以为执行 composer update --with-dependencies 能清理无用包，其实它只是更新指定包及其子依赖，和“删除未用包”完全无关。真正瘦身的关键动作只有两个：识别 + 移除。

• composer update 默认只会更新已声明的包，不会自动卸载未声明的包（哪怕它们是旧版本残留）
• 如果曾手动 composer require 过测试工具但没加 --dev，它会留在 require 里，成为隐形膨胀源
• 定期运行 composer validate 和 composer outdated 是辅助手段，但不能替代冗余检测

实际项目里最常被忽略的是 autoload 配置残留：比如删了包却忘了从 composer.json 的 autoload 或 autoload-dev 中移除对应 psr-4 映射，会导致 composer dump-autoload 失败或产生无效扫描路径。