composer镜像配置必须同时满足键名repo.packagist（单数）、type值为composer、url为https且末尾带/三要素，缺一即静默回退官方源；验证需执行composer config -g repo.packagist并输出完整json对象。
配错一个字符，镜像就等于没配——Composer 镜像不是“开了就行”，而是“配对、配全、配准”三件事必须同时成立，否则静默 fallback 到 packagist.org，你还在等 Downloading，其实根本没走镜像。
composer config -g repo.packagist 为什么总不生效
这条命令失败，90% 不是网络问题，而是三个硬性条件漏掉任一：键名拼错、type 值缺失、URL 格式不对。它不报错，但完全不写入配置。
-
repo.packagist必须是单数、全小写；写成repos.packagist或repositories.packagist，命令执行成功但无效 - 第二个参数必须是
composer—— 这是仓库类型声明，漏掉就 fallback 回官方源 - URL 必须以
https://开头，且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json导致 404） - 验证是否成功：运行
composer config -g repo.packagist，输出必须是完整 JSON 对象，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或只返回字符串，都说明没写进去
项目级配置怎么安全追加而不覆盖私有源
全局配置在 CI、宝塔、Docker 中容易因用户权限失效；项目级更可控，但直接编辑 composer.json 容易误删已有源。正确做法是让 Composer 自动合并。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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） - 如果原
composer.json是"repositories": {}，命令会转为标准对象并插入packagist条目 - 如果已有 Git 私有源（如
"my-vcs": {"type": "vcs", "url": "..."}），命令会向对象中追加，不破坏原有结构 - 但若原
repositories是数组格式（[]），该命令会报错；需先手动改为{}再执行 - 改完必须删掉
vendor/和composer.lock，再跑composer install—— 否则composer.lock里还是旧 dist URL，根本不会走新镜像
宝塔 / CI / Docker 里镜像为啥不起作用
全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」默认用 www 用户，CI 流水线通常用非登录用户，根本读不到你的配置。
- 查实际执行用户：在宝塔终端运行
sudo -u www composer config -g repo.packagist，如果输出为空，说明该用户没配 - 给对应用户重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本或 systemd 服务中，别依赖全局配置，改用临时参数更可靠：
composer install --repository-url=https://mirrors.aliyun.com/composer/ - Docker 构建时，建议在
Dockerfile里显式配置：RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并确保该 RUN 指令在COPY composer.*之后、composer install之前
换镜像后依然卡在 Resolving dependencies 怎么办
镜像只加速下载（Downloading 阶段），不解决依赖解析（Resolving dependencies）慢的问题。卡在这里，和镜像无关，是本地 CPU 在暴力穷举版本组合。
- 删掉
"minimum-stability": "dev"—— 稳定版能砍掉 80% 的求解时间 - 收紧 PHP 版本约束：
"php": "^8.1"比"php": ">=7.4"少查几百个包的兼容性元数据 - 确保
composer.lock已提交进 Git，并在 CI/部署中始终用composer install（不是update） - 临时禁用 xdebug：
php -d xdebug.mode=off $(which composer) install，它会让解析慢 5–10 倍 - 如果项目已有
repositories字段，别手动编辑composer.json，用composer config repo.packagist ...让 Composer 自动合并
最常被忽略的点：镜像配置成功 ≠ 依赖安装变快。Resolving 和 Downloading 是两个阶段，优化手段完全不同；而 composer.lock 是否删除、是否用对用户、URL 末尾有没有 /，这三处任一出错，镜像就形同虚设。
