composer config --global cache-dir 输出的是 composer 当前实际使用的缓存根目录，读取自全局配置文件，未配置时回退至平台默认路径；但环境变量 composer_cache_dir 优先级更高且不在此命令中体现。
composer config --global cache-dir 能直接查到当前生效路径
这条命令输出的就是 Composer 实际在用的缓存根目录，不是默认值，也不是猜测值。它读的是 ~/.composer/config.json（Linux/macOS）或 %APPDATA%\Composer\config.json（Windows）里已写入的配置，没配过就回退到平台默认路径。
常见错误是运行 composer config cache-dir（不带 --global），这查的是项目级配置——而缓存路径几乎从不在项目 composer.json 里设，所以大概率返回空或报错。
- 必须加
--global才查对地方 - 如果输出为空，说明没显式配置过，走默认路径：
~/.composer/cache（Linux/macOS）或%APPDATA%\Composer\cache（Windows） - 环境变量
COMPOSER_CACHE_DIR优先级更高，但config --global cache-dir不会显示它；要确认是否被覆盖，得额外运行echo $COMPOSER_CACHE_DIR（Linux/macOS）或echo %COMPOSER_CACHE_DIR%（Windows）
为什么 composer diagnose 不能替代查缓存路径
composer diagnose 会检查缓存目录是否存在、是否可写，但它不告诉你路径是什么。它只报错，比如 Cache directory does not exist 或 Cache directory is not writable，但不会输出具体路径。
你得先知道路径在哪，才能去建目录、改权限。靠 diagnose 反推路径，等于让程序替你猜，效率低还容易误判。
-
diagnose是验证工具，不是查询工具 - 它看到缓存目录不可写时，可能是因为
cache-dir指向了/tmp/composer-cache，但该路径实际不存在——而你根本不知道这个路径从哪来的 - CI 环境中常因挂载失败导致缓存路径指向空目录，
diagnose报错后，仍需回到config --global cache-dir确认真实值
查路径时最容易忽略的三个干扰项
缓存路径不是静态的，它会被多层机制覆盖，只看 config --global cache-dir 还不够，得顺手排除干扰。
-
COMPOSER_CACHE_DIR环境变量：只要它非空，就会直接生效，config命令查不到，但composer install -vvv日志开头会打印Loading config from COMPOSER_CACHE_DIR - 项目级
composer.json中的"config": {"cache-dir": "..."}：极少见，但一旦存在，会覆盖全局配置；可用composer config cache-dir单独查（不带--global） - Docker 或 CI 中的用户 UID 不匹配：比如容器内以 UID 1001 运行，但缓存目录属主是 UID 1000，
config显示路径正确，实际却因权限被拒而静默失效
确认路径后，下一步该做什么
查到路径只是起点。真正关键的是立刻验证它是否真实可写、且内容结构符合预期。
Linux/macOS 上建议连着跑两行：
composer config --global cache-dir ls -ld $(composer config --global cache-dir)
Windows 上对应：
composer config --global cache-dir dir "%APPDATA%\Composer\Cache"
- 如果
ls -ld或dir报“no such file”，说明路径不存在，composer install会失败，得手动mkdir -p并赋权 - 如果能看到
files/、repo/、vcs/子目录，说明缓存机制已在运行；若只有空目录，可能是刚清过缓存，或之前一直没成功写入过 - 别跳过这步：很多“缓存不生效”问题，根源就是路径存在但无写权限，或者目录被 IDE/杀软锁住
