Composer self-update通过内置公钥验证GPG签名并比对SHA-384哈希来确保下载文件完整性，任一环节失败即中止更新；官方安装脚本也强制先校验SHA-384再执行，verify-checksums --strict需配合COMPOSER_EXPERIMENTAL=1启用且严格比对lock中dist.sha256与实际文件。

composer self-update 怎么验证下载文件完整性

它靠内置公钥验 GPG 签名，再比对 SHA-384 哈希，不是只看 HTTPS 或文件大小。只要初始安装可信，后续每次更新都端到端防篡改。

关键点：

• self-update 会从官网拉取新 composer.phar 和配套的 .sig 签名文件
• 内置公钥（硬编码在 PHAR 里）验证签名是否由 Composer 官方私钥生成
• 签名通过后，才用 hash_file('SHA384', 'composer.phar') 计算本地哈希，与官方公布的 SHA-384 值比对
• 任一环节失败（签名无效、哈希不匹配、证书链断裂），更新立即中止并报错，不会静默覆盖

安装脚本（composer-setup.php）怎么验 integrity

不是直接执行，而是先校验哈希再决定是否运行。官方安装流程强制这一步，跳过等于裸奔。

标准做法是：

• 用 wget -q -O - https://composer.github.io/installer.sig 获取当前 installer 的 SHA-384 值，存入变量 HASH
• 执行 php -r "if (hash_file('SHA384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); }"
• 只有输出 Installer verified 才能继续 php composer-setup.php
• 注意：hash_file 必须用 SHA384，换成 SHA256 或漏掉引号都会失效

verify-checksums --strict 为什么必须加 COMPOSER_EXPERIMENTAL=1

因为它是实验性功能，默认禁用。不设这个环境变量，composer verify-checksums --strict 直接报 command not found。

Workflow Decomposer

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

下载

启用后它才真正干活：

• 逐个读取 vendor/ 下每个包的实际文件（跳过 .git、tests/、docs/ 等非发布路径）
• 归并字节流，算出实际 SHA-256，和 composer.lock 里 dist.sha256 字段比对
• 不加 --strict 时，哪怕哈希不匹配也只 warning，返回码仍是 0 —— CI 流水线会误判成功
• type 为 package 或 path 的包会被跳过，且不提示；autoload.php 文件完全不参与校验

中文镜像站的哈希透传缺失风险在哪

不是镜像“慢”，而是它可能把原始 dist 包替换成自己构建的 ZIP，却没同步更新 dist.sha256 字段 —— 结果哈希比对通过，内容却已被动过手脚。

验证是否安全，就看两处是否一致：

• 同一包，在官方源和镜像源的 composer.lock 中，dist.url 和 dist.sha256 是否完全相同
• 手动下载两个源的 dist ZIP，运行 shasum -a 256 *.zip，哈希值是否一致
• 解压后重点比对 src/ 下入口类的函数签名、关键注释块、行数——这些改动很难被忽略
• 如果发现差异，说明该镜像未做哈希透传，不能用于生产环境的完整性校验

最隐蔽的问题是：很多私有包或老旧中文包根本没打 dist ZIP，composer.lock 里 dist.sha256 字段为空，verify-checksums --strict 直接跳过，连 warning 都没有。