composer status 显示“modified”未必是手动修改代码，常见原因包括依赖包安装后自动生成文件（如 Symfony 缓存）、Git 忽略规则未覆盖 vendor 临时文件、或使用 --no-scripts 导致 post-install-cmd 未执行；-v 可查看具体差异文件。
composer status 显示“modified”却没改代码？
这是最常被误读的提示——composer status 报 modified，不代表你手动改了 vendor 里的文件，很可能是依赖包自身在安装后执行了生成操作（比如 Symfony 的缓存写入、Laravel 的 storage/framework 写入），或 Git 忽略规则没覆盖 vendor 下的某些临时文件。
- 运行前先确认当前目录是项目根目录（含
composer.json），否则会报错或返回空 - 默认只检查
vendor/下已由 Composer 安装的包，不检查你自己require-dev里带path类型的本地包（它们会被跳过） - 若用
composer install --no-scripts装过，某些包的 post-install-cmd 可能没执行，导致生成文件缺失，也会被识别为 “modified” - 想看具体哪些文件被标为 modified，加
-v参数：composer status -v
composer status 和 composer update 的关系是什么？
composer status 不修改任何东西，它只是比对 vendor/ 当前状态与 composer.lock 记录的哈希值。而 composer update 会重算依赖、下载新版本、更新 composer.lock，并重写 vendor/ —— 两者目的完全不同，不能互相替代。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 当你怀疑依赖被意外篡改（比如 CI 环境里有人手改了 vendor），用
composer status是最快验证手段 - 如果
status显示 clean，但应用行为异常，问题大概率不在 vendor 文件完整性，而在环境变量、配置加载顺序或缓存未清 - CI 流程中建议加一行：
composer status || { echo "vendor modified!"; exit 1; }，防人为误操作污染构建产物
为什么有时 status 没输出、直接退出？
这通常不是 bug，而是 composer status 默认静默成功——只有发现差异时才打印内容并返回非零退出码（1）。没有输出 ≠ 没运行，只是当前 vendor/ 和 composer.lock 完全一致。
- 检查退出码最可靠：
composer status; echo $?，输出0表示 clean，1表示有 modified 或 error - Windows CMD 下
%ERRORLEVEL%才是等效检查方式，PowerShell 用$LASTEXITCODE - 某些旧版 Composer（
vendor 中部分包显示 “untracked”，怎么处理？
“untracked” 意味着这个包不在 composer.lock 里，但它的文件出现在 vendor/ 目录下——常见于手动 git clone 到 vendor、或用 composer require --dev 后又删了 composer.json 里对应行但没删 vendor。
- 先运行
composer validate，确认composer.json结构合法，避免因语法错误导致解析失败 - 用
composer show查看实际加载了哪些包，对比composer.json的require和require-dev - 安全清理方式是：
rm -rf vendor && composer install，而不是单独删某个 untracked 包——否则可能破坏 autoload 映射 - 如果你确实在用
path类型仓库，确保composer.json里写了"type": "package"或启用了repositories配置，否则会被当成 untracked
composer.lock 中每个包的 dist.shasum 字段，而不是 Git commit hash 或文件 mtime。哪怕你把整个 vendor 提交进 Git，只要 lock 文件没更新，status 就永远认为它是 clean 的。 
