“could not lock file”真因是文件系统不支持flock()原子锁，非权限问题；高发场景包括wsl2的/mnt/c/、docker bind mount未指定user、macos外接ntfs盘、ci并发写vendor；验证用touch test.lock && rm test.lock，失败即确认底层i/o不可靠。
Composer卡在“Could not lock file”怎么定位真因
这不是权限问题，而是底层文件系统不支持 flock() 原子锁。报错里那个路径（比如 /path/to/composer.lock）只是被选中的“受害者”，真正的问题藏在挂载方式里。
先确认是否踩中高发场景：
- WSL2 用户正在
/mnt/c/下开发 →flock()默认失效 - Docker 容器把宿主机目录 bind mount 进来，且没指定
user:→ UID 映射断开 - macOS 项目放在
/Volumes/外接 NTFS 盘上 → Unix 权限模型压根不生效 - CI 流水线多个 job 并发写同一份
vendor/→ 锁竞争，不是单机问题
验证方法：在报错目录下执行 touch test.lock && rm test.lock。失败就说明文件系统连基础写删都不可靠，composer install 必然卡住。
别删lock文件，先用 composer validate 分清过期还是损坏
composer validate 是唯一能快速区分两类问题的命令，它不联网、不读包、500ms 内出结果。
三种典型输出对应不同处理：
-
The lock file is not up to date→ 过期，运行composer update --lock同步即可 -
JSON decode error at line X→ 真损坏，备份后删掉composer.lock，再根据vendor/是否完整决定下一步 - 只提示
./composer.json is valid→composer.lock根本不存在或被.gitignore屏蔽了
注意：composer install 在 lock 缺失时不会静默重建——v2.5+ 直接报错 Command "install" is not defined，旧版行为不可控。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer install --force-reinstall 覆盖安装的适用边界
这个命令不是万能解药，它只在 lock 文件完好、vendor 目录结构完整但内容异常时有效。
典型适用场景：
- Windows 下 IDE 占用
vendor/导致部分包解压失败，重启 PHP 服务后仍残留脏状态 - CI 构建中途中断，
vendor/里混入半成品目录，但composer.lock没变 - 想重跑所有
post-install-cmd脚本（如生成配置、清理缓存），又不想升级依赖
不适用场景：
-
composer.lock已被手动改过 → 哈希校验失败，命令直接退出 - 本地
composer.json新增了包但没更新 lock →--force-reinstall会报错，拒绝执行 - WSL2/NFS 环境下即使加了参数，
flock()仍不可用 → 会卡在 Generating autoload files 阶段
修复后必须验证文件系统层是否真支持 Unix 权限
很多用户 chown -R $USER:$USER vendor/ 后以为万事大吉，结果下次 composer update 又卡住——因为 chown 在 WSL2 的 /mnt/c/ 或 Docker bind mount 下根本无效。
关键验证动作只有两个：
- 在目标目录运行
touch test-perm && rm test-perm，成功才代表基础 I/O 可靠 - 检查
df -T .输出的文件系统类型：nfs、9p（WSL2 默认）、ntfs都是危险信号
一旦确认不支持，换路径是唯一出路：~/projects（WSL2）、user: "1001:1001"（Docker）、~/Sites（macOS），别试图用 chmod 777 或反复 sudo 掩盖问题。
