能改，但必须用绝对路径、带--global且含空格时加英文双引号；实际生效路径优先级为COMPOSER_CACHE_DIR环境变量＞全局config＞默认路径，需验证权限、存在性及非网络存储。
composer config --global cache-dir 改不了缓存目录？先确认路径是否合法
直接执行 composer config --global cache-dir /path/to/cache 失败，大概率是路径含非法字符、权限不足或用了绝对路径但没加引号。Composer 对缓存路径校验严格：路径必须可写，不能含未转义的空格或中文，且 cache-dir 值在全局配置中只接受绝对路径（相对路径会被忽略）。
常见错误现象：composer install 仍往默认位置（~/.composer/cache 或 %APPDATA%ComposerCache）写入；执行 composer config --global --list 看不到 cache-dir 条目；或报错 Failed to write config file。
- Linux/macOS 下务必用双引号包裹含空格路径：
composer config --global cache-dir "/home/user/my cache/composer" - Windows 下路径分隔符统一用正斜杠或双反斜杠：
composer config --global cache-dir "C:/Users/Alice/ComposerCache"或"C:\Users\Alice\ComposerCache" - 路径不能指向 NFS 或某些加密卷——Composer 会因
flock()失败静默回退到默认缓存 - 改完后运行
composer clear-cache，否则旧缓存仍被复用
为什么改了 cache-dir 后 composer update 还很慢？检查是否命中缓存
修改缓存目录本身不加速安装，只是换地方存包。真正影响速度的是缓存是否被有效复用。如果 composer update 依然下载大量包，说明新路径下没有对应包的缓存副本，或者 Composer 没识别到已有缓存。
验证方式：进新缓存目录看是否存在 repo/https---packagist.org/ 子目录及其中的 packages.json 和 .zip 文件；若为空，说明缓存未迁移，也未生成。
- Composer 不自动迁移旧缓存——需手动
cp -r ~/.composer/cache/repo ~/.cache/composer/repo（Linux/macOS）或用robocopy（Windows） - 若用私有仓库，确保新缓存路径下
repo/https---your-private-repo.com/目录存在且可写 - 执行
composer diagnose会提示Cache directory: ... is not writable，这是最常被忽略的权限问题
CI/CD 中临时改缓存路径：用 COMPOSER_CACHE_DIR 环境变量更可靠
在 GitHub Actions、GitLab CI 等环境中，用 composer config --global 写配置容易污染 runner 状态，且不同 job 间缓存路径可能冲突。此时应优先用环境变量临时覆盖。
COMPOSER_CACHE_DIR 优先级高于全局配置，且只作用于当前命令，无需清理、无副作用。
- GitHub Actions 示例：
env: COMPOSER_CACHE_DIR: ${{ runner.temp }}/composer-cache - GitLab CI 示例：
variables: COMPOSER_CACHE_DIR: "$CI_PROJECT_DIR/.composer-cache"
- Docker 构建时：
docker run -e COMPOSER_CACHE_DIR=/tmp/composer-cache composer install - 注意：该变量值必须为绝对路径，且容器内对应目录需提前
mkdir -p并chown到运行用户
缓存目录改完，vendor 目录和 autoload 还受影响吗？完全不影响
cache-dir 只控制 Composer 下载、解压、元数据解析阶段的中间存储位置，和最终 vendor 目录、autoload.php 生成逻辑完全隔离。改缓存路径不会触发 vendor 重建，也不需要删 vendor 或重跑 install。
唯一需要同步调整的，是 CI 脚本里显式清理缓存的命令——比如原来写 rm -rf ~/.composer/cache，现在得改成 rm -rf $COMPOSER_CACHE_DIR 或对应的新路径。
复杂点在于：某些老旧部署脚本会硬编码缓存路径做空间监控或日志归档，这类地方容易漏改，导致磁盘告警误报或清理失效。
