flock ./composer.lock失败的直接原因是composer.lock文件缺失或当前用户无写权限；需先用ls -l确认文件存在及权限，ci首次构建应从main分支复制lock文件，nfs/wsl2等不支持posix锁的环境应改用.git目录锁或平台原生并发控制。
composer.lock 不存在或不可写导致 flock 失败
报错 flock ./composer.lock: Cannot open lock file 或 No such file or directory，说明 composer.lock 文件压根没生成，或虽存在但当前用户无写权限。这不是配置问题，是锁机制的前置条件不满足。
先确认文件状态：ls -l composer.lock。若输出为空，说明文件缺失；若权限为 -r--r--r--（只读），或属主是 root，就无法加锁。
- CI 首次构建新分支时最常见：
composer.lock尚未提交，应从main或stable分支复制一份干净的再运行flock - Docker 环境中检查挂载卷是否设为
ro，或容器 UID/GID 与宿主机不匹配 - Git 忽略了
composer.lock？查.gitignore是否误写了该文件
flock 在 NFS/WSL2/Windows 路径下根本无效
报错 Could not lock file /path/to/composer.lock，但文件可读可写、权限正常——大概率是底层文件系统不支持 POSIX flock()，比如 NFS 挂载、WSL2 的 /mnt/c/、Git for Windows 的 MSYS2 环境。
运行 df -T . 查看挂载类型：若显示 nfs 或 nfs4，flock 就是摆设。
- WSL2 用户必须把项目移到
/home/xxx/下，避开/mnt/c/ - CI 场景优先用平台原生锁：GitHub Actions 用
concurrency，GitLab CI 用interruptible: false+ job 级锁 - 实在不行，退而求其次：部署时只跑
composer install --no-interaction --no-plugins --optimize-autoloader，跳过锁和脚本执行
--no-interaction 不解决并发冲突
很多人以为加了 --no-interaction 或 --prefer-dist 就能避免并发 install 冲突，其实完全无效。这些参数只控制交互提示和下载方式，不改变文件读写顺序，也不提供原子性保障。
冲突根源是多个进程同时读旧 composer.lock → 各自解析依赖 → 并行写 vendor/ → 最后都尝试覆盖写回 composer.lock。Composer 自身没有版本戳或哈希校验机制，install 阶段默认跳过写前比对。
- 真正有效的串行化必须发生在 shell 层：用
flock或其他 OS 级锁阻塞对composer.lock的写入路径 - 不要依赖 Composer 参数“假装”串行，那只是掩耳盗铃
- CI 中若一个 repo 触发多个 job（如 PR 和 push 到 main），必须靠外部锁机制隔离
锁整个 .git 目录比锁 composer.lock 更鲁棒
当 composer.lock 不稳定（比如被 git clean 清掉、或 CI 临时删掉重生成）时，直接锁它容易失败。更可靠的做法是锁项目根目录下的 .git 目录——只要项目是 git 克隆的，.git 就一定存在且可访问。
命令示例：flock .git -c 'composer install'。它利用 .git 目录本身的排他性，规避了 composer.lock 缺失或权限错位的问题。
- 注意：
.git目录不能是符号链接，否则flock可能失效 - 如果项目不用 git（比如纯 tar 包解压），可新建一个空目录（如
.composer-lock-guard）并锁它 - 这个技巧在 CI 模板里很实用，比反复检查
composer.lock存在性更省事
最容易被忽略的点是：flock 锁的是打开的文件描述符，不是文件路径本身。所以即使你 chown 修好了权限，如果文件系统不支持 flock，或者锁目标被符号链接绕过，照样失败。别只盯着权限看，先确认锁机制是否真的生效。
