verify-checksums --strict 是唯一真正校验 vendor 文件内容完整性的命令，成功时静默返回 0，失败仅报 “checksum verification failed” 且不指明具体包或文件，跳过 path 类型包及无 dist.sha256 字段的包，但会因手动修改 vendor/autoload.php 等未记录文件而失败。

Composer 本身不提供通用“数据校验”能力，你看到的所谓“校验结果”，实际只来自三类场景：包哈希完整性验证、依赖约束解析、插件签名检查。没有统一的数据校验报告，必须按具体命令和上下文分别解读。

verify-checksums --strict 的输出怎么看

这是唯一真正校验 vendor 文件内容完整性的命令，但输出极简，容易误读：

• 成功时无输出（静默），返回码为 0
• 失败时只报 checksum verification failed，不指出哪个包、哪几个文件出问题
• 它跳过 type: "path" 包和没有 dist.sha256 字段的包，这类包完全不在校验范围内
• 它会扫描 vendor/autoload.php 等生成文件，但这些文件没记录在 composer.lock 中，一旦被手动修改就会直接失败

composer install/update 的“校验失败”通常不是数据问题

这类错误（如 Signature verification failed）90% 以上源于镜像源元数据失配，而非本地文件损坏：

Workflow Decomposer

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

下载

• 错误常出现在切镜像后首次 install，切回官方源立即消失 → 镜像未同步新 tag 的 dist.sha256
• composer.lock 里存的是旧哈希值，而镜像返回了新包（或缓存旧包但改了哈希）→ 严格比对必失败
• 企业 CDN 或代理层篡改响应体（比如 gzip 压缩后未重算 Content-Length）→ 校验流被破坏
• 仅删 vendor/ 不够，必须连 composer.lock 一起删，否则重装仍用旧哈希比对

依赖冲突提示里的“校验”其实是约束求解过程

运行 composer require xxx --dry-run -v 时看到的 “found x versions, but y are not allowed” 并非数据校验，而是 SAT 求解器在尝试满足所有 require 和 conflict 声明：

• 它不会检查 PHP 版本是否真能跑起来，只看 php: ^8.1 这类声明是否语法上可满足
• 提示 “your requirements could not be resolved” 时，重点看最后一段：哪些包的版本约束互相打架，而不是怀疑数据出错
• composer show --tree 能暴露隐藏依赖，比如 A 依赖 B v1，C 依赖 B v2，B 自身又声明 conflict: "b/*" → 这才是真实冲突点

最易被忽略的一点：verify-checksums 和 install 校验的对象根本不同——前者验磁盘上解压后的文件字节，后者只验下载包压缩包的哈希。两者都通过，不代表 vendor/autoload.php 没被注入，也不代表 config/*.php 没被手动改过。校验永远有盲区，关键文件得靠只读权限+部署断言兜底。