镜像只影响“能看到哪些版本”，不改变^和~的解析逻辑；composer的^和~由本地semver解析器计算，镜像仅提供元数据副本，同步延迟会导致实际安装版本低于预期，验证需用composer show -a查看镜像所见版本。
镜像只影响“能看到哪些版本”，不改变^和~的解析逻辑
Composer 的 ^ 和 ~ 版本约束完全由本地 composer/semver 解析器计算，镜像不参与任何版本判断。它只决定你「能查到哪些可用版本」——比如写 "monolog/monolog": "^2.8"，但阿里云镜像还没同步 v2.9.0，composer update 就只会升到 v2.8.4，不是约束失效，是元数据没刷新。
常见误判：看到没升到最新版就改约束，结果换镜像后发现原写法完全正确。验证方法很简单：composer show -a monolog/monolog 列出的版本，就是当前镜像所见的全部候选集，不是 Packagist 全量。
换镜像后 composer update 仍装旧版？先看锁文件和元数据缓存
镜像再快，也绕不过 composer.lock 的硬锁定。如果 lock 文件里记着 "version": "1.1.5"，而 composer.json 写的是 "^1.2.0"，composer install 依然装 1.1.5 —— 它只认 lock。
-
composer clear-cache只删已下载的 ZIP 包，不影响元数据缓存（即packages.json索引） - 必须手动删掉
~/.composer/cache/repo/下对应镜像的整个子目录（如https---mirrors.tuna.tsinghua.edu.cn-composer） - 加
-vvv参数重试：composer require monolog/monolog:dev-main -vvv，观察日志里请求的 URL 是否含镜像域名、状态码是否 200
composer update --lock 根本不读镜像配置
这个命令不联网、不查镜像、不更新 dist.url 或哈希值，只重写 composer.lock 的元数据字段（如 content-hash、platform）。哪怕你刚配好阿里云镜像，跑完 composer update --lock，lock 里所有包的 dist.url 还是原始 GitHub 地址——这不是 bug，是设计如此。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正让 lock 记录走镜像的，是 composer install 或 composer update 下载时的行为。换镜像后若想彻底生效，必须清空 vendor/ 和 composer.lock，再重新 install。
私有包和项目级配置容易被忽略的关键点
全局镜像（composer config -g repo.packagist）对私有包无效。报 Could not find package acme/utils，99% 是因为没在项目 composer.json 的 repositories 字段里显式声明源地址。
微服务或团队项目更推荐项目级配置：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g），它会自动写入 composer.json 的 repositories 数组，Git 提交后 CI 也能用，避免权限或路径导致的静默失效。
注意顺序：repositories 数组靠前的源优先匹配；私有源建议放后面，否则可能意外覆盖开源包。
