多用户不能共享 composer 缓存目录，因缓存含 uid、php 版本、auth 加密上下文等用户专属哈希值，共用会导致权限冲突、校验失败、json 损坏及静默降级下载。
不能共享 Composer 缓存目录——强行让多个用户共用同一个 COMPOSER_CACHE_DIR 或 ~/.composer/cache，会导致权限冲突、缓存校验失败、JSON 元数据损坏，甚至 composer install 静默退回到临时目录重下包。
为什么多用户不能共享 cache 目录
Composer 缓存内容（如 repo/ 下的 packages.json、archived/ 里的 zip 包）内部包含与用户环境强绑定的哈希值，包括：
– 当前用户的 UID 和文件权限位
– PHP 版本、已加载扩展（如 openssl 版本影响签名验证）
– auth.json 中私有仓库 token 的加密上下文
多个用户写同一路径时，file_put_contents(..., LOCK_EX) 会因 NFS 或本地权限模型不一致而静默失败，composer diag 却仍显示 “Cache directory: /shared/cache” —— 它只检查路径存在性，不验证原子写入。
多用户机器上正确的缓存配置方式
每个用户必须拥有独立的缓存目录，但可通过统一策略降低维护成本：
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 为每位用户设置专属
COMPOSER_CACHE_DIR，例如在~/.zshrc中添加：export COMPOSER_CACHE_DIR="$HOME/.cache/composer" - 确保该路径存在且可写：
mkdir -p "$HOME/.cache/composer" && chmod 700 "$HOME/.cache/composer" - 统一镜像源（不跨用户）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 禁用全局
sudo composer global—— 否则会把包装进/root/.composer，普通用户无法执行其vendor/bin下的命令
CI/CD 或开发机集群中“类共享”的替代方案
真要复用下载结果，应放弃“挂载同一目录”的思路，改用服务化分层：
- 每台机器用本地 SSD 缓存：
export COMPOSER_CACHE_DIR="/mnt/ssd/composer-cache"（确保磁盘非 NFS） - 加一层 HTTP 缓存代理（如 nginx +
proxy_cache），拦截对packagist.org的GET /packages.json和 dist 包 URL 请求 - CI 流水线中用平台原生缓存机制：
GitHub Actions：缓存$HOME/.composer/cache路径，key 基于${{ hashFiles('**/composer.lock') }}
GitLab CI：用cache:关键字同时保存vendor/和$COMPOSER_HOME/cache/
最容易被忽略的一点是：即使所有配置都对了，如果缓存目录挂载在 NFS 上，或路径里有空格却没用符号链接绕过，Composer 就会完全跳过缓存——它不报错，只默默重下。验证是否生效，唯一可靠方式是删掉旧缓存后跑一次 composer require monolog/monolog --no-install，然后立刻检查目标路径下是否生成了 repo/ 和 archived/ 子目录。
