镜像源配置https仍可能被篡改，因其仅保障传输安全，不保证镜像内容可信；国内镜像不透传signature字段，导致composer跳过gpg验签，且dist.sha256仅校验包体哈希、不绑定发布者身份，无法防元数据劫持或恶意替换。
为什么镜像源配置了 HTTPS 还可能被篡改
因为 HTTPS 只保证传输过程不被窃听或中间人劫持，不保证镜像站返回的内容本身可信。阿里云、腾讯云等公开镜像默认不转发 packages.json 中的 signature 字段，Composer 拿不到签名就静默跳过 GPG 验签——此时你看到的 secure-http: OK 是真，但 signature verification: OK 是假。
常见错误现象：
-
composer diagnose显示secure-http: OK，却没出现signature verification: OK - 某包在镜像站缺失 provider 文件，Composer 自动 fallback 到官方源，但日志里不提示、
composer.lock也不更新dist.url - 手动修改
composer.lock中某个包的dist.sha256后运行composer install无报错 → 实际走的是source安装（如Cloning），完全绕过哈希校验
dist.sha256 不是签名，只是内容指纹
dist.sha256 字段只校验 ZIP/TAR 包解压前的字节一致性，它不绑定发布者身份、不防元数据劫持、不覆盖 vendor/autoload.php 等引导文件。镜像站若替换了原始 dist.url 但保留原始哈希值（比如同步不及时或人工干预），校验照样通过，而实际代码可能已被注入。
关键事实：
-
dist.sha256为空时，verify-checksums --strict直接跳过，不提示也不失败 -
--prefer-source或"preferred-install": {"*": "source"}会彻底绕过整个dist校验链 -
composer show --security若不含Signature verification: enabled，说明签名未生效，此时所有哈希校验都不可信
如何真正启用 Packagist 元数据 GPG 验证
这是目前 Composer 唯一用到 GPG 的签名验证场景：校验 packages.json 是否由 Packagist 私钥签署，防止攻击者篡改包索引、注入恶意包链接。它不校验包体内容，但守住“你看到的包列表”这道门。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
必须同时满足：
-
composer --version≥ 2.2.0（2026 年建议用 2.7.x） - 执行
composer config --global signing-key https://packagist.org/keys.json -
repo.packagist.type必须为composer（不是package或留空） -
repo.packagist.url是 HTTPS 地址且以/结尾（例如https://mirrors.aliyun.com/composer/） -
repo.packagist.org.allow_ssl_downgrade设为false（否则签名验证会被降级跳过）
验证方式：composer install -v 日志中出现 Verifying packages.json signature with key；composer diagnose 同时输出 secure-http: OK 和 signature verification: OK。
verify-checksums --strict 是 vendor 层唯一落地校验手段
verify-checksums 命令本身不联网、不查元数据，只读取本地 vendor/ 并逐包计算 SHA256，再跟 composer.lock 中对应 dist.sha256 比对。但它默认不严格：哈希不匹配只警告，返回码仍是 0，CI 会误判成功。
实操要点：
- 必须加
--strict参数，否则不中断、不报错、不改变退出码 - 它只校验
dist类型包，source类型包（Git 克隆）和path类型包完全不参与 - 它不校验
vendor/autoload.php、composer.lock自身、或任何已安装后被手动修改的文件 - CI 流程中应放在部署前执行，并检查命令退出码是否为 0
真正难的不是知道该用什么命令，而是确认它是否真的在校验——得看 composer.lock 里有没有非空 dist.sha256，得看 -v 日志里是不是 Downloading 而不是 Cloning，还得确认镜像站返回的 JSON 响应里确实带 signature 字段。这些细节漏掉一个，整套校验就形同虚设。
