composer remove 不适用于“一键清理”，仅处理声明层和 autoload 映射，不扫描代码、配置或动态加载，大规模重构必须分批删（每次1–3个）、验证（测试+dump-autoload+opcache重置）、闭环（交叉验证require关系与隐式引用）。
composer remove 命令是否适用于大规模重构场景
适用，但必须分批、验证、闭环，不能当作“一键清理”工具。它只处理声明层和 autoload 映射，不扫描代码、不识别配置引用、不校验运行时动态加载——这些恰恰是大规模重构中最容易翻车的地方。
常见错误现象：执行 composer remove monolog/monolog 后 CI 通过，上线却在某个日志上报路径里抛出 Class not found；或 Laravel 的 config/logging.php 仍引用 MonologHandlerStreamHandler，但类文件已删，报错不直接指向配置文件。
- 每次最多删 1–3 个包，避免依赖图震荡过大
- 必须配合自动化测试（哪怕只有 smoke test）验证核心链路
- 删完立刻运行
composer dump-autoload -o，否则旧 PSR-4 映射可能缓存生效 - 若项目启用了 OPcache，需额外执行
opcache_reset()或重启 PHP 进程
如何判断一个包在重构后“真无用”而非“暂时没调用”
不能只看当前 grep -r "Monolog\" src/ app/ 是否命中——重构中常有“先删依赖、再改调用”的中间态，此时代码里还留着 use，但逻辑已被注释或替换。真正要交叉验证三处：
-
composer why vendor/package-name：输出为空才表示无上游 require（注意：--dev包需加--dev参数查） -
composer show --tree | grep -A5 vendor/package-name：确认它不在任何保留包的子树中 - 人工扫 config/、app/Providers/、database/migrations/、.env 中所有字符串形式的引用（如
'driver' => 'monolog'）
特别注意：Laravel 的 Service Provider、Symfony 的 Bundle、Doctrine 的 Event Subscriber 都不靠 new 或 use 显式出现，而是通过字符串注册，composer-unused 工具基本无法覆盖。
批量移除多个包时为什么不能写成 composer remove pkg1,pkg2
因为 composer remove 不接受逗号分隔，也不支持引号包裹——它把 pkg1,pkg2 当作一个包名，必然报错 Package "pkg1,pkg2" is not required。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
正确写法是空格分隔：composer remove spatie/laravel-permission laravel/sanctum nunomaduro/collision。这个命令是原子操作：任一包被其他包依赖，整个命令回退，不会删掉前几个。
- 失败时会明确提示哪个包被谁 require，例如
Root package "laravel/sanctum" cannot be removed because it is required by "laravel/framework" - 如果想跳过保护机制强行删，可用
--with-dependencies，但风险极高——它会连带删掉你显式 require 的子依赖（如guzzlehttp/promises），而上游包可能仍硬编码依赖它 - 删
require-dev包时，必须显式加--dev，否则默认只操作require，命令看似成功，实际没动 dev 区
删完之后 vendor 目录还有残留，是不是命令失败了
不是失败，是设计行为。composer remove 默认只标记待卸载，不立即物理删除 vendor 子目录；真正清理由后续 composer install 或 composer update 触发。
跳过这步直接部署，会导致两个静默问题：
-
vendor/composer/autoload_classmap.php里还存着旧类路径，类能加载但实际文件已不存在，某些边缘路径下才暴露 -
vendor/monolog/monolog/目录残留，CI 构建时可能误判为“已安装”，影响安全扫描或体积统计
所以必须补一步：composer install（推荐）或 composer update --lock && composer install。若担心版本漂移，可先 git stash 当前 composer.lock，执行后再 git stash pop 比对差异。
真正麻烦的从来不是删包本身，而是那些没写在 composer.json 里、却活在 app/ 目录下对旧包的隐式调用——它们不会报错，只会在某个边缘路径里突然抛出 Class not found。
