Composer的cache目录可安全共享，因只存ZIP包和元数据；而temp目录不可共享，因其为运行时工作区，多项目并发会引发解压中断、autoload生成错乱、版本解析漂移等问题。
不行，多个项目共用 Composer 临时文件目录（如 cache、temp）在技术上虽能运行，但会引发缓存污染、元数据错乱和构建不可复现等实际问题——这不是配置建议，而是故障前置条件。
为什么 COMPOSER_CACHE_DIR 能共享，但 COMPOSER_TEMP_DIR 不能
Composer 的 cache 目录（默认 ~/.composer/cache）设计为全局共享：它只存 ZIP 包和 repo 元数据，不绑定具体项目，且 composer install --prefer-dist 默认复用这些文件，安全高效。而 temp 目录（默认在系统临时路径下，如 /tmp/composer）是运行时工作区，用于解压、校验、生成 autoload 映射等操作——多个项目并发执行 composer install 时，会争抢同一临时子目录，导致：
- 解压中途被另一个项目的
rm -rf清空，报file not found in archive或corrupted zip - 不同项目的
composer.json中minimum-stability不一致，却共用同一临时元数据缓存，造成版本解析结果漂移 - Docker 多阶段构建中，若多个
RUN composer install共享 temp，第二阶段可能读到第一阶段残留的未完成解压树
强行共用 temp 的典型错误现象
你不会立刻看到报错，但会遇到这些“玄学”问题：
-
composer install在 CI 上偶发失败，本地重试却成功（因 temp 目录竞争时机不同） - 同一个
composer.lock，在机器 A 安装后vendor/autoload.php正常，机器 B 却报Class not found（autoload 生成被中断或覆盖） -
composer update后，vendor/composer/installed.json缺少部分包条目（临时目录里某包的composer.json被覆盖写入）
真正可行的替代方案：隔离 temp，复用 cache
你要的不是“共用”，而是“加速 + 可控”。正确做法是：
- 让每个项目使用独立
temp目录：通过环境变量COMPOSER_TEMP_DIR=$PWD/.composer-temp指向项目内路径（确保该目录存在且可写），彻底避免竞争 - 保留全局
cache：不改COMPOSER_CACHE_DIR，让它继续复用已下载的 dist 包——这是 Composer 唯一被设计为共享的部分 - CI 环境中加一层防护：在
composer install前执行mkdir -p .composer-temp && chmod 700 .composer-temp，防止权限继承问题 - 验证是否生效：运行
composer config --global temp-dir应为空；composer config temp-dir应输出项目级路径
别碰 COMPOSER_HOME 下的 temp 子目录
有人试图把 COMPOSER_HOME 设为项目目录来“统一管理”，这等于把 auth.json、config.json、cache、temp 全塞进项目根——后果是：auth.json 可能被误提交，temp 再次变成多项目共享，且 composer global 工具会失效。真正的隔离粒度是“每个项目一个 temp”，而不是“把所有 Composer 状态挪进项目里”。
