Composer镜像配置生效需同时满足三个硬性条件：键名必须为单数repo.packagist、type值必须显式写composer、URL须为HTTPS且末尾带/；任一缺失即静默回退官方源，验证须执行composer config -g repo.packagist并确认输出为完整JSON对象。
配镜像不是“换地址就完事”，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令只要漏掉一个硬性条件，就会静默回退到 https://packagist.org，你看到命令没报错，不代表它真在用镜像。
为什么 composer config -g repo.packagist 总是看起来生效却没用
常见错误现象：命令执行无报错，composer config -g repo.packagist 输出为空、null 或仍是官方地址，composer install -vvv 日志里仍出现 GET https://packagist.org/。
-
repo.packagist写成repos.packagist（多一个 s）：Composer 2.0+ 直接忽略，不报错也不写入 - 漏掉中间的
composer—— 它是type值，不是可选参数，也不是注释：例如composer config -g repo.packagist https://mirrors.aliyun.com/composer/就失效 - URL 少了末尾
/：比如https://mirrors.aliyun.com/composer，请求会拼成/composerpackages.json，返回 404 后 fallback - 用了 HTTP 协议：Composer 2.9.6+ 默认拒绝非 HTTPS 源，连接直接被拦截
验证是否真写进去了，别只信命令没报错：composer config -g repo.packagist 输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
项目级配置怎么避免覆盖私有源且确保生效
项目根目录下只要 composer.json 里定义了 repositories 字段（哪怕只是 {} 或 []），全局配置就完全不走——不是优先级低，是彻底跳过。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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数组追加新项，key 固定为"packagist" - 如果原
composer.json是"repositories": {}，命令会转为标准数组格式并插入；如果已有私有 VCS 源（如 Git 地址），会追加到数组末尾，不破坏结构 - 但如果
"repositories": []（空数组），该命令会失败，需先手动改为"repositories": {}再重试 - 改完必须删掉
vendor/和composer.lock：因为composer.lock里记录的是旧源下的 dist URL 和 hash，不删它，composer install仍按旧地址下载，根本不会走新镜像 - 删完只跑
composer install（不是update），让 Composer 从头解析依赖、生成适配新镜像的 lock 文件
宝塔、CI、Docker 里镜像为啥不生效
全局配置写在 ~/.composer/config.json，但宝塔后台默认以 www 用户运行，GitHub Actions runner 用的是 runner 用户，Docker 容器里又是独立用户环境——它们根本读不到你本地终端用户的配置。
- 宝塔中需切换用户执行：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Dockerfile 中必须在
RUN阶段显式配置：RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，且不能漏掉末尾/ - 多阶段构建中，每个含
composer的阶段都得单独配一次；--from=builder不继承配置 - Alpine 镜像还要额外装证书：
RUN apk add --no-cache ca-certificates，否则会报SSL certificate problem: unable to get local issuer certificate
换源后依然卡住或报错，该查什么
镜像只影响元数据和 ZIP 包下载路径，不解决依赖解析、PHP 扩展缺失或缓存污染问题。
- 先运行
composer clear-cache：旧缓存里存的是官方源 URL 和 hash，不清掉，composer update仍可能校验失败或 404 - 删掉
vendor/和composer.lock再重装：lock 文件里的 hash 来自旧源，和镜像元数据不匹配会导致安装中断 - 如果卡在
Resolving dependencies，和镜像无关：检查composer.json是否写了太宽泛的 PHP 版本约束（如"php": "^7.4 || ^8.0"）、require-dev是否塞了大量未锁定版本的工具链、是否用了太多dev-main分支依赖 - 验证是否真走镜像：加
-vvv参数运行composer install，观察日志里是否出现mirrors.aliyun.com或对应镜像域名
最容易被忽略的是：改完配置不删 composer.lock 和 vendor，就直接 composer update——这等于拿新镜像去校验旧锁文件，必然失败。镜像生效的前提，是让 Composer 从零开始生成一套匹配它的新依赖图。
