Composer 默认不校验下载包哈希，因仅当 composer.lock 含非空 dist.shasum 时才校验；旧版 Composer、手动修改 lock 文件或镜像源篡改均会导致校验失效，易受中间人攻击。

Composer 默认不校验下载包的内容哈希，遇到网络劫持（比如中间人篡改 dist ZIP、替换 composer.lock 中的 dist.shasum 字段）时，会静默安装被污染的代码——这不是小概率事件，国内某些运营商和企业网络确实存在这类问题。

为什么 composer install 会跳过哈希校验？

Composer 在解析 composer.lock 时，仅当该文件中明确包含 dist.shasum 字段且非空时，才在下载后比对 ZIP 文件的 SHA256 值。但以下情况会导致校验失效：

• 你用的是旧版 Composer（shasum 字段处理宽松，甚至忽略校验失败
• composer.lock 是由未启用校验的机器生成的，其中 dist.shasum 字段为空或缺失
• 执行了 composer update --no-install 后再手动 install，而 lock 文件未更新哈希
• 使用了 COMPOSER_DISABLE_NETWORK=1 或离线模式，跳过远程校验逻辑

强制启用并验证哈希校验的实操步骤

不是加个配置就能生效，必须确保“生成 lock”和“执行 install”两个环节都走严格路径：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 升级到 Composer 2.2+（推荐 2.5+），运行 composer self-update
• 删掉现有 composer.lock，用 composer update --lock 重新生成（注意：不是 --no-install）
• 检查新生成的 lock 文件，确认每个 package 的 dist 下都有非空 shasum 字段，例如：

  "dist": {
    "type": "zip",
    "url": "https://api.github.com/repos/monolog/monolog/zipball/...",
    "reference": "...",
    "shasum": "a1b2c3..."
  }

• 执行 composer install --no-dev（或带 --dry-run 先试跑），观察输出是否含 Verifying archive integrity... OK 类提示；若报 sha256 hash mismatch，说明校验已触发且拦截了异常包

网络劫持下仍可能绕过校验的隐蔽路径

即使启用了哈希，以下行为会让校验形同虚设：

• 使用 composer config --global secure-http false → 导致 Composer 通过 HTTP 下载 packagist.org 元数据，中间人可篡改 JSON 响应中的 dist.urls 和 shasum
• 镜像源未同步 shasum 字段（如某些老旧私有镜像或国内镜像未完整透传 Packagist 的 dist 数据）
• 手动修改 composer.lock 中的 shasum 值去“匹配”被劫持的 ZIP，Composer 不校验该字段来源合法性
• 启用 composer config --global store-auths false 并配合代理，某些代理会缓存并返回篡改后的 ZIP 而不触发重下载

真正起作用的不是“开启校验”这个动作，而是整条链路——从元数据 HTTPS 获取、到 lock 文件生成时的哈希写入、再到 install 时的本地 ZIP 校验——任一环降级为 HTTP 或绕过签名，哈希就只是摆设。最易被忽略的是镜像源本身是否可信，以及 secure-http 是否全局开启。