项目级repositories数组必须是数组且首项为{"packagist.org": false}，因Composer 2.2+硬编码官方源，仅写镜像URL无法禁用其静默fallback；该开关须为独立数组项，否则镜像404或超时后仍会回退到packagist.org，导致包来源不一致、行为不可预测。
团队开发中，靠每个成员自己配全局镜像，本质上是把环境一致性押在“人不犯错”上——这不可控，也不该由人来兜底。
为什么项目级 repositories 数组必须是数组，且首项为 {"packagist.org": false}
Composer 2.2+ 把 packagist.org 当作硬编码权威源，仅靠写个镜像 URL 不会禁用它；必须显式声明 {"packagist.org": false} 作为独立数组项，才能切断回退路径。否则 Composer 在镜像 404 或超时后，会静默 fallback 到官方源，导致部分包走镜像、部分走 packagist.org，行为不可预测。
-
"repositories"必须是数组（[]），不是对象（{}）；写成对象会被忽略 - 第一项必须是
{"packagist.org": false}，不能合并进第二项（如{"packagist.org": false, "type": "composer", "url": "..."}是无效的） - 第二项起才是镜像源，
url值必须以/结尾，例如https://mirrors.aliyun.com/composer/，少斜杠会导致请求路径拼接错误（如/composerpackages.json），返回 404 后 fallback
改完 composer.json 后，为什么还要删 vendor 和 composer.lock？
composer.lock 里记录的是每个包的完整 dist URL（比如 https://api.github.com/repos/monolog/monolog/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（不是update），让 Composer 从头解析依赖、生成适配新镜像的 lock 文件 - CI/CD 流水线中要确保缓存策略不保留旧
vendor或composer.lock，否则每次构建都沿用旧路径
如何防止全局镜像污染项目行为？
只要项目 composer.json 中定义了 repositories 数组，Composer 就会彻底忽略全局的 repo.packagist 配置。但问题在于：有人可能在全局配了镜像，又在项目里写了另一个镜像，结果部分命令（如 composer require）因上下文不同读取逻辑不一致，引发混用。
- 建议团队统一执行：
composer config --global --unset repo.packagist，清空所有成员的全局 Packagist 镜像设置 - 验证是否清空：
composer config --global repo.packagist输出应为空或https://packagist.org（即恢复默认） - CI 脚本开头加一句
composer config --global --unset repo.packagist，防止单独配置残留 - 私有 VCS 源（如 GitLab 私库）不受影响，因为它们是
type: "vcs"，和repo.packagist无冲突
临时调试时，--repository-url 参数怎么用才安全？
当怀疑镜像配置失效、或需快速验证某镜像可用性时，绕过所有持久化配置最可靠。该方式不修改任何文件，执行完即失效，适合排查和 CI 临时覆盖。
- 在项目根目录运行：
composer install --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/ - 创建新项目时验证：
composer create-project topthink/think demo --repository-url=https://mirrors.aliyun.com/composer/ - 注意：该参数只作用于当前命令，不写入配置；也不能替代
{"packagist.org": false}的禁用逻辑，若镜像本身未禁用官方源，仍可能 fallback
真正麻烦的从来不是“换哪个镜像快”，而是镜像配置被误写、被覆盖、被缓存，导致同一行命令在不同机器上走不同网络路径——这种差异藏在 silent fallback 里，很难 debug。把 repositories 写死在 composer.json，并强制所有人删 lock 重装，是唯一能堵住这个漏洞的做法。
