flock失败需先区分是文件不存在/权限不足还是Windows句柄占用：前者应确保composer.lock存在且可写，后者需关闭IDE、Web服务器等占用进程。
直接删锁文件或强杀进程不是正解，得先分清是“flock系统锁”还是“Windows文件句柄占用”——两者成因、现象和解法完全不同。
flock ./composer.lock 失败：文件不存在或权限不足
报错类似 Cannot open lock file 或 No such file or directory，说明 flock 根本没拿到文件描述符。这不是并发冲突，而是前提条件缺失。
-
composer.lock当前不存在（比如 CI 新分支首次构建、刚git checkout但未提交）——应先从main分支复制一份干净的composer.lock - 文件存在但不可写：
ls -l composer.lock看权限，若为只读或属主是root，需chmod u+w composer.lock或chown $USER:$USER composer.lock - Docker 场景下注意挂载卷是否设为
ro，或容器内 UID/GID 与宿主机不匹配导致写失败 - 更鲁棒的替代方案是锁
.git目录：flock .git -c 'composer install'（前提是.git存在且可访问）
flock 在 NFS/WSL2/Windows 上完全失效
报错 Could not lock file /path/to/composer.lock，但文件可读可写、权限正常——大概率是底层不支持 POSIX flock()，比如 NFS 挂载、WSL2 的 /mnt/c/ 路径、Git for Windows 的 MSYS2 环境。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
df -T .查看挂载类型：若显示nfs或nfs4，flock本质无效 - WSL2 用户请把项目移到
/home/xxx/下，避开 Windows 盘符挂载路径 - CI 场景优先用平台原生锁机制，如 GitHub Actions 的
concurrency、GitLab CI 的interruptible: false+ job-level lock - 实在无法换环境，退而求其次：禁用插件 + 预生成 lock，即只跑
composer install --no-interaction --no-plugins --optimize-autoloader，不触碰 lock 文件
Windows 下 vendor 文件被占用导致覆盖失败
报错 Permission denied 或 Could not delete，常见于 composer install --force-reinstall 中途卡住。根本不是权限设置问题，而是文件正被其他进程持有。
- 关掉所有 PHP 进程（Swoole、Xdebug）、Web 服务器（Laravel Sail、Valet）、IDE（PhpStorm 的索引服务）
- 在 PhpStorm 中禁用 “Synchronize files on frame activation”
- 改用 PowerShell 执行精准清理：
Remove-Item -Recurse -Force vendor\some-package，避免全局删vendor - 仍失败？重启终端（CMD/PowerShell），或临时加
--prefer-dist减少对符号链接的依赖（Windows 默认禁用 symlinks）
为什么 --no-interaction 不能解决并发冲突
很多人误以为加了 --no-interaction 就能安全并发执行 composer install，实际完全无效。
- 该参数只跳过交互提示，不改变文件读写顺序，也不提供原子性保障
- 多个进程同时写
vendor/、同时重建 autoload、同时跑post-install-cmd，必然竞争 - 真正可靠的并发控制必须依赖外部锁机制（
flock、CI 平台锁、或目录级互斥），而不是靠 Composer 参数“假装安静”
最常被忽略的一点：flock 锁的是打开的文件描述符，不是文件路径本身；而 Windows 文件句柄锁定发生在内核层，连 flock 都没机会介入。判断错误类型，比急着删文件或加 sudo 重要得多。
