“Signature mismatch”或“package is corrupted”是composer.lock中dist.sha256与下载包实际SHA-256不一致所致，非证书验证失败；诱因包括手动改lock、source类型包跳过校验、缓存复用冲突或镜像返回损坏包；验证需删vendor和lock后重装，仍错则切回官方源或检查PHP证书配置。
Composer install报错“Signature mismatch”或“package is corrupted”
这不是证书验证失败，而是composer.lock里记录的dist.sha256哈希值和实际下载包解压前的 SHA-256 不一致。Composer 在安装时只做这一步校验，不涉及 TLS 证书、GPG 签名或运行时文件完整性。
常见诱因包括：
- 手动修改过
composer.lock中某包的dist.sha256字段 - 该包是
source类型（如通过 Git clone 安装），完全跳过哈希校验 - 使用了缓存——旧缓存包被复用，但 lock 文件已更新，导致哈希对不上
- 镜像源中途返回了损坏或被篡改的 ZIP 包（极少见，但企业代理/防火墙可能重写响应）
验证方式：删掉 vendor 和 composer.lock，重新 composer install；若仍报错，再检查镜像源是否可信或临时切回官方源 https://packagist.org。
PHP 层 SSL 证书路径配置错误（最常见根因）
95% 的 SSL certificate verify failed 错误，本质是 PHP 找不到或读不了 CA 证书文件，不是 Composer 或网络问题。
先确认问题归属：
- 运行
php -r "print_r(openssl_get_cert_locations());"，看default_cert_file和ini_cafile是否指向一个真实存在、可读的 PEM 文件 - 如果路径为空、是符号链接但目标丢失、或权限为 000，就是这里出问题
- 再跑
curl -v https://packagist.org/packages.json，如果也失败，说明是系统级证书问题，不是 Composer 单独能调的
修复步骤：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 下载最新 Mozilla 根证书：cacert.pem
- 保存为绝对路径，例如
/etc/ssl/certs/cacert.pem（Linux）、C:\php\extras\ssl\cacert.pem（Windows） - 编辑 CLI 模式下真正生效的
php.ini（执行php --ini查看 Loaded Configuration File） - 添加两行（必须用绝对路径，不能用
~或相对路径）：openssl.cafile=/etc/ssl/certs/cacert.pemcurl.cainfo=/etc/ssl/certs/cacert.pem - 关闭当前终端，新开一个——CLI 环境不会自动重载 ini，必须重启进程
临时绕过证书校验的三种有效方式（仅限调试）
Composer 本身没有 --no-secure 或 --insecure 参数，那些写法会直接报 Command not defined。真正起作用的只有底层环境变量方式：
-
COMPOSER_CAFILE=/dev/null composer install（Linux/macOS）或set COMPOSER_CAFILE= && composer install（Windows CMD）：强制让 Composer 使用空 CA 文件，跳过证书链校验 -
COMPOSER_DISABLE_TLS=1 composer install：降级为 HTTP 协议（仅对同时提供 HTTP 接口的镜像有效，如旧版阿里云镜像） - 手动改
composer.json里的镜像 URL 为http://mirrors.aliyun.com/composer/，再执行composer update --lock
⚠️ 注意：COMPOSER_CAFILE=/dev/null 是最底层、最可靠的绕过方式，但它只应在你确认镜像可信、且不涉及敏感依赖的本地调试场景中使用；生产环境或 CI 中绝不可用。
为什么 --no-secure-http 有时无效？
composer config -g secure-http false 或 composer install --no-secure-http 控制的是是否允许非 HTTPS 的仓库地址，它不干预 OpenSSL 的证书校验逻辑。真正触发 certificate verify failed 错误的是 PHP 的 stream_context_create() 或 cURL，不是 Composer 的协议开关。
所以当你看到这个错误时，优先排查 PHP 的 openssl.cafile 和 curl.cainfo 配置，而不是折腾 Composer 的 secure-http 设置。
复杂点在于：同一个系统里 CLI 模式和 Web 模式可能加载不同的 php.ini，而 Composer 只走 CLI；容易被忽略的是——改完 php.ini 后没关终端，导致新配置根本没生效。
