Composer不提供分布式文件锁，多节点并发install到共享vendor目录会导致写入冲突；必须通过预构建+只读分发规避，或用Redis等外部工具实现跨节点安装锁。
Composer 本身不提供分布式文件锁机制，composer install 在多节点并发执行时，若共享同一 vendor 目录（比如 NFS 或网络挂载卷），会因文件竞争导致解压失败、autoload 损坏或部分包被覆盖——这不是“重复解压”的问题，而是**并发写入冲突**。
为什么不能靠 Composer 自带逻辑解决集群并发
Composer 的安装流程默认假设 vendor 是本地独占目录：它先检查包是否已存在，再决定跳过或解压。但在 NFS 等共享文件系统上：
-
file_exists()和mkdir()不是原子操作，两个节点可能同时判断“目录不存在”，然后都尝试创建，后者失败并中断 -
unzip或tar解压过程没有跨节点互斥，同一包可能被两个进程同时写入相同路径 -
composer.lock虽然锁定版本，但不锁定安装动作本身；install不做分布式协调，也不支持 lock 文件级的租约机制
真正可行的部署方案：隔离 + 预构建 + 只读分发
放弃让多个节点直接运行 composer install 到共享目录。正确做法是把依赖安装变成单点预构建步骤：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在 CI 构建机（或专用构建节点）上运行
composer install --no-dev --prefer-dist --optimize-autoloader，生成完整vendor - 将整个
vendor打包为 tar.gz 或镜像层，通过 rsync / object storage / Docker image 分发到各集群节点 - 各节点解压后设为只读：
chmod -R 444 vendor/（Linux/macOS）或attrib +R vendor\（Windows），防止运行时意外修改 - 若需热更新，走蓝绿发布：新版本
vendor解压到独立路径，再原子切换软链接
如果硬要共享 vendor 目录，必须加外部锁
仅当基础设施不允许预构建（如遗留系统强制要求现场安装），才考虑用外部工具协调：
- 用 Redis 实现简易分布式锁：在
composer install前获取composer:install:lock键，超时设为 300 秒，释放由脚本保证 - 避免用文件锁（如
flock），NFS 对flock支持极差，且无法跨主机生效 - 锁粒度必须是整个安装过程，不是单个包——因为
autoload重建和脚本执行（如post-install-cmd）也需串行 - 失败后必须清理残留（如半解压目录），否则下次锁释放后仍会因目录结构异常而报错
关键点在于：Composer 不是为共享存储设计的。所谓“分布式文件锁”不是配置开关能打开的功能，而是需要你主动规避并发场景，或引入外部协调层。最常被忽略的是——即使加了锁，vendor 在 NFS 上的 stat、rename、symlink 等操作依然可能因缓存不一致而失败，这比锁本身更难调试。
