用 composer remove 卸载包是安全、推荐的方式，它会自动删依赖、更新 composer.json 和 composer.lock；手动删再 install 易留幽灵依赖或 autoload 残留，且 remove 严格校验依赖关系、不支持多包批量操作。
直接说结论：用 composer remove 卸载包是安全、推荐的方式，它会自动删依赖、更新 composer.json 和 composer.lock，比手动删再 composer install 更可靠。
为什么不能只改 composer.json 再 composer install
手动删掉 composer.json 里的包后运行 composer install，看似能卸载，但实际可能留下“幽灵依赖”——比如该包的子依赖没被其他包共用，却仍留在 vendor/ 里；或者它的 autoloader 映射还残留在 vendor/autoload.php 中，导致后续报 Class not found 错误但不提示来源。
-
composer remove会调用依赖解析器反向推导，精准移除整个依赖子图 - 它强制重写
autoload规则，清理vendor/composer/autoload_*.php - 如果包被其他已安装包 require（哪怕只是 dev-require），
remove会拒绝执行并报错，避免破坏依赖一致性
composer remove 基本用法和参数差异
最常用形式就是 composer remove vendor/package-name，例如卸载 Laravel 的测试工具：composer remove phpunit/phpunit。它默认只处理 require 区块；如要删 require-dev 里的包，必须加 --dev 参数：
-
composer remove doctrine/dbal→ 只删require中的 -
composer remove phpunit/phpunit --dev→ 只删require-dev中的 - 不支持同时删多个包（如
composer remove a/b c/d）——会报错，得逐个执行
注意：没有 --force 或 --ignore-platform-reqs 这类选项，它严格遵循当前环境约束。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
常见错误现象和应对
执行时遇到最多的是 Could not find package xxx in a version matching yyy，这通常不是包不存在，而是版本冲突或锁定问题：
- 先确认包名拼写是否完全匹配（包括大小写），可用
composer show列出已安装包 - 如果刚换过 PHP 版本或扩展，
composer.lock里记录的平台配置可能过期，先运行composer update --lock再试remove - 遇到
Package is not required in your composer.json？说明它可能通过其他包间接引入，此时得用composer depends vendor/package-name查谁在引用它，再决定是否先卸载上游
卸载后还要检查什么
composer remove 成功不代表万事大吉。最容易被忽略的是硬编码引用：
- 搜项目里所有
use语句和new XxxClass()调用，确认没残留对已卸载类的直接引用 - 检查
config/app.php（Laravel）、services.yaml（Symfony）等配置文件，删掉对应的 provider 或 service 定义 - 如果该包提供 Artisan 命令、Blade 指令或 Twig 扩展，对应命令行输入或模板语法会直接报错，得同步清理
这些地方不会被 Composer 自动感知，靠删包命令解决不了。
