缓存路径配置失败时 composer config -g cache-dir 输出为空，composer 2.x 会静默回退至默认路径；必须用严格格式设置并验证输出，否则 clear-cache 等操作仍作用于旧路径。
composer config -g cache-dir 输出为空或不是路径？
说明缓存路径根本没写进去，不是“不生效”，是配置失败。Composer 2.x 会静默 fallback 到默认路径（~/.composer/cache 或 %LOCALAPPDATA%\Composer\Cache），不报错也不提醒。
正确命令必须带 -g 且格式严格：
-
composer config -g cache-dir /path/to/my/cache（Linux/macOS） -
composer config -g cache-dir C:\MyCache（Windows，路径不能含空格或中文） - 执行后立刻验证：
composer config -g cache-dir应输出你刚设的完整路径，而非空或null - 若输出
Could not write to file，说明目标目录不存在或权限不足——先mkdir -p /path/to/my/cache并chown $USER:$USER /path/to/my/cache
缓存路径改了但 composer clear-cache 仍清旧位置？
因为 clear-cache 命令本身读取的是当前生效的 cache-dir 配置，如果配置没写成功，它就还在清默认路径。这不是命令 bug，是配置未落地的连锁反应。
实操建议：
- 先确认
composer config -g cache-dir输出是否正确；否则所有后续操作都无效 - 手动删掉旧缓存目录：
rm -rf ~/.composer/cache（Linux/macOS）或rd /s /q "%LOCALAPPDATA%\Composer\Cache"（Windows） - 再跑一次
composer clear-cache，观察终端输出的 “Clearing cache (X MB)” 是否指向你新设的路径 - Windows 用户注意：
%LOCALAPPDATA%展开后通常是C:\Users\Alice\AppData\Local\Composer\Cache，别和%APPDATA%混淆
CI/CD 中缓存路径被覆盖或权限拒绝？
常见于 GitHub Actions、GitLab CI 或宝塔面板：你用 root 配的全局 cache-dir，但实际运行的是 www 或 runner 用户，导致 Composer 启动时无法写入该路径。
关键点：
- 在 CI 脚本中，不要依赖本地配置，显式设置环境变量：
COMPOSER_CACHE_DIR=/tmp/composer-cache - 确保该路径存在且可写：
mkdir -p $COMPOSER_CACHE_DIR && chmod 777 $COMPOSER_CACHE_DIR - 避免跨用户复用缓存：不同 PHP 版本或 Composer 版本的缓存不兼容，混用会导致
JSON decode error或file_get_contents(): failed to open stream - Docker 场景下，挂载卷需匹配 UID/GID：
-v $(pwd)/.composer-cache:/tmp/composer-cache:z，并用user: "1001:1001"对齐
缓存路径生效了但 install 还卡在 Downloading？
这说明请求根本没走缓存，而是直接发往远程源——缓存只加速元数据（packages.json）和 zip 包下载，不改变源地址。卡住大概率是镜像配置或网络问题，和缓存路径无关。
快速定位方法：
- 加
-vvv看真实请求：composer install -vvv 2>&1 | grep -i "downloading\|http" - 检查是否被项目级
repositories屏蔽：composer config repositories若有输出，说明全局镜像已失效 - 确认没误配
repo.packagist（应为repositories.packagist.org）——Composer 2.2+ 已废弃单数形式，写错就静默忽略 - 缓存路径本身不影响网络行为，但若路径设在 NFS 或慢速盘上，可能拖慢解压速度，表现为“卡”而非“失败”
config -g 写的是一份配置，但真正执行 install 的可能是另一个 UID，路径存在也没用。
