composer config -g repo.packagist 命令易因拼写错误（如 repos.packagist）、缺 composer 类型参数、URL 末尾缺 / 或漏 -g 而静默失效；正确写法为 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，验证需 composer config -g repo.packagist 输出 JSON 或 URL，且须 composer update --lock 生效。
composer config -g repo.packagist 命令为什么总不生效
不是镜像源不行，是命令写错一个字符就静默回退到 packagist.org，且完全不报错。
-
repo.packagist不能写成repos.packagist（多一个 s 就彻底失效） - 必须显式指定
composer作为 type 参数：正确写法是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉composer会当成 URL 直接存错字段 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌——少斜杠会导致路径拼成/p2//类似错误，返回 404 - 必须加
-g：漏掉就只改当前目录的composer.json，换个项目就失效
验证是否成功：运行 composer config -g repo.packagist，输出应为完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）或至少是该 URL 字符串；若为空、null 或仍显示 https://repo.packagist.org，说明根本没写进去。
项目级配置如何避免覆盖私有仓库
项目根目录下已有 "repositories" 字段时，手动编辑 composer.json 极易格式出错或误删原有源。用命令让 Composer 自动合并更安全。
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 如果原
composer.json是"repositories": {}，命令会转为标准数组并插入packagist条目 - 如果原
"repositories"是数组（如含私有 Git 源），命令会向末尾追加新项，不破坏已有结构 - 千万别手写
"packagist.org": false或"packagist": false——这会让基础扩展（如ext-json）校验失败，直接报错
改完务必运行 composer update --lock，否则 composer.lock 仍记录旧源地址，下载时实际不走镜像。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
怎么确认镜像真在用？-vvv 是唯一可信证据
不加 -vvv 的日志只显示 “Downloading xxx”，不暴露域名，无法判断是否走镜像。只有 -vvv 能看到真实 HTTP 请求地址。
- 运行
composer install -vvv 2>&1 | grep "Downloading"，观察 URL 域名是否为mirrors.aliyun.com或你配置的镜像域名 - 临时绕过所有自定义源验证：
composer install --no-plugins --repository=https://packagist.org，如果这时反而快了，说明是项目级repositories配置覆盖了全局镜像 - 检查生效源优先级：
composer config --list | grep repositories，看输出里带项目路径的行，即实际接管的源 - 运行
composer diagnose，关注 “Repo packagist.org:” 后面是否为你设的镜像地址
换镜像后还是卡在 Resolving dependencies？别怪网络
镜像只加速 Downloading 阶段，对依赖解析无任何帮助。卡在这一步，和镜像无关，是本地约束或环境问题。
- 常见诱因：
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束，会让求解器暴力遍历所有组合 -
"minimum-stability": "dev"强制拉取不稳定分支，候选版本数爆炸 -
composer.lock被删或未提交，install实际退化为update，触发全量解析 - 项目
composer.json中repositories指向已下线私有源，Composer 逐个超时才 fallback
快速定位：执行 composer install -vvv，盯住日志里最慢那行——如果是 Resolving dependencies 卡住超过 5 秒，就该收紧版本约束、禁用 xdebug、清理缓存，而不是再折腾镜像。
