composer config -g 输出的是全局配置文件中显式写入的配置项，不含默认值或环境变量推导值；composer config -l -g 才显示最终生效的完整合并配置，含默认值、环境变量及配置文件内容。
composer config -g 输出的是什么
执行 composer config -g 显示的是全局配置文件（~/.composer/config.json）里**显式写入的配置项**，不包含默认值。它只告诉你“你手动改过哪些”，不是“当前生效的所有值”。比如你从没设过 bin-dir，这里就不会出现；但 composer config -l -g 会把它算进去，因为 Composer 自动推导出了路径。
为什么 composer config -l -g 和 composer config -g 结果不一样
composer config -l -g 展示的是全局作用域下最终生效的完整配置合并结果，含默认值、环境变量覆盖项、以及 ~/.composer/config.json 里的内容；而 composer config -g（不带 -l）只是简单列出该 JSON 文件里 key-value 对的原始集合。
- 想确认某项是否被你亲手写进全局配置 → 用
composer config -g - 想看全局下实际生效的
home、bin-dir、repo.packagist等完整值 → 必须用composer config -l -g - 输出里带
(global)标记的，说明这个值确实来自全局配置，不是项目或环境变量塞进来的
怎么验证 config 文件路径本身对不对
关键不是“有没有配置”，而是“Composer 到底读的是哪个文件”。运行 composer global config --list --verbose，第一行 Loaded config file: 后面的路径才是真实加载地址。常见错位：
- 误用
sudo composer global config→ 写进/root/.composer/config.json，但你日常是普通用户，根本读不到 -
COMPOSER_HOME设了但路径不存在，或含未展开的~或$HOME→ Composer 会静默 fallback 到默认路径，但你不知道 - Windows 下 Git Bash 里
%COMPOSER_HOME%大小写写成%composer_home%→ 变量不生效，又不报错
composer diagnose 里哪些行真有用
composer diagnose 不只是检查 PHP 扩展，它还会模拟运行时行为，其中两行最值得盯：
-
Repo packagist.org: https://mirrors.aliyun.com/composer/—— 这个 URL 必须和composer config -g repo.packagist的url字段完全一致（协议、域名、结尾/都不能差） -
Cache directory: /home/you/.composer/cache—— 如果这里路径异常（比如指向/tmp或空），说明COMPOSER_HOME或权限出问题，后续 install/update 都可能失败 - 它不会告诉你“配置写错了”，但会暴露“配置没被识别”：如果 Repo 行还是
https://packagist.org，哪怕config -g显示了镜像，也说明被更高优先级设置（如环境变量或项目级repositories）覆盖了
真正容易被忽略的是：诊断通过 ≠ 配置生效。它不校验 JSON 格式合法性，也不阻止你把 url 写成 "https://mirrors.aliyun.com/composer"（缺末尾 /），这种错只能靠 -vvv 日志里实际请求的 URL 暴露出来。
