Composer默认启用secure-http是防篡改第一道硬门槛，因其强制所有包源走HTTPS并校验SHA1，缺一不可；FileDownloader在写入前必校验checksum，镜像源同步元数据则校验仍可靠。
Composer 本身不实现零信任架构，但它的下载机制天然契合零信任“永不信任、始终验证”的核心逻辑——所有远程包在写入本地前，必须通过 HTTPS 传输 + SHA1 校验和比对，缺一不可。
为什么默认启用 secure-http 是防篡改的第一道硬门槛
Composer 默认强制所有包源走 HTTPS（secure-http 配置项为 true），这不是可选项，而是安全基线。一旦某镜像或私有源返回 HTTP URL，Composer 直接报错：The "http://..." URL is not allowed to be used with secure-http。
这个限制堵死了中间人劫持、DNS 污染等常见篡改路径。即使你手动配置了 HTTP 源，只要 secure-http 开启，Composer 就拒绝请求。
- 检查当前配置：运行
composer config --global secure-http，输出应为true - 禁用它等于主动放弃传输层保护，不建议在任何生产或协作环境中关闭
- 私有仓库若未启用 HTTPS，应优先修复证书问题，而非降级协议
FileDownloader 如何在写入前完成完整性校验
关键逻辑在 FileDownloader::download() 中：下载完成后，立即调用 hash_file('sha1', $fileName) 与元数据中声明的 $checksum 比对。不一致则删除文件并抛出异常：Invalid checksum for ...。
这个校验不是“可选插件行为”，而是 Composer 下载流程的必经环节，且发生在缓存写入之前。也就是说，哪怕缓存目录被恶意污染，下一次下载仍会重新校验。
- 校验值来自
composer.lock或仓库 metadata 中的dist.sha1sum字段 - 若包无校验和（极罕见），Composer 会跳过校验，但现代 Packagist 所有包均强制提供
- 不要手动修改
vendor/下文件——一旦composer install重装，校验失败将直接中断流程
镜像源切换时，校验和是否依然可靠
可靠。镜像源只是代理分发，不参与包内容生成。阿里云、腾讯云等主流镜像均同步 Packagist 的完整元数据，包括 sha1sum 值。Composer 下载时仍以原始包定义为准，校验逻辑不变。
但要注意：自建镜像若未严格同步校验和字段，或允许上传未经签名的包，则破坏信任链。此时风险不在 Composer，而在镜像运维本身。
- 验证镜像可靠性：对比同一包在官方源与镜像源的
composer show -s vendor/package输出，确认sha1sum一致 - 避免混用多个镜像源——不同源可能缓存不同版本的 metadata，导致校验冲突
- 私有源务必启用
ssl.verify_peer，防止伪造证书绕过 HTTPS
真正容易被忽略的是：校验和只保证“下载下来的文件没被改”，不保证“包作者最初上传的内容就是安全的”。所以 require 第三方包前，仍需人工审查其代码、维护活跃度与历史漏洞记录——Composer 提供的是传输与落地环节的防篡改，不是源头可信担保。
