composer install仅校验composer.lock中dist.shasum与下载包解压前的SHA-256值是否匹配，不匹配则报错；同时强制HTTPS及TLS证书验证，但不校验作者GPG签名或已安装vendor文件完整性。
composer install 时到底校验了什么
它只比对 composer.lock 中每个包的 dist.shasum 和你本地下载的 ZIP/TAR 包解压前的 SHA-256 值——不匹配就中断安装，报 Signature mismatch 或 package is corrupted。这不是“数字签名验证”，是哈希校验；不走 HTTPS、证书异常或中间人劫持，根本连不到校验环节。
常见错误现象：
- 改了
composer.lock中某包的shasum字段再运行composer install，却没报错 → 很可能用了缓存，或该包是source类型（如 Git 克隆），完全绕过校验 - 国内镜像源替换了原始
dist包但保留了原哈希 → 校验通过，内容却已非作者发布 -
vendor/目录被手动修改后，composer dump-autoload或composer update都不会触发任何文件级完整性检查
为什么 Packagist 元数据 GPG 验证必须手动启用
这是目前唯一真正用到 GPG 的签名验证场景：校验 packages.json 是否由 Packagist 私钥签署，防止攻击者篡改包索引、注入恶意包链接。它不校验包体内容，但能守住“你看到的包列表”这道门。
必须满足以下条件才生效：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer --version≥ 2.2.0（2026 年建议用 2.7.x） - 执行
composer config --global signing-key https://packagist.org/keys.json - 确保
secure-http: true（默认开启），且未设置disable-tls: true - 运行
composer install -v时日志中出现Verifying packages.json signature with key -
repo.packagist.org.allow_ssl_downgrade必须设为false，否则签名验证会被降级跳过
哪些安全机制根本不存在或已被废弃
composer verify-signature 这个命令是虚构的。Composer 官方从未提供该命令，所有声称支持它的教程、插件或脚本都不可信。第三方插件如 composer/composer-signature-checker 已多年未维护，在 PHP 8.1+ 下因调用废弃的 openssl_pkey_get_public 直接崩溃。
容易踩的坑：
- 在
composer.json里写"signature": "xxx"字段 → Composer 完全忽略 - 看到 Packagist 页面显示 “Verified” 就以为本地已验签 → 那只是作者上传时附带签名的记录，不代表你安装时做了验证
- 误以为
composer update --lock会重签名 → 它只更新时间戳，不生成或校验任何密码学签名
怎么确认你的配置真的生效了
仅靠命令执行成功不等于安全机制起作用。必须交叉验证：
- 运行
composer diagnose，输出中必须同时出现secure-http: OK和signature verification: OK—— 少一个都不算安全 - 运行
composer show --security，确认输出含Signature verification: enabled - 执行
composer install -vvv，观察日志是否出现Verifying packages.json signature且无报错 - 若使用镜像，必须禁用默认源：
composer config -g repo.packagist false，再配置元数据镜像而非替换源，否则签名验证直接失效
最常被忽略的是：镜像配置方式错误导致签名锚点丢失，以及私有仓库未额外配置 signing-key。这两处一旦出问题，整套验证链就断在第一环。
