composer config 命令可直接修改项目或全局配置，无需手动编辑 composer.json；它支持设置、删除、查询配置项，但需注意 repo.packagist 仅接受布尔值，换镜像须先禁用再添加自定义仓库。
直接用 composer config 命令改配置，不用手动编辑 composer.json
Composer 提供了原生命令行接口来读写配置项，核心就是 composer config。它能修改全局（-g）或当前项目（默认）的配置，比如仓库源、缓存路径、平台版本模拟等。改完立刻生效，下次运行 composer install 或 composer update 就会按新配置走。
常见错误现象：有人手动改 composer.json 里的 config 字段，但忘了运行 composer dump-autoload 或误以为必须重装依赖——其实完全没必要；还有人把 config 和 repositories 混用，结果镜像没切成功。
- 改当前项目的配置：
composer config <var>key</var> <var>value</var>，例如composer config platform.php 8.1.0 - 删某项配置：
composer config --unset <var>key</var>，比如composer config --unset discard-changes - 查当前值：
composer config <var>key</var>（不带 value），如composer config repo.packagist - 加
-g参数操作全局配置（影响所有项目），例如composer config -g repo.packagist https://packagist.phpcomposer.com
repo.packagist 配置必须设为 false 才能禁用官方源
很多人想换国内镜像，执行 composer config repo.packagist https://mirrors.aliyun.com/composer/，结果发现 composer update 还是连 packagist.org —— 因为这个字段不是“替换源”，而是“是否启用官方源”。它只接受布尔值或 false，设成 URL 是无效的，Composer 会忽略并回退到默认行为。
正确做法是：先禁用官方源，再加自定义仓库。
- 禁用官方源：
composer config repo.packagist false - 添加阿里云镜像：
composer config repositories.packagist composer https://mirrors.aliyun.com/composer/ - 注意
repositories.xxx的xxx是你起的别名，不能叫packagist（会冲突），建议用aliyun或phpcomposer - 验证是否生效：
composer config repositories应该输出带新仓库的对象，且repo.packagist为false
修改 cache-dir 后旧缓存不会自动迁移
改缓存路径（比如从默认 ~/.composer/cache 指向 SSD 分区）很常见，但 composer config cache-dir /path/to/new/cache 只影响后续操作，之前下载的包、zip 文件、元数据全留在老位置，既浪费空间又可能引发混淆。
性能影响明显：如果新路径在机械盘或网络盘，composer update 速度会断崖式下降；反之，迁移到 NVMe 能提速 2–3 倍。
- 改完
cache-dir后，手动把旧缓存整个复制过去：cp -r ~/.composer/cache/* /path/to/new/cache/ - Linux/macOS 下确认权限一致，尤其
github-api目录的 owner 和 group - Windows 用户注意路径分隔符，
composer config cache-dir D:\composer-cache必须用正斜杠或双反斜杠 - 改完建议跑一次
composer clear-cache，再composer update --dry-run看是否走新路径
PHP 平台版本模拟（platform）只影响依赖解析，不改变运行时
用 composer config platform.php 8.0.0 是为了让 Composer 在安装时假装当前环境是 PHP 8.0，从而允许装那些声明 "php": "^8.0" 的包——但它不会真的降级你的 PHP，也不会影响 vendor/autoload.php 加载逻辑。
容易踩的坑：有人在 CI 中设了 platform.php，本地开发却用 PHP 8.2，结果运行时报 Attribute 或 match 语法错误，以为配置生效了；其实这只是安装阶段的“兼容性协商”，和实际执行无关。
- 仅对
require和require-dev中的包版本约束起作用 - 不影响
autoload规则、PSR-4 映射、classmap 生成 - 若同时设了
platform.ext-xxx（如platform.ext-gd），记得值填true或false，不能留空 - CI 中推荐用
--ignore-platform-req=php替代全局platform，更精准
改配置本身很简单，难的是理解每个键的实际作用域——比如 repo.packagist 是开关，repositories.xxx 才是容器；platform 只管装包时的决策，不管运行时行为。漏掉这些隐含规则，命令敲得再熟也没用。
