composer config --list 显示每项配置实际生效的文件路径，括号内路径即真实来源，优先级为 --config > COMPOSER_HOME > 系统默认路径（如 ~/.composer/config.json），项目 composer.json 的 config 字段仅影响行为不改变查找路径。
Composer 查找配置文件的路径不是靠“猜”或“默认值”，而是有一套明确的优先级顺序，且每层都可被覆盖。你改错位置，就等于没改。
composer config --list 显示的配置来源在哪
运行 composer config --list 时，每行配置项后面括号里的路径，就是它当前实际生效的位置。这个输出是唯一可信依据，别信文档里写的“默认在 ~/.composer/config.json”——它可能已被 COMPOSER_HOME 或命令行参数覆盖。
-
COMPOSER_HOME环境变量存在时，Composer 会优先读取$COMPOSER_HOME/config.json（Linux/macOS）或%COMPOSER_HOME%\config.json（Windows） - 没设
COMPOSER_HOME时，才回落到系统默认：Linux/macOS 是~/.composer/config.json，Windows 是%APPDATA%\Composer\config.json - 项目根目录下的
composer.json不算“配置文件”，它是项目依赖描述；但它的config字段会影响当前项目行为，不改变全局配置查找路径
为什么 composer config -g xxx 改了但不生效
根本原因是 -g（global）写入的是全局配置文件，但它不一定就是你当前看到的那个。常见断点：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 执行
composer config --global home，确认COMPOSER_HOME指向哪里；如果它指向/root/.composer而你用普通用户运行，那改的就是 root 的配置 - 检查是否在终端启动前设置了
COMPOSER_HOME，比如 shell 配置文件里有export COMPOSER_HOME="/tmp/composer"，那就完全绕过了默认路径 - Git Bash / WSL 用户注意：
COMPOSER_HOME在 Windows 和子系统中可能被分别设置，导致两边读不同配置
如何强制 Composer 使用指定配置文件
不用改环境变量或动默认路径，直接用 --config 参数指定即可，适合 CI、临时调试或隔离场景：
- 读取自定义配置：
composer install --config=/path/to/my-config.json - 该文件必须是合法 JSON，且结构与标准
config.json一致（不能只写一个字段） - 命令行传入的
--config优先级最高，会覆盖COMPOSER_HOME和默认路径下所有配置 - 注意：此参数不改变
composer config -g的写入目标，只是本次运行时覆盖
Windows 下 %APPDATA% 路径解析失败的真实原因
PowerShell 中 %APPDATA% 不自动展开为真实路径，导致 Composer 找不到配置文件，表现为 Could not open input file: composer.phar 或静默跳过 global 配置。
- 验证方式：在 PowerShell 中运行
$env:APPDATA，看输出是否为完整路径（如C:\Users\Alice\AppData\Roaming） - 若为空或报错，说明环境变量未继承，常见于从 GUI 启动的终端（如 VS Code 集成终端）
- 临时修复：在 PowerShell 中手动设置
$env:COMPOSER_HOME = "$env:APPDATA\Composer" - 长期方案：在系统环境变量中显式定义
COMPOSER_HOME，避免依赖%APPDATA%解析
配置路径本身不复杂，难的是它被多层环境变量、shell 初始化逻辑和跨平台差异悄悄劫持。每次怀疑配置没生效，第一反应不该是重装 Composer，而是先跑一遍 composer config --list，盯着括号里的路径看——那里写着真相。
