全局配置仅写入~/.composer/config.json但不保证生效，因项目级composer.json中repositories字段会完全覆盖全局配置；项目级配置才真正可控且行为一致。
全局配置只改 ~/.composer/config.json，不保证生效
全局配置本质是写进 ~/.composer/config.json 的一条记录，但它的作用范围非常有限：只要项目目录下存在 composer.json 且里面定义了 repositories 字段，全局配置就完全被忽略。不是“优先级低”，而是直接不读——Composer 不合并，只替换。
常见误判场景：
- 在项目里运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，以为能统一加速所有项目，结果composer install还是连packagist.org - CI 脚本里执行
composer config -g，但构建容器没初始化~/.composer目录，命令静默失败，根本没写入任何配置 - 宝塔面板用
www用户执行命令，却在root用户下配了全局镜像，两者配置文件互不可见
项目级配置写进 composer.json，才真正可控
项目级配置不是“可选优化”，而是唯一能确保行为一致的手段。它把镜像源明确写进 composer.json 的 repositories 字段，Git 提交后，谁拉代码、在哪跑，都走同一套源。
必须注意结构细节：
-
repositories必须是对象（{}），不是数组（[]）；如果已是数组，composer config repo.packagist ...会直接报错 - 键名必须是
"packagist"（单数），且值必须含"type": "composer"和以/结尾的 HTTPS URL - 若已有
"packagist.org": false，得先删掉，否则镜像配置会被屏蔽 - 改完必须运行
composer update --lock，否则composer.lock仍指向旧源地址
为什么 “全局 vs 项目分镜像” 是伪需求
Composer 没有“全局包走 A 镜像、项目包走 B 镜像”的机制。所谓 composer global install 安装的包，其依赖解析和 dist 文件下载，依然走当前命令执行时生效的镜像配置——不是独立通道，也不区分安装位置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
镜像源只控制元数据（packages.json、p2/xxx.json）获取路径，不代理 zip/tar 下载。dist 文件地址由包自身 composer.json 或 composer.lock 决定，镜像不干预。
真正需要分流的场景，只能靠：
- 为不同项目单独配
repositories - 用环境变量临时切源：
COMPOSER_REPO_PACKAGIST=https://mirrors.tencent.com/composer/ composer install - 脚本封装 + 目录隔离，而不是指望 Composer 自动识别命令类型
验证配置是否真生效，别信命令输出
运行 composer config -g repo.packagist 输出非空，不代表全局镜像就在用；运行 composer config repo.packagist 有值，也不代表项目实际走这个源——因为 composer config 只显示配置项，不反映最终生效逻辑。
可靠验证方式只有两个：
- 执行
composer install -vvv，看日志里请求的是哪个域名（搜Loading composer repositories后面的 URL） - 临时删掉
vendor/和composer.lock，再composer install，观察是否从镜像域名拉取元数据
最容易被忽略的是：换镜像后卡在 Resolving dependencies，那和镜像无关，是依赖图太复杂或版本约束太松，得查 composer.json 里的 require 写法，不是重配镜像能解决的。
