必须用composer validate区分锁文件状态：报“The lock file is not up to date”为过期，执行composer update --lock即可；报“./composer.lock is invalid”带行号为真损坏，需备份后重建；不报错但install提示corrupted多因dist.sha256校验失败。

composer validate报“is invalid”带行号才是真损坏

看到composer install失败，别急着删composer.lock。先跑composer validate看输出：

• 报The lock file is not up to date → 锁文件只是过期，执行composer update --lock即可，不碰vendor/
• 报./composer.lock is invalid并带具体行号（如Parse error on line 42）→ 真损坏，常见于断电后文件截断、含<<<< HEAD或空字节
• 不报错但composer install提示Invalid lock file. Corrupted. → 多半是dist.sha256校验失败，说明锁里记录的哈希和实际包不匹配

真损坏时该删哪些、留哪些

断电后vendor/和composer.lock都可能不完整，恢复路径取决于vendor/状态：

• 如果vendor/存在且没手动删过（比如解压已完成），先备份cp composer.lock composer.lock.bak，再运行composer update --lock——它只重写lock，不动vendor
• 如果vendor/已被删、目录里有空文件夹、或vendor/composer/installed.json是空文件 → 必须清掉全部：rm -rf vendor composer.lock，再跑composer install --no-cache
• 千万别用composer update替代——它会查远程最新版，可能升级一堆包，彻底偏离原依赖状态

为什么必须加--no-cache

断电后本地缓存（~/.composer/cache）里可能存着损坏的 zip 包或截断的元数据。composer install默认会复用它们，导致反复失败。

Workflow Decomposer

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

下载

--no-cache强制跳过本地缓存，从镜像源重新拉取原始包，避免“用坏数据装坏包”的死循环。

flock失败不是内核问题，是文件或权限不对

报flock ./composer.lock failed，不是 Composer 或 Linux 内核版本的问题，而是：

• composer.lock不存在，或权限不足（ls -l composer.lock确认可写）
• 在 NFS、WSL2 挂载的 Windows 路径（如/mnt/c/）、Git for Windows 的 MSYS2 环境下，flock()本身就不支持
• CI 中新分支首次构建时，composer.lock还没被提交，得先从稳定分支复制一份

真正影响锁文件行为的，从来不是内核版本，而是文件是否存在、是否可写、挂载方式是否支持 POSIX 锁。