composer config -g repo.packagist 总不生效是因为键名必须为 repo.packagist（非 repos.packagist）、type 值 composer 不可省略、URL 必须 HTTPS 且末尾带 /，三者缺一即静默回退官方源；验证需输出完整 JSON 或正确 URL，空、null 或仍显示 packagist.org 说明未写入。
composer config -g repo.packagist 命令为什么总不生效
不是命令没运行，是三个硬性条件漏一个就静默失败：键名必须是 repo.packagist（写成 repos.packagist 或 packagist.org 都无效），中间的 composer 是 type 值，不能省略，URL 必须以 https:// 开头且结尾带 /（比如 https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌）。
验证是否写入成功，只看这一条命令输出：composer config -g repo.packagist
输出应为完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}），或新版 Composer 的纯 URL 字符串。空、null、报错、或仍显示 https://packagist.org，说明根本没写进去。
- 全局配置只影响当前用户的
~/.composer/config.json，宝塔、Docker 或 CI 中用www/runner用户执行时，必须用对应用户运行该命令 - 旧版 Composer 1.x 不识别
repo.packagist，得用composer config -g repos.packagist '{"type":"composer","url":"..."}' - 项目根目录下有
composer.json且含repositories字段（哪怕只是"repositories": {}），全局配置就会被覆盖
镜像只加速下载，不加速依赖解析
composer install 卡在 Resolving dependencies 或 Loading composer repositories，和镜像无关——这个阶段根本不发 HTTP 请求，纯本地计算。
典型诱因包括：
- composer.json 里写了过宽的 PHP 版本约束，比如 "php": "^7.4 || ^8.0 || ^8.1 || ^8.2"，让求解器暴力尝试所有组合
- "minimum-stability": "dev" 强制拉取开发分支，候选包数量爆炸
- composer.lock 被删或未提交，install 实际退化为 update
- 项目 repositories 里配置了已下线的私有源，Composer 逐个超时才 fallback
快速排查：
进项目根目录，跑 composer config --list | grep repositories 看实际生效的是哪个源；再执行 composer validate --strict 确认 composer.lock 合法。
必须配合的四个参数才能真正提速
光换镜像只是第一步。生产环境或 CI 构建中，composer install 不加这四个参数，等于主动浪费时间：
-
--no-dev：跳过require-dev（如 phpunit、phpstan），省掉 30–60% 时间 -
--prefer-dist：强制走 ZIP 包；国内镜像几乎不缓存 Git source，没切对镜像时它反而 fallback 到极慢的 clone -
--optimize-autoloader（或-o）：生成静态类映射，PHP 7.4+ 下可进 opcache，autoload 阶段提速明显 -
--classmap-authoritative（或-a）：仅限部署用，告诉自动加载器“没在映射里 = 真没有”，彻底跳过文件扫描
组合示例：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
注意：--prefer-dist 会被项目级 "prefer-source": true 全局覆盖，必须手动删掉；--classmap-authoritative 在开发机误用会导致新增类直接报错。
换源后仍卡在 Downloading？清缓存比重配更重要
镜像配置正确，但 composer clear-cache 没执行，Composer 仍从旧缓存读元数据——它甚至不会尝试新镜像地址，直接卡在 DNS 解析或 TLS 握手阶段。
必须做三件事：
- 运行 composer clear-cache，清掉 ~/.composer/cache/ 下所有内容
- 删除项目里的 vendor/ 和 composer.lock
- 再跑 composer install --no-cache（禁用缓存，强制走新源）
CI/CD 中若用 Docker，每次构建前要确保 ~/.composer/cache 挂载正确；否则每次都是“全新缓存”，镜像优势全无。另外，composer.lock 记录的是旧源哈希，保留它会导致 hash does not match 错误。
真正卡点常藏在缓存、插件和并发设置里——很多人配完镜像就以为万事大吉，结果还是慢。
