composer install 不报错但包内容错误是因为默认不校验已安装包完整性；仅首次下载dist包时比对lock中的sha256，缓存、--prefer-source、镜像替换等均跳过校验。

composer install 为什么没报错但包内容错了

因为默认不校验已安装包的文件完整性。Composer 只在首次下载 dist 包（zip/tar）时，比对 composer.lock 中记录的 dist.sha256 和解压后根目录的哈希值；一旦缓存存在、或用了 --prefer-source、或镜像替换了原始 dist 包，这层校验就完全跳过。

常见诱因包括：

• 本地 vendor/ 被手动修改或删了部分文件，composer install 不会察觉
• 国内镜像（如阿里云、腾讯云）未严格同步 Packagist 的 dist 包签名，哈希可能“碰巧匹配”但内容已被替换
• composer.lock 是旧版生成的，而当前运行的是新版 Composer（如 2.5+），但 lock 文件里没写 content-hash 或 dist.sha256 字段
• 项目用了 "type": "package" 或 path 仓库，这类 source 安装方式压根不走哈希校验流程

启用 verify-checksums 实验性校验（推荐部署阶段用）

Composer 2.4+ 提供了 verify-checksums 命令，它是目前最贴近“部署前验包”的官方方案——但它仍是实验性功能，需显式启用环境变量。

实操要点：

• 必须加 COMPOSER_EXPERIMENTAL=1，否则命令不存在
• 务必带 --strict：它让命令在校验失败时返回非零退出码，CI/CD 流程才能真正中断
• 执行前确保 vendor/ 已存在且 composer.lock 是最新（即刚跑完 composer install）
• 不校验 source 类型包，只针对 dist 包生成的 vendor 子目录

示例命令：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict

镜像配置不影响 verify-checksums 的校验逻辑

你用的是 https://mirrors.aliyun.com/composer/ 还是官方源，对 verify-checksums 的行为没影响——它只读 composer.lock 里的 dist.sha256，然后重新计算本地 vendor/{package}/ 目录的哈希值。镜像只决定 install 阶段从哪下 zip，不影响后续校验依据。

但要注意一个陷阱：

• 如果镜像源返回的 dist 包和 Packagist 官方不一致（比如打了补丁但没更新 sha256），那么 verify-checksums 一定会失败
• 这种失败不是 bug，而是安全机制在起作用：它忠实地告诉你，“你装的包，和 lock 文件承诺的不一样”
• 此时该做的不是关掉校验，而是换镜像、切回官方源、或联系镜像维护方确认一致性

真正卡住部署的最小可靠组合

仅靠 composer install 永远无法保证 vendor 完整。生产部署脚本里，必须串联两步：

• 先跑 composer install --no-interaction --no-scripts --no-plugins（避免脚本干扰校验）
• 再跑 COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict

缺一不可。跳过第一步直接校验，会因 vendor 缺失而报错；跳过第二步，等于把校验权交给了镜像和网络——而这两者恰恰是最不可信的环节。