Composer中文镜像站中的全量包哈希值（Hash）校验与防篡改策略-composer-PHP中文网

verify-checksums --strict 是唯一能验证 vendor 是否被篡改的命令，需启用 composer_experimental=1，仅校验 dist.sha256 非空的包，不覆盖 autoload.php 等关键文件，防篡改须结合权限控制与构建快照比对。

composer中文镜像站中的全量包哈希值（hash）校验与防篡改策略

verify-checksums --strict 是唯一能验证 vendor 是否被篡改的命令

它不是默认启用的功能，必须加环境变量 COMPOSER_EXPERIMENTAL=1 才能运行；不加 --strict 时即使哈希不匹配也只警告、返回码仍是 0，CI 流水线会误判成功。

这个命令只校验 dist.sha256 字段非空的包——比如私有源里用 "type": "package" 配置的中文包，若没打 zip 包、没填哈希值，就会被跳过，不报错也不校验。

vendor/autoload.php 不在任何 dist.sha256 覆盖范围内，手动改它不会触发 verify-checksums 报错
生成文件如 vendor/composer/autoload_real.php 同样不参与校验，但它们是执行入口，被篡改后果严重
真正防篡改得靠权限控制：chmod -R a-w vendor/ + CI 中断言 grep -q "autoload_real\.php" vendor/autoload.php

镜像站哈希不一致时，`hash mismatch in provider file` 怎么定位

Composer 2.5+ 强制校验 packages.json 里 provider-includes 字段声明的每个 provider-*.json 文件的 SHA-256 值。阿里云镜像默认透传上游哈希，腾讯云需手动开启 verify-signature，旧镜像（如 phpcomposer.com）直接替换 URL 却不重签，必报错。

别只看 composer install 能不能跑通——很多镜像能返回 packages.json，但某个 provider-laravel~10.0.json 的哈希已失效，错误要等到装对应包时才暴露。

Discussion Composer

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

下载

查当前镜像地址：composer config -g repos.packagist，确认输出是 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}
找一个项目中用到的包，提取它的 provider 文件名：curl -s https://mirrors.aliyun.com/composer/packages.json | jq -r '.provider-includes | keys[] | select(contains("laravel"))'
比对镜像与官方源该文件哈希：curl -s https://mirrors.aliyun.com/composer/p/provider-laravel~10.0.json | sha256sum 和 curl -s https://repo.packagist.org/p/provider-laravel~10.0.json | sha256sum

中文包 `dist.sha256` 字段为空，怎么补救

常见原因：包作者只提供 --prefer-source 路径、自建镜像未同步原始哈希、或 composer.json 显式写了 "type": "package" 绕过 Packagist 元数据校验。此时无法依赖 Composer 内置机制，得靠外部快照比对。

在 CI 构建开始时用 composer show --installed --format=json 记录当前 vendor 状态，部署前再比一次，diff 出差异项人工复核。这不是理想方案，但对缺失哈希的中文包是唯一可行路径。

手动比对单个包哈希：先用 composer show --locked vendor/chinese-package --format=json 提取 dist.sha256 值
进入 vendor/vendor/chinese-package 目录，运行：find . -type f ! -name '.git*' ! -path './tests/*' ! -path './vendor/*' -print0 | sort -z | xargs -0 shasum -a 256 | shasum -a 256
注意排除路径必须写全，漏掉 ./vendor/* 可能把嵌套依赖也计入，导致哈希不一致

`composer install` 成功 ≠ 包没被篡改

它只在校验刚下载的 zip/tar 包（解压前）是否匹配 composer.lock 中记录的 dist.sha256；一旦解压落地，就不再回头检查。而 verify-checksums 是真打开 vendor/ 目录递归读所有文件（排除 .git、tests/ 等），归并字节流再算一次 SHA-256。

常见触发失败场景包括：手动改过 vendor/autoload.php、CI 构建用了 --prefer-source、本地缓存被污染后重装却复用了坏包。

--prefer-source 安装的包完全不走哈希校验，因为 git clone 后内容可能被本地修改
composer install --dry-run --verbose 可模拟安装流程并强制校验所有包哈希，适合 CI 中使用
删 vendor/ 后重装仍报错？因为 composer.lock 里存的哈希值已和当前镜像返回的包不一致，必须同步清除 vendor/ 和 composer.lock

真正难防的是那些不进 dist 流程、没哈希字段、又混在 vendor 里的中文包——它们靠自动校验机制根本扫不到，只能靠构建快照 + 权限锁死 + 人工复核三者叠加。