直接运行 composer config --global cache-dir 输出的路径即为当前生效的 composer 缓存根目录，它优先于 ~/.composer/cache 和环境变量 composer_cache_dir，是唯一可信依据。
怎么查当前生效的 Composer 缓存路径
直接运行 composer config --global cache-dir，它输出的就是 Composer 实际读写的缓存根目录。Linux 上默认是 ~/.composer/cache，但这个值可能被环境变量 COMPOSER_CACHE_DIR 覆盖，或被公司镜像脚本悄悄改过——命令结果才是唯一可信依据。
常见误判是直接进 ~/.composer/cache 看大小，结果发现里面空空如也。这时大概率是 COMPOSER_CACHE_DIR 指向了别处（比如 /tmp/composer-cache），而你删错了地方。
- 确认是否被环境变量覆盖：
echo $COMPOSER_CACHE_DIR - 验证路径是否存在且可写：
ls -ld $(composer config --global cache-dir) - 看真实占用：
du -sh $(composer config --global cache-dir)
改缓存路径前必须检查的三件事
用 composer config --global cache-dir /new/path 改路径看似简单，但失败常发生在执行之后——不是命令没跑，而是后续 install 直接报错。
- 目标路径必须已存在：
mkdir -p /new/path，不能靠 Composer 自动创建 - 当前用户要有完整读写权限：
chown $USER:$USER /new/path，尤其当之前用过sudo composer时，旧缓存里可能混着 root 权限文件 - 绝对路径，不支持波浪号：
/home/user/cache✅，~/cache❌（Composer 不解析 shell 符号）
改完后立刻验证：composer config --global cache-dir 输出应与你设置的一致，且 ls -l $(composer config --global cache-dir) 不报 permission denied。
为什么改完路径后 composer install 还往老地方写
最常见原因是 PHP 进程没读到新配置，尤其是用了 opcache 或 CLI SAPI 缓存了 Composer 的全局配置加载逻辑。更隐蔽的是某些 CI/CD 环境或容器中，composer 命令其实是 shell wrapper，内部硬编码了缓存路径。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 重启终端或重新登录，确保环境变量刷新
- 检查是否有 wrapper 脚本：
which composer→ 如果输出是/usr/local/bin/composer，再cat /usr/local/bin/composer看是否含COMPOSER_CACHE_DIR=... - 临时强制指定：
COMPOSER_CACHE_DIR=/new/path composer install，能绕过配置读取逻辑，快速验证路径是否真生效
如果强制指定后正常，说明问题出在配置加载环节，而不是路径本身。
缓存目录结构变了，旧缓存要不要手动迁移
不需要。Composer 不会自动迁移旧缓存，也不需要你手动搬 files/、repo/、vcs/ 子目录。新路径下首次 install 会从头拉包、生成元数据、解压 ZIP —— 旧缓存留在原地，完全无影响。
但要注意：如果你刚在旧路径下跑过 composer update，又切到新路径，composer.lock 里记录的 dist URL 可能仍指向旧镜像源（比如 packagist.org），导致下载慢或失败。此时建议同步换源：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。
vcs/ 目录是隐形磁盘杀手，单个 Git 裸仓库就能占几百 MB 并耗尽 inode。如果旧缓存里有大量 vcs 内容，而你又不打算再用它，手动删掉更省事：rm -rf ~/.composer/cache/vcs/* —— 这步跟改路径无关，但值得顺手做。
