挂载网络驱动器作Composer缓存目录会导致静默失效：不报错但反复下载、repo/files目录为空，因NFS/SMB不支持rename()等原子操作，引发Permission denied、JSON写入中断、多机写冲突损坏文件；composer diag仅校验路径存在性，不验证原子性，需用strace或检查子目录生成确认真实生效。
挂载网络驱动器当 Composer 缓存目录会出什么问题
直接把 NFS、SMB 或 Windows 共享盘映射为 COMPOSER_CACHE_DIR 路径，Composer 很可能静默失效——它不会报错，但每次 composer install 都像第一次运行：反复下载包、repo/ 目录空空如也、archived/ 下没 zip 文件。
根本原因是 Composer 依赖原子性文件操作（如 rename()、file_put_contents(..., LOCK_EX)），而多数网络文件系统不保证这些语义。常见表现包括：
-
file_put_contents(/mnt/nfs/composer-cache/repo/https---packagist.org/packages.json): failed to open stream: Permission denied（实际是 NFS 的锁机制不兼容） - JSON 元数据写半截就中断，后续读取时解析失败，触发重拉
- 多个机器同时写同一缓存目录，
repo/里出现损坏的packages.json或provider-*.json
为什么 COMPOSER_CACHE_DIR 指向网络路径后 composer diag 还显示“Cache directory: /mnt/nfs/xxx”
composer diag 只检查路径是否存在、是否可读，**不验证写入原子性或并发安全性**。只要目录存在且当前用户有基本写权限，它就判定“缓存可用”，然后在后台悄悄 fallback 到临时目录（通常是 /tmp）或直接禁用缓存。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证真实行为的方法只有两个：
- 执行
composer clear-cache && composer require monolog/monolog --no-install，立刻检查目标网络路径下是否生成了repo/和files/子目录（没有 = 没生效） - 用
strace -e trace=openat,write,unlink,chmod composer install 2>&1 | grep cache（Linux）看实际打开/写入的是哪个路径
多机器共享缓存的可行替代方案
真要跨机器复用下载结果，必须绕开“共享同一物理目录”的思路，改用服务化或分层策略：
-
CI/CD 场景：用构建平台自身的缓存机制（如 GitHub Actions 的
actions/cache、GitLab CI 的cache:关键字），把~/.composer/cache打包上传/下载，比挂 NFS 更可靠 -
开发机集群：每台机器用本地 SSD 缓存（
COMPOSER_CACHE_DIR=/ssd/composer-cache），再配一个轻量 HTTP 代理（如proxy-cache或自建nginx+proxy_cache），拦截对packagist.org的元数据请求和 dist 包下载 -
企业内网：部署私有 Packagist（如 Private Packagist、Satis 或 Artifactory），所有机器指向该源；缓存由服务端统一管理，客户端只需标准
composer config -g repo.packagist composer https://pkgs.internal
试图让 5 台不同用户的 Linux 机器共用一个 NFS 上的 /nfs/composer-cache，不出三天就会遇到 corrupted provider-2026-06.json 或 vendor/autoload.php not found ——这不是配置问题，是分布式文件系统与 Composer 写模式的根本冲突。
