有校验，但仅在composer install/update时对dist包解压前做一次性sha-256比对（对比composer.lock中dist.sha256），缓存命中、--prefer-source、镜像未同步哈希或autoload.php被篡改等场景均绕过校验。
composer install 时到底有没有校验包完整性？
没有自动、持续的校验，只有一次性比对，且极易被绕过。它只在 composer install 或 update 用 --prefer-dist 下载 zip/tar 包时，比对 composer.lock 中的 dist.sha256（或 shasum）与压缩包解压前的实际哈希值——仅此一次，之后 vendor 目录就“静默落地”，再无回检。
常见失效场景包括：
- 缓存命中：复用
~/.composer/cache/files/中已存在的 zip，跳过哈希计算 -
--prefer-source或"type": "package"配置：完全不读dist.sha256，也不触发校验 - 国内镜像未同步原始哈希：阿里云、腾讯云等镜像源默认不提供
signature字段，也常缺失或替换dist.sha256 -
vendor/autoload.php被篡改：该文件是 Composer 安装时生成的引导入口，不在任何 dist 哈希覆盖范围内，dump-autoload也不校验它
国内镜像怎么配才不破坏签名验证链？
关键不是“换源”，而是“只代理元数据，不动包文件”。用 composer config -g repos.packagist.type composer 和 composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ 声明镜像为元数据代理源，而非彻底替换官方源。
这样做的效果是：
-
packages.json等元数据走镜像（加速），但包文件（.zip/.tar）仍从 Packagist 官方或其 CDN 下载 -
signature字段能被正确读取并验证，因为镜像只转发 HTTPS 元数据响应，不篡改内容 - 执行
composer diagnose后能看到signature verification: OK，这才是真正生效的标志 - 避免踩坑：
composer config -g repo.packagist composer https://...是危险操作，它会彻底关闭签名校验
如何确认当前环境真在验证 GPG 签名？
签名验证必须显式开启，且只对 dist 包生效，source 方式（git clone）不参与。全局配置项是 security.signature-verification，不是 security.signature-verification（后者无效）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证是否启用：
- 运行
composer config --global security.signature-verification，返回true才算开启 - 临时强制校验安装过程：
composer install --verify-signatures，若失败会报Signature mismatch或Missing signature for - 注意：Packagist 上的 “verified” 标签 ≠ 代码安全，仅代表作者上传时附带了有效 GPG 签名；你仍需检查仓库 owner 是否与
composer.json中的support.source一致
CI 中怎么补上 vendor 文件完整性兜底？
verify-checksums 命令不可直接用，它从 Composer 2.5+ 开始存在但默认隐藏，必须每次加环境变量：COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict。没 --strict 参数时，哪怕哈希不匹配也只警告、返回码仍是 0，CI 无法阻断。
更可靠的做法是快照比对：
- 构建开始时执行：
composer show --installed --format=json > installed.json - 部署前再次导出，用
jq提取各包的distReference和name，排序后diff两份输出 - 对中文私有包（
dist.sha256为空）或type: "package"场景，这是唯一能发现异常的方式 - 生产环境务必设
chmod -R a-w vendor/，防止运行时被注入；CI 中加断言：grep -q "autoload_real\.php" vendor/autoload.php || exit 1
真正危险的不是下载时被劫持，而是 vendor 已落地却无人盯守——哈希校验只发生在那一刻，之后全靠你手动守住目录权限和快照一致性。
