多版本控制（MVC）不是主动防护手段，因其仅保存历史版本而不校验内容真实性；Composer 防篡改依赖自身机制：composer install --dry-run --verbose 触发 dist.shasum 比对、security.signature-verification true 验证 GPG 签名、secure-http true 强制 HTTPS，MVC 仅用于事后回滚。
对象存储的多版本控制（MVC）本身不能防止 Composer 镜像被篡改——它只保存历史版本，不校验内容真实性。真正起作用的是 Composer 自身的校验机制，而 MVC 只能在事后提供回滚能力。
为什么多版本控制不是主动防护手段
对象存储（如 OSS、S3）开启多版本后，每次上传同名文件都会保留旧版本，但这个过程完全不校验：
- 上传一个被篡改的
packages.json或恶意dist.zip，MVC 会安静存下它，不报错也不拦截 - Composer 客户端从镜像拉取时，根本不知道该文件有多个版本；它只认当前 latest 版本
- 攻击者若已控制镜像源服务器或上游同步逻辑，可直接覆盖 latest + 删除旧版本（如果权限允许），MVC 形同虚设
真正该用的 Composer 内置防护链
防止镜像被篡改，必须依赖 Composer 运行时校验，而非存储层备份：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer install --dry-run --verbose：强制触发 dist 包哈希比对，失败即停；它读的是composer.lock中的dist.shasum，不是对象存储的版本 ID -
security.signature-verification true：启用 Packagist 元数据 GPG 签名验证，确保packages.json没被中间人替换——这层校验发生在 HTTP 响应解析阶段，早于文件落盘 -
secure-http true：强制所有仓库走 HTTPS，防 DNS 劫持或代理污染；否则即使开了 MVC，请求也可能被导向假镜像 -
preferred-install dist：避免走source（git clone），因为 source 不参与dist.shasum校验，且易被分支污染
多版本控制唯一有价值的使用场景
它只在“确认已被篡改”后的应急响应中有用：
- 发现线上
vendor/autoload.php被注入恶意代码 → 追查对应包的安装时间 → 查对象存储中该dist.zip的历史版本 → 找出未被篡改的 SHA-256 值 - CI 流水线跑
composer verify-checksums --strict失败 → 对比当前composer.lock中的shasum和 MVC 中各版本的哈希值，定位哪次上传出了问题 - 需人工回滚时，用 OSS 控制台或 CLI 快速恢复某个
packages.json的旧版（前提是该文件确实被启用了 MVC 且未被删除）
别把多版本控制当成安全开关——它没有签名、不校验、不阻断。真正的防线在 composer.lock 的非空 shasum、security.signature-verification 的启用状态，以及每次 install 时是否真的执行了哈希比对。MVC 只是最后一张底牌，而且得你提前记得开、记得不删旧版、记得定期审计版本列表。
