composer config -g在团队中不可靠，因其仅写入当前用户独立的~/.composer/config.json，Git不跟踪、CI容器无该路径、宝塔/Docker用户配置隔离，且无法审计回滚；项目级需用数组格式repositories，首项{"packagist.org": false}禁用官方源，镜像URL末尾必须带/，并删除vendor与composer.lock后执行composer install --no-cache。
为什么composer config -g在团队里根本不可靠
它只写进当前用户的~/.composer/config.json，而 Git 不跟踪这个文件，CI 环境（GitHub Actions、GitLab CI）启动的是干净容器，压根没这个路径；宝塔用www用户跑命令，Docker 里可能是runner或www-data，它们读的配置文件彼此完全隔离。
更隐蔽的问题是：某人本地执行了composer config -g repo.packagist composer https://packagist.org，整个团队立刻退回到官方源——没人知道谁动了全局配置，也没法审计或回滚。
常见失败现象包括：Loading composer repositories卡住十几秒、composer install仍走api.github.com、新人 clone 后首次安装慢得像爬行。
repositories必须是数组，且首项必须是{"packagist.org": false}
Composer 2.2+ 把packagist.org硬编码为兜底源，光写个镜像 URL 不会禁用它。只有显式声明{"packagist.org": false}作为独立数组项，才能切断回退路径。
必须满足这几点才真正生效：
-
repositories字段必须是数组（[]），不能是对象（{}），否则整个字段被忽略 - 第一项必须是
{"packagist.org": false}，不能合并到第二项里（比如{"packagist.org": false, "type": "composer"}无效） - 第二项起才是镜像源，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} -
url末尾必须带/，少一个斜杠会拼成/composerpackages.json导致 404
改完composer.json后，vendor/和composer.lock必须一起删
composer.lock里存的是每个包的完整 dist.url（比如https://api.github.com/.../zipball/），它是旧源下生成的哈希快照。Composer 安装时优先读 lock 文件，完全不重新解析repositories——哪怕你刚加了镜像，它仍按 lock 里写的地址去下载。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
所以必须执行：
rm -rf vendor composer.lock- 再运行
composer install --no-cache（不是update） -
composer update会复用旧 lock 中的元数据，无法触发新镜像的元数据拉取
CI 脚本里漏掉这一步，缓存会复用旧 lock，构建结果不可控，而且问题难以复现。
私有源怎么共存不冲突
已有 Git 私有包或企业 Nexus 源时，不能直接用composer config repo.packagist命令，它会清空整个repositories字段。
正确做法是手动编辑composer.json，确保结构如下：
"repositories": [
{"packagist.org": false},
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"},
{"type": "vcs", "url": "https://gitlab.internal/my/package"}
]
顺序不影响解析，但{"packagist.org": false}必须是第一项；私有 VCS 源放在后面即可，无需额外禁用或特殊处理。
注意：config.platform也建议精确到 PHP 小版本（如"php": "8.1.25"），避免因平台差异导致依赖解析不一致——这点常被忽略，却直接影响多机环境下的可复现性。
