项目级repositories必须首项为{"packagist.org": false}，因Composer 2.2+硬编码官方源，仅配镜像URL会触发静默fallback；改composer.json后须删vendor和composer.lock再install，否则仍按旧lock文件下载。
因为不一致的镜像会导致同一 composer.lock 在不同环境解析出不同包来源，进而触发静默 fallback、404 后回退到 packagist.org、甚至装出不同版本的间接依赖——这不是“可能”，而是 Composer 2.2+ 的确定行为。
为什么项目级 repositories 必须显式禁用 packagist.org
Composer 2.2+ 把 packagist.org 当作硬编码权威源，仅配置镜像 URL 不会关闭它。一旦镜像响应慢或返回 404（比如少写了末尾 /），Composer 就会自动 fallback 到官方源，导致：
- 开发机走阿里云镜像，CI 构建时却从
api.packagist.org下载，超时卡住 - 部分包来自镜像，部分来自海外源，
composer.lock记录的 dist URL 混杂，破坏可复现性 - 私有包和公开包混合时，fallback 行为不可控，调试困难
正确写法必须是 "repositories" 数组，且首项为 {"packagist.org": false}，第二项才是镜像源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
改了 composer.json 为什么还要删 vendor 和 composer.lock
composer.lock 里存的是每个包的完整 dist URL（例如 https://api.github.com/.../zipball/），它是在旧镜像或无镜像配置下生成的。Composer 安装时优先读 lock 文件，完全不重新解析 repositories 配置。
- 只改
composer.json就跑composer install→ 仍按 lock 里写的地址下载，根本不会走新镜像 - 只跑
composer update→ 可能重算依赖树，引入意外升级，破坏生产一致性 - 必须执行：
rm -rf vendor composer.lock && composer install，强制重建锁文件和依赖树
CI/CD 中镜像配置为什么不能靠 composer config -g
容器环境通常挂载空 /root/.composer 或 /tmp/composer，composer config -g 写入的配置在构建结束后即丢失；更麻烦的是，不同基础镜像对 $HOME 路径处理不一致，导致命令执行但未生效。
- Dockerfile 中写
RUN composer config -g repo.packagist ...→ 镜像层不可追踪、无法审计、易被覆盖 - 推荐做法：CI 脚本开头加
composer config --global --unset repos.packagist清除干扰，再靠项目级repositories主导 - 验证是否生效：运行
composer install --dry-run 2>&1 | grep "mirrors.aliyun.com"，看到域名才确认走镜像
真正关键的不是“用了镜像”，而是“所有环境都以相同方式禁用 fallback、相同路径解析 lock、相同条件触发重装”。漏掉任一环节，一致性就断在某个构建节点上。
