composer config -g repo.packagist 不是安全配置，因其将官方源替换为镜像源，导致 composer 无法获取 packages.json 中的 signature 字段，从而静默跳过 gpg 签名验证；主流公开镜像（如阿里云、腾讯云）均不转发该字段，即使启用 security.signature true 和正确 signing-key，验签仍失效。
为什么composer config -g repo.packagist不是安全配置
这条命令看似启用镜像，实则直接替换官方源语义，导致 Composer 完全跳过 packages.json 的 GPG 签名验证。阿里云、腾讯云等公开镜像不转发 Packagist 原始响应中的 signature 字段，而 Composer 在元数据里找不到该字段时，会静默降级为无校验模式——composer install照常成功，但你已失去对仓库投毒的第一道防线。
真正有效的镜像配置必须保留官方源地址语义，只代理元数据请求（如 packages.json），包文件下载仍走带校验的路径。否则，哪怕开了 security.signature，也形同虚设。
repos.packagist 配置必须满足的三个硬性条件
要让签名验证真正跑起来，repos.packagist 必须同时满足：
-
type设为composer（不是package或其他） -
url指向 HTTPS 地址（如https://mirrors.aliyun.com/composer/），且该地址返回的packages.json必须含signature字段（目前主流国内镜像均不满足，需自行部署或选用支持签名转发的私有镜像服务） - 全局启用签名开关：
composer config -g security.signature true（注意：不是security.signature-verification，后者是无效配置项）
运行 composer diagnose 后，必须同时看到 secure-http: OK 和 signature verification: OK 才算生效。缺一不可。
如何确认镜像真的在验签？看日志，别信配置项
配置写进去了不代表验证在跑。唯一可靠方式是加 -v 参数观察实际日志：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer install -v，搜索输出中是否出现Verifying packages.json signature with key - 若只有
Loading packages.json from https://...但无验签行，说明镜像未提供 signature 字段，或 Composer 因网络/证书问题根本没拿到公钥 - 公钥必须通过
composer config --global signing-key https://packagist.org/keys.json设置；本地路径、错拼 URL、HTTP 协议、内网无法访问该地址，都会导致验签失败且不报错
PHP 的 openssl.cafile 若指向错误证书 bundle，也会让 keys.json 加载失败——这比配置写错更隐蔽，查日志才能暴露。
生产环境别依赖镜像站的“签名支持”承诺
截至 2026 年 6 月，所有公开 Composer 镜像站（包括阿里云、腾讯云、华为云）均未承诺转发 signature 字段，也不提供元数据快照与离线审计能力。所谓“支持签名”，只是指它们能代理 HTTPS 请求，而非保障签名链完整。
真要落地签名验证，必须：
- 自建
packagist-mirror或使用private-packagist，定期抓取并固化含signature的packages.json - 用 Nginx/Envoy 拦截
/dists/*请求，校验每个 ZIP 文件的 SHA256 是否与元数据中dist.shasum一致 - 项目级锁定源：
composer.json中显式声明repositories和config，不依赖全局配置
镜像配置最容易被忽略的点，从来不是“怎么写”，而是“谁在读、谁在验、谁在改”。~/.composer/config.json 权限不对、CI 构建用 root 跑 install、Docker 容器里 vendor 属主混乱——这些都会让签名验证在启动前就失效。
