安全连接需保留官方源+启用签名验证+仅镜像元数据；全量替换repo.packagist会丢弃signature校验，导致无感知供应链投毒。
直接说结论：安全连接 = 保留 packagist.org 官方源 + 强制启用签名验证 + 仅将元数据请求（packages.json）代理到 HTTPS 镜像，不能用 composer config -g repo.packagist composer https://... 这种全量替换方式。
为什么 repo.packagist 全量替换不安全
这种写法会彻底丢弃官方源，导致 Composer 跳过 signature 字段校验。国内镜像（如阿里云）不生成或不透传 signature 元数据，composer install 就会静默降级为无校验模式——你拉下来的 zip 包可能已被篡改，且无法察觉。
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/后，composer diagnose中signature verification会显示disabled - 即使 URL 是 HTTPS，只要没走官方源，
packages.json里的signature字段就为空或缺失 - 旧地址如
https://packagist.phpcomposer.com已停用，且从不支持 signature，强行使用等于主动关掉安全链路
正确配置：用 repos.packagist 代理元数据
Composer 2.2+ 支持在不替换源的前提下，把元数据请求转发给镜像，同时仍从官方或带校验的 CDN 下载包文件（.zip/.tar），并验证 signature。
- 先启用全局签名验证：
composer config -g security.signature true - 再设置可信镜像（仅代理元数据）：
composer config -g repos.packagist.type composer，然后composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 确认 HTTPS 强制开启：
composer config -g secure-http true（默认已开，但建议显式检查） - 验证是否生效：
composer diagnose输出中必须同时出现secure-http: OK和signature verification: OK
Docker 构建时容易踩的坑
在 Dockerfile 里写 RUN composer config -g ... 看似简单，但极易因格式或环境问题失效。
- 键名必须是
repos.packagist（复数），不是repo.packagist或packagist.org；漏掉s就静默失败 - URL 必须以
https://开头，且结尾带/，例如https://mirrors.aliyun.com/composer/；少斜杠会触发 404 后 fallback 回官方源 - Alpine 镜像需提前装
ca-certificates：RUN apk add --no-cache ca-certificates，否则 HTTPS 握手失败，配置看似成功实则不生效 - 多阶段构建中，final 阶段若以
www-data用户运行，composer config -g写入的/root/.composer/config.json对它不可见；应改用RUN su www-data -c "composer config -g ..."
CI/CD 中镜像源常“失效”的真实原因
不是配置没写对，而是缓存和用户上下文让配置根本没被读到。
- CI runner 复用旧缓存，
vendor/和composer.lock没清干净，Composer 仍按 lock 文件里原始地址拉包，完全不查新配置 - 脚本以
root身份运行，但 PHP 进程实际以www-data启动，后者读不到 root 的全局配置 - 推荐做法：在 CI 脚本开头加两行 ——
composer clear-cache和composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/，强制刷新
最易被忽略的一点：安全配置是否生效，不能只看命令有没有报错，必须运行 composer diagnose 并逐项核对输出。很多团队配完就跑 install，结果一直以为“连上了”，其实 signature verification 早就 disabled 了。
