详解Composer镜像源同步过程中的包指纹校验-composer-PHP中文网

composer install时比对的是composer.lock中dist.sha256字段记录的zip包sha-256字节哈希值，下载完成后立即计算本地文件哈希并与之比对，不涉及gpg签名或git hash。

详解composer镜像源同步过程中的包指纹校验

composer install 时到底在比对哪个指纹

Composer 安装包时校验的不是 GPG 签名，也不是 Git commit hash，而是 dist.sha256 字段记录的 ZIP 包字节哈希值。这个值写在 composer.lock 里，下载完成后 Composer 会当场计算本地文件的 SHA-256，并和它比对。

常见错误现象：The checksum verification failed 或 hash verification failed，但 vendor/ 里文件看起来完全正常——这是因为镜像站返回了 ZIP 包，却没同步原始哈希（比如阿里云、腾讯云部分镜像默认不透传 dist.sha256），导致你比的是镜像“自己填的”哈希，而非 Packagist 原始值。

dist.sha256 为空时，verify-checksums 直接跳过该包，不警告也不报错
--prefer-source 或 "preferred-install": {"*": "source"} 会彻底绕过整个 dist 校验链
vendor/autoload.php、vendor/composer/autoload_real.php 等生成文件不在哈希覆盖范围内，改了也不会触发校验失败

为什么镜像源下 verify-checksums 经常“假成功”

verify-checksums --strict 是唯一能落地校验 vendor 是否被篡改的命令，但它有硬性前提：必须启用环境变量 COMPOSER_EXPERIMENTAL=1，否则即使哈希不匹配也只警告、返回码仍是 0。

更关键的是，它只校验 composer.lock 中 dist.sha256 非空的包。而中文镜像环境下大量包缺失该字段，原因包括：

包作者发布时只提供 --prefer-source 路径，未打 dist ZIP 包
自建镜像或旧镜像（如已停用的 phpcomposer.com）仅缓存文件，不校验/不透传原始元数据
composer.json 中显式写了 "type": "package"，绕过 Packagist 元数据校验逻辑

此时你看到 No checksum mismatches found，不代表安全，只是“没东西可校验”。

如何确认当前镜像是否同步了真实哈希值

不能靠 composer config repo.packagist.org.url 输出判断——配置可能还在，但镜像实际没同步哈希。真正有效的验证方式是看 -vvv 日志中下载 URL 对应的元数据是否含原始 dist.sha256。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

手动验证步骤：

找一个项目中实际用到的包，例如 laravel/framework
运行 composer install -vvv 2>&1 | grep "Downloading.*p2/laravel/framework"，拿到镜像站返回的 JSON URL
用 curl -s https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json | jq -r '.packages."laravel/framework"[0].dist.sha256' 提取哈希
对比官方源同路径结果：curl -s https://repo.packagist.org/p2/laravel/framework/10.0.0.json | jq -r '.packages."laravel/framework"[0].dist.sha256'

两者不一致，说明该镜像未同步原始哈希；若镜像返回 null 或空字符串，说明它压根没透传该字段。

签名验证（signature verification）才是真正的信任锚点

dist.sha256 只防内容篡改，不防元数据劫持。Packagist 官方签名才是防中间人攻击的核心机制，它由服务端为每个包版本生成并内嵌在元数据中。

但签名验证极易被配置破坏：

执行 composer config -g repo.packagist false 是必要前置动作，否则旧式源替换会关闭签名验证
镜像 URL 必须带尾斜杠：https://mirrors.aliyun.com/composer/ ❌ 写成 https://mirrors.aliyun.com/composer 会导致 Composer 误判为普通仓库，签名字段直接丢失
必须确保全局配置为 repos.packagist.type composer + security.signature-verification true

运行 composer diagnose，只有同时出现 secure-http: OK 和 signature verification: OK，才代表签名生效。否则所有哈希校验都只是“纸面安全”。