最准验证方式是执行composer config -g repo.packagist，输出必须为完整JSON（如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）；若为空、报错或仅字符串，则配置失败，常见因键名错误、URL缺斜杠或项目级repositories覆盖全局。
composer config -g repo.packagist 必须写对，否则镜像根本不会生效——不是慢，是压根没走国内源。
验证当前生效的镜像地址是否正确
很多人改完配置就跑 composer install，结果日志里还是出现 https://packagist.org/packages.json。真正有效的判断方式只有一种：composer config -g repo.packagist 输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
- 输出为空、
null或报Key does not exist，说明配置失败，常见原因是键名写成repos.packagist（多一个s） - 输出是字符串而非 JSON（如仅
https://mirrors.tuna.tsinghua.edu.cn/composer/），新版 Composer 允许，但需确认末尾有/ - 项目根目录存在
composer.json且含"repositories"字段，它会完全屏蔽全局配置；此时应运行composer config repo.packagist（不带-g）查项目级设置
强制刷新元数据，别只清缓存
composer clear-cache 只删 ZIP 包和 provider 缓存，不影响 packages.json 元数据复用逻辑。Composer 默认 15 分钟内复用本地元数据，哪怕镜像已更新也不会重拉。
- Composer ≥ 2.5：用
composer update --refresh，丢弃所有缓存的packages.json，强制从当前镜像源重新下载索引 - Composer rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
- 临时调试可用
composer install --no-cache -v，终端输出的真实请求 URL 会暴露是否命中你配的镜像地址
项目级配置比全局更可靠，尤其在 CI 和团队协作中
全局配置写在 ~/.composer/config.json，但宝塔、Docker、GitHub Actions 等环境默认以非 root 用户运行，根本读不到该文件。项目级配置写进 composer.json，拉代码即生效，行为一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），命令会自动追加到"repositories"数组，不破坏原有私有源 - 切忌手动编辑
composer.json时写成"packagist": false，这会导致基础包（如php、ext-json）校验失败 - 改完后务必删掉
vendor/和composer.lock，再执行composer install，否则旧 lock 文件仍指向海外源哈希
镜像不解决依赖解析卡顿，别指望它加速 Resolving dependencies
镜像只加速元数据拉取和 ZIP 包下载，对依赖解析阶段毫无帮助。如果卡在 Resolving dependencies，和网络无关，典型原因有：
-
composer.json中写了过宽的 PHP 版本约束，比如"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"，求解器暴力尝试组合 - 设置了
"minimum-stability": "dev"，强制拉取不稳定分支，候选版本数爆炸 -
composer.lock被删或未提交，install实际退化为update，触发全量解析 - 项目
repositories中存在已下线的私有源，Composer 逐个超时才 fallback
真正容易被忽略的是：换源之后，composer.lock 里记录的仍是旧源的哈希值，直接复用必然报 hash does not match —— 这时候删 lock 文件重装不是“折腾”，而是必须步骤。
