composer config -g repo.packagist 总不生效是因为三个硬性条件缺一不可：键名必须为单数 repo.packagist、第二个参数必须显式写 composer（type 值）、url 必须 https 且末尾带 /；任一错误即静默回退官方源，验证需输出完整 json 对象。
composer config -g repo.packagist 为什么在多项目下总不生效
根本不是镜像地址或网络问题，而是命令本身漏了三个硬性条件：键名必须是 repo.packagist（单数），第二个参数必须显式写 composer（这是 type 值，不能省略或替换成 https 等），URL 必须是 HTTPS 且末尾带 /（例如 https://mirrors.aliyun.com/composer/✅，少斜杠会拼出 /composerpackages.json 导致 404）。任一错误，Composer 就静默 fallback 到 https://packagist.org，且不报错、不提示。
验证是否真写进去了，只看这一行输出：composer config -g repo.packagist。必须返回类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON；返回空、null、Key not found，或只输出原始 URL 字符串，都说明失败。
项目级配置才是多项目环境的可靠解法
全局配置（-g）只写入当前用户的 ~/.composer/config.json，而多项目环境下，不同项目可能由不同用户运行（比如宝塔用 www、CI 用 runner、Docker 用非 root 用户），它们根本读不到你的配置文件。
真正能跨项目、跨环境一致生效的方式，是把镜像声明直接写进每个项目的 composer.json：
- 进项目根目录（确保有
composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 该命令会自动向
composer.json的repositories字段安全追加，key 固定为"packagist" - 如果原
"repositories": []是数组格式，命令会报错；需先手动改成"repositories": {}（空对象）再重试 - 已有私有源（如
"type": "vcs"）时，该命令会追加到数组末尾，不会覆盖
改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update），否则旧 lock 文件仍指向官方 dist URL。
repositories 数组顺序和 packagist.org 的显式处理
Composer 的 repositories 是线性短路匹配：按数组顺序逐个请求，第一个返回包信息的源就生效，后面的全跳过。只要项目里定义了 repositories，Composer 就默认禁用 packagist.org——这不是 bug，是设计行为。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
不显式处理，composer require monolog/monolog 会直接报 Could not find package。
安全写法是：
-
repositories必须是索引数组（[]），不能写成键值对对象（{}） - 镜像源放第一位（如阿里云、腾讯云）
- 私有 Git 源等放中间
- 末尾必须加
{"packagist.org": true}（不是{"type": "composer", "url": "https://packagist.org/"}）——它只用于元数据兜底查询，ZIP 包仍从你排第一的镜像拉
type 值选错也会导致包“消失”："type": "composer" 才支持完整索引服务；"type": "vcs" 只查单个仓库 tag，不参与顺序匹配逻辑。
CI/CD 和 Docker 中镜像不走的排查重点
你在本地终端配好了 composer config -g，但 GitHub Actions、宝塔、Docker 构建时依然走官方源，核心原因是：它们运行命令的用户跟你的终端用户不一致。
常见场景和对应动作：
- 宝塔：PHP-FPM 通常以
www用户运行，得用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - GitHub Actions：在
.github/workflows/xxx.yml的 setup 步骤里加run: composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker：在
Dockerfile中RUN这条命令，并确保以目标用户（如USER www）身份执行 - 更稳妥的做法是放弃全局配置，统一用项目级配置 + 提交
composer.json到 Git，所有环境自然一致
换源后卡在 Resolving dependencies 或 Loading composer repositories，90% 不是镜像问题，而是缓存残留或 composer.lock 未重建——镜像只加速元数据和 ZIP 下载，完全不参与依赖解析过程。
