Composer update 默认使用 ~/.composer/cache 是因全局配置项 cache-dir 的默认值为此路径，该路径可修改且影响下载与解压效率。
Composer update 为什么默认用 ~/.composer/cache？
Composer 在执行 composer update 时，会把下载的包压缩包（.zip/.tar.gz）、安装后的 dist 包、以及某些元数据缓存在本地。默认路径是用户主目录下的 ~/.composer/cache，这是由 Composer 的全局配置项 cache-dir 控制的，不是硬编码，可以改。
这个缓存目录影响两个关键行为：一是重复 update 时是否跳过重新下载（靠比对 hash 和时间戳），二是 install 是否能快速解压已有 dist 包。改错位置或权限不对，会导致缓存失效、反复下载、甚至报 Failed to extract 错误。
修改 cache-dir 的三种可靠方式
- 直接写入全局配置：
composer config -g cache-dir /path/to/your/cache（推荐）。路径必须存在且当前用户有读写权限，否则后续命令会静默失败或回退到默认路径
- 手动编辑
~/.composer/config.json，添加或修改 "cache-dir": "/path/to/your/cache" 字段，然后运行 composer clear-cache 让新路径生效
- 临时覆盖（仅当次命令）：
COMPOSER_CACHE_DIR=/tmp/composer-cache composer update。注意环境变量名是 COMPOSER_CACHE_DIR，不是 COMPOSER_HOME 或其他
composer config -g cache-dir /path/to/your/cache（推荐）。路径必须存在且当前用户有读写权限，否则后续命令会静默失败或回退到默认路径 ~/.composer/config.json，添加或修改 "cache-dir": "/path/to/your/cache" 字段，然后运行 composer clear-cache 让新路径生效 COMPOSER_CACHE_DIR=/tmp/composer-cache composer update。注意环境变量名是 COMPOSER_CACHE_DIR，不是 COMPOSER_HOME 或其他 不要用 composer config cache-dir ...（不加 -g），那会写进当前项目的 composer.json，而项目级配置不控制全局缓存行为。
改完后怎么确认生效了？
运行 composer config -g cache-dir，输出应为你设置的路径；再执行 composer clear-cache，观察终端是否提示 “Clearing cache (…/your/cache)” —— 如果还显示 ~/.composer/cache，说明配置没写对或被其他配置覆盖（比如 COMPOSER_HOME 指向了别的地方）。
另外，检查新缓存目录下是否生成了 repo/、files/、vcs/ 子目录。如果只有空目录或权限拒绝日志，update 过程中就会绕过缓存，变慢且容易出错。
多用户或 CI 环境下的常见坑
- 在 Docker 或 CI 中，如果挂载了空 volume 到
/tmp/composer-cache，但没设好 uid/gid，Composer 可能因权限不足放弃写缓存，表现是每次 update 都重下所有包
-
cache-dir 路径不能是符号链接（尤其在 macOS 上用 ~/Library/Caches 时），Composer 会拒绝使用，回退到默认路径且不报错
- 不要和
COMPOSER_HOME 混用：前者只管缓存，后者决定 config.json、auth.json 等文件位置；改了 cache-dir 不影响认证凭据存放
/tmp/composer-cache，但没设好 uid/gid，Composer 可能因权限不足放弃写缓存，表现是每次 update 都重下所有包 cache-dir 路径不能是符号链接（尤其在 macOS 上用 ~/Library/Caches 时），Composer 会拒绝使用，回退到默认路径且不报错 COMPOSER_HOME 混用：前者只管缓存，后者决定 config.json、auth.json 等文件位置；改了 cache-dir 不影响认证凭据存放 真正起作用的是配置值本身是否可写、是否被正确加载，而不是路径看起来多“规范”。
