Composer中文镜像环境下的Composer版本哈希一致性检查-composer-PHP中文网

不能直接用，必须先启用实验模式：composer 2.5+ 才提供 verify-checksums 命令，但默认隐藏，需每次执行时设置 composer_experimental=1 环境变量并配合 --strict 参数，才能严格校验 vendor/ 与 composer.lock 中 dist.sha256 是否一致。

composer中文镜像环境下的composer版本哈希一致性检查

composer verify-checksums --strict 能不能直接用

不能直接用，必须先启用实验模式。Composer 2.5+ 才带 verify-checksums 命令，但它默认隐藏，不设环境变量就根本不会出现在 composer list 里。

执行前要确认：composer --version ≥ 2.5；然后每次调用都得带上 COMPOSER_EXPERIMENTAL=1，比如：COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict。

--strict 是关键开关——没它，哪怕发现哈希不匹配也只警告、返回码仍是 0，CI 流水线会当成成功通过。

中文镜像（如阿里云、腾讯云、华为云）若未同步原始 dist 包的 dist.sha256 字段，verify-checksums 仍会比对，但比的是镜像提供的哈希值，不是 Packagist 原始值
镜像源替换 dist 包但未更新哈希时，校验“通过”但内容已非作者发布——这是镜像一致性风险，不是 Composer 本身缺陷
运行前建议先检查镜像配置：composer config repo.packagist.org.url，确认是否指向可信镜像

为什么中文镜像下 verify-checksums 经常跳过包

很多中文包（尤其是私有源或 "type": "package" 配置）在 composer.lock 里没有 dist.sha256 字段，verify-checksums 会跳过它们，不报错也不校验。

常见原因包括：

包作者发布时只提供了 --prefer-source（git clone）路径，没打 dist zip 包
使用了自建镜像源，但未同步原始哈希值（部分镜像仅缓存文件，不校验元数据）
composer.json 中显式写了 "type": "package"，绕过 Packagist 元数据校验逻辑

此时 verify-checksums 不会报错，但实际漏检——你看到 “No checksum mismatches found” 并不等于所有包都安全。

Discussion Composer

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

下载

如何手动验证单个中文包的哈希是否被镜像污染

当 verify-checksums 报 “Checksum mismatch” 但没指明具体路径时，得手动定位到包级，尤其针对中文生态常用包（如 overtrue/wechat、laravel-china/socialite）：

先用 composer show --locked overtrue/wechat --format=json 提取该包的 dist.sha256 值
进入 vendor/overtrue/wechat 目录
运行：find . -type f ! -name '.git*' ! -path './tests/*' ! -path './vendor/*' -print0 | sort -z | xargs -0 shasum -a 256 | shasum -a 256
对比结果：两次 SHA256 是否一致？不一致就说明该包目录内有文件被改动或增删，或镜像替换了原始 dist 包

注意：别直接 shasum -a 256 . —— 目录不可哈希，必须先归并所有文件字节流再算。

vendor/autoload.php 被改了，verify-checksums 会发现吗

不会。verify-checksums 只校验原始 dist 包解压后的文件，而 vendor/autoload.php 是 Composer 安装时生成的引导文件，不在任何 dist.sha256 覆盖范围内。

它的内容固定为：require_once __DIR__ . '/composer/autoload_real.php';，一旦被注入 eval($_GET['x']) 或替换成恶意代码，所有校验命令都无感。

生产环境唯一可靠防护是设为只读：chmod -R a-w vendor/
CI 中加断言：grep -q "autoload_real\.php" vendor/autoload.php || exit 1
更彻底的做法：固化该文件哈希，在部署脚本中单独校验，比如：[[ $(sha256sum vendor/autoload.php | cut -d' ' -f1) == "b0e4a7c9d8f1e2b3a4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7" ]] || echo "autoload.php tampered!"

镜像环境本身不影响这个风险，但 CI 构建若复用旧 vendor/ 目录，更容易被注入——这点比哈希不一致更隐蔽、更危险。