verify-checksums --strict 是唯一能验证 vendor 文件真实性的命令，需启用 composer_experimental=1，它逐包比对 vendor 目录实际文件 sha256 与 composer.lock 中 dist.sha256，但跳过无该字段或 type 为 package/path 的包，且不校验 autoload.php；镜像站哈希透传缺失和 autoload.php 篡改是主要风险点。
verify-checksums --strict 是唯一能验 vendor 文件真实性的命令
它不是默认启用的功能，必须加 COMPOSER_EXPERIMENTAL=1 才能调用；不加 --strict 时哪怕哈希不匹配也只警告、返回码仍是 0，CI 会误判成功。这个命令逐包读取 vendor/ 目录下实际文件（排除 .git、tests/ 等非发布路径），归并字节流后算 SHA256，再跟 composer.lock 里对应包的 dist.sha256 字段比对。
常见失效场景包括：
-
type: "package"或type: "path"的包会被跳过，不会报错，但也不校验 - 私有源或老旧中文包没打 dist zip 包，
composer.lock里dist.sha256字段为空，verify-checksums直接忽略 - 镜像站替换了原始 dist 包但没同步哈希值——此时哈希匹配，内容却已非作者发布
中文镜像站常导致哈希“匹配但内容被篡改”
国内主流镜像（如阿里云、腾讯云、华为云）多数未强制同步 Packagist 原始 dist.sha256，而是用自己的构建流程生成 zip 包并计算新哈希。结果就是：哈希比对通过，但代码可能被注入、删减或替换。
验证方法很简单：
- 对比同一包在官方源和镜像源的
composer.lock中dist.url和dist.sha256是否一致 - 手动下载两个源的 dist zip 包，运行
shasum -a 256 *.zip，看是否相同 - 解压后比对关键文件（如
src/下入口类）的行数、函数签名、注释块
若发现差异，说明该镜像未做哈希透传，不能用于生产环境完整性校验。
dist.sha256 字段为空时，不能靠 verify-checksums 补救
很多中文私有包或自建源配置了 "type": "package"，绕过了 Packagist 元数据校验逻辑，导致 composer.lock 里没有 dist.sha256。此时 verify-checksums 会直接跳过，不报错也不提示。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
可行替代方案只有外部快照比对：
- CI 构建开始时运行
composer show --installed --format=json > vendor-snapshot.json - 部署前再次执行同命令，用
diff比对两次输出 - 对差异项人工复核：是否新增/删除了非预期文件？autoload 配置是否被改写？
注意：这个快照不含哈希，只记录包名、版本、安装路径，适合快速发现增删改，但无法证明内容未被篡改。
生产环境必须设 vendor/ 为只读 + 校验 autoload.php
verify-checksums 不校验 vendor/autoload.php，因为它是 Composer 安装时生成的引导文件，不在 dist 包原始结构内。但攻击者常从这里注入恶意代码——比如把 require_once 换成远程加载脚本。
所以必须：
- 部署后立即执行
chmod -R a-w vendor/，防止运行时覆盖 - 在启动检查脚本中加入
grep -q "require_once.*autoload_real\.php" vendor/autoload.php，断言其内容未变 - 避免使用
composer dump-autoload --optimize后再手动改autoload.php，这类操作会绕过所有校验机制
真正难防的不是哈希不匹配，而是哈希匹配但内容被镜像站静默替换，或者 autoload.php 这种“不受锁保护”的关键入口被篡改。
