composer self-update校验GPG签名而非SHA-256，仅更新composer.phar自身；它与composer install校验dist.sha256完全隔离，前者保工具安全，后者护依赖包完整。
composer self-update 不校验 SHA-256。
它校验的是 GPG 签名，不是 dist.sha256 或任何文件级哈希。
这个命令只作用于 Composer 自身可执行文件（composer.phar），和你项目里的 vendor/、composer.lock、依赖包完全无关。它不读 composer.lock，不碰 vendor，也不触发任何包级哈希比对。
为什么 self-update 和 dist.sha256 是两套机制
很多人把这两件事混为一谈，但它们在设计上完全隔离：
-
self-update下载并替换composer.phar，用内置 GPG 公钥验证签名，失败则回退到旧版 -
composer install下载 zip/tar 包时，从composer.lock读取dist.sha256，计算下载文件的 SHA-256 并比对 - 前者保护工具自身，后者保护依赖包；前者发生在全局环境，后者发生在每个项目中
self-update 报错时常见原因不是哈希问题
如果你看到 self-update 失败，大概率不是 SHA-256 不匹配，而是：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GPG 签名验证失败（如系统时间错误、CA 证书过期、
secure-http=false导致 HTTPS 被降级） - 镜像源未代理官方更新接口（例如阿里云镜像不提供
https://getcomposer.org/version数据） - PHP 版本不兼容目标版本（比如用 PHP 7.4 尝试升级到 v3）
- 本地
composer.phar权限被锁定或磁盘满
怎么确认 self-update 真正生效了
别只看输出 “Up to date”，要验证实际行为：
- 运行
composer --version，确认版本号变化 - 执行
ls -la $(which composer)，检查修改时间是否更新 - 临时禁用镜像：运行
composer config -g repo.packagist.org.url https://packagist.org，再self-update—— 这能绕过镜像缓存干扰 - 加
-v参数：运行composer self-update -v，观察日志里是否出现Verifying signature...行
真正该关心的 SHA-256 校验在哪儿
你项目里依赖包的完整性，靠的是 composer install 时对 dist.sha256 的校验，而不是 self-update。这点容易被忽略：
- 确保
composer.lock中每个包的dist段含 64 字符的sha256字段（不是空字符串，也不是 40 字符 SHA-1） - 避免使用
--prefer-source或全局配置"preferred-install": {"*": "source"}，否则直接跳过 SHA-256 校验 - CI 构建时强制清缓存：
composer clear-cache && rm -rf vendor/ && composer install --no-cache --prefer-dist
self-update 的安全性依赖 GPG，不是 SHA-256；而你项目的包安全，才真正靠 dist.sha256。两者不能互相替代，也不能互相证明。 
