Composer config -g repo.packagist 命令没生效是因为未同时满足三个硬性条件：键名必须为单数 repo.packagist、type 值必须显式写 composer、URL 必须 HTTPS 且末尾带斜杠，任一缺失即静默回退官方源。
composer config -g repo.packagist 命令为什么没生效
90% 的“配了还是慢”问题，根源就在这条命令写错了——它不报错，但静默回退到 https://packagist.org。必须同时满足三个硬性条件：
• 键名只能是 repo.packagist（不是 repos.packagist、packagist.org 或其他变体）
• composer 是必需的 type 参数，不能省略
• URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，少斜杠会拼成 /composerpackages.json 导致 404
验证镜像是否真正生效的三步检查
别只看命令有没有执行成功，要确认 Composer 实际请求的是哪个域名：
• 运行 composer config -g repo.packagist，输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或仍是官方地址说明没写进去
• 执行 composer diagnose，检查 Repo 行是否显示镜像域名
• 加 -vvv 运行 composer install，日志里出现的下载地址应为 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn，而不是 packagist.org
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置比全局更可靠，尤其在 CI 和团队协作中
全局配置容易因用户权限不一致（比如宝塔用 www 用户跑命令，而 -g 写的是 root 的 ~/.composer/config.json）或被环境变量覆盖。项目级配置直接写进 composer.json，拉代码即生效：
• 进入项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加 -g）
• 它会自动向 repositories 字段插入或合并 "packagist" 条目，不破坏已有私有源
• 改完必须运行 composer update --lock，否则 composer.lock 里仍存着旧的 dist.url，下载时还会先试一次境外地址
换镜像后仍卡在 Resolving dependencies 怎么办
镜像只加速下载环节（Downloading、Fetching package），不解决依赖解析慢的问题。如果 composer update 卡在 Resolving dependencies 超过 10 秒，大概率是：
• composer.lock 陈旧，或 require 版本约束太宽（如 "^2.0"），触发深度回溯
• 某个包的 dist.url 在镜像中暂未同步（新发布包可能延迟几分钟），curl -I https://mirrors.aliyun.com/composer/p2/vendor/package.json 返回 404 就能确认
• 优先用 composer install 恢复已有锁文件，而非无意义地 update；真要更新，加 -vvv 看卡在哪一步，再针对性调整版本约束
composer update --lock 这一步——哪怕全局镜像已生效，只要 composer.lock 里还存着旧链接，下载时仍会先发一次境外请求。 
