多版本控制（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 运行时校验，而非存储层备份：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
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 只是最后一张底牌，而且得你提前记得开、记得不删旧版、记得定期审计版本列表。
