该错误由依赖约束冲突导致，非网络或权限问题；应优先运行composer why-not或composer update --dry-run -v定位冲突源头，再针对性调整版本约束或PHP配置。
Composer 报 Your requirements could not be resolved 或 Signature verification failed 时，如果 composer show --security 显示 Signature verification: disabled，说明签名验证根本没启用——不是“包没签名”，而是你连校验开关都没打开。
为什么 composer show --security 显示 disabled
Composer 2.5+ 默认仍不强制开启签名验证，必须显式配置。低于 2.5 的版本压根不支持 security.signature-verification，运行 composer config -g security.signature-verification true 会报错 Unknown configuration setting "security.signature-verification"。
- 先确认版本：
composer --version，若低于 2.5，升级是唯一解法 - 全局配置写错键名很常见：用
repos.packagist（少一个s）代替repos.packagist.org，会导致配置静默失效 - 项目级
composer.json中存在"repositories"字段（哪怕为空数组），会完全屏蔽全局签名设置 - 镜像 URL 末尾漏掉
/，如https://mirrors.aliyun.com/composer，拼接packages.json时返回 404，签名元数据根本拉不到
如何确认签名验证真正生效
仅运行 composer config -g security.signature-verification true 不够，必须验证链路完整：
- 执行
composer diagnose，输出中必须同时出现secure-http: OK和signature verification: OK - 运行
composer show --security，看到Signature verification: enabled才算到位 - 检查
composer.lock文件顶部是否有"signatures": { ... }字段——这是签名元数据落地的证据 - 临时删掉
vendor/并运行composer install --dry-run，观察是否报Signature verification failed for package xxx（有则说明机制已触发）
私有仓库怎么配签名才不裸奔
Packagist.org 的签名机制对私有仓库无效，直接照搬 security.signature-verification true 没用。必须额外补足信任链：
- 私有仓库（如 Satis、Private Packagist）必须启用服务端签名，并提供公钥；客户端需用
composer config -g repos.my-private-repo.signing-key /path/to/pubkey.asc - 若用自建 Composer 镜像站，不能只代理
packages.json，还必须确保 dist 包下载路径指向带signature字段的官方 CDN 或经签名的内部存储 - HTTPS 是底线：所有私有源 URL 必须以
https://开头，且证书有效；config secure-http true必须启用，否则签名字段会被跳过 - 避免混用：不要在同一个项目里既配 Packagist 官方源又配未签名的私有源——Composer 会降级为全链路不校验
签名不是开了就万事大吉。Packagist 上只有作者主动启用「signed packages」的包才带签名，而绝大多数历史包、dev 分支、fork 仓库都不在此列。真正关键的是：别让 composer update 在没有人工 review 的情况下跑进生产环境，否则签名再严也拦不住你亲手装上带漏洞的新版 guzzlehttp/guzzle。
