COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict 是唯一能严格校验 vendor 文件真实哈希的命令，它递归计算 vendor/ 下各包源文件 SHA256 并与 composer.lock 中 dist.sha256 比对，跳过 path 类型包、生成文件及无哈希记录的文件。
verify-checksums --strict 是唯一能校验 vendor 文件真实哈希的命令
清完缓存、重装依赖、甚至 composer install 成功，都不代表 vendor/ 里的文件没被篡改或损坏。composer clear-cache 只删下载缓存，对已解压到磁盘的文件毫无影响。真正验证它们是否和 composer.lock 记录的一致，必须用实验性命令：COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict。
它会递归扫描 vendor/ 下每个包的源文件（跳过 .git、tests/、docs/ 等非发布路径），合并所有字节流后计算 SHA256，并与 composer.lock 中对应包的 dist.sha256 字段比对。
- 不加
--strict：发现不匹配也只警告，返回码仍是 0，CI 流水线会误判为成功 - 不设
COMPOSER_EXPERIMENTAL=1：该命令根本不可见 - 跳过
type: "path"包，或没有dist.sha256字段的包（如老旧私有仓库包） - 不校验
vendor/composer/autoload_*.php这类生成文件
为什么 install 成功后 verify-checksums 却报 mismatch
composer install 只在校验刚下载的 zip/tar 包解压前的哈希；一旦解压完成，就不再回看磁盘上的实际内容。verify-checksums 则是真打开 vendor/ 目录，逐文件读取再算一次 SHA256。两者校验时机和对象完全不同。
- CI 中用了
--prefer-source：走 git clone，无dist.sha256，verify-checksums直接跳过，不报错也不校验 - 本地缓存曾被污染，重装时复用了坏包：
install阶段因缓存命中绕过校验，verify-checksums立刻暴露磁盘上已存在的篡改 - 镜像源替换了 dist 包但未同步原始哈希：
install阶段“匹配”，verify-checksums必然失败
verify-checksums 报错但不指明具体哪个文件出问题
它只告诉你某个包哈希不匹配，不会列出是哪个文件。要定位，得手动操作：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 从
composer.lock中提取该包的dist.sha256值 - 进入
vendor/{vendor}/{package}目录 - Linux/macOS 下运行：
find . -type f ! -name "*.php" -o -name "*.php" | xargs shasum -a 256 | shasum -a 256 - Windows 可用 PowerShell 或 WSL 模拟类似归并逻辑
结果需与 dist.sha256 完全一致才算通过。
最危险的是 autoload.php 这类关键文件完全游离在校验体系外
vendor/autoload.php 被手动修改或注入恶意代码时，verify-checksums 无法感知——它虽会被扫描到，但不在任何哈希记录中；而 autoload_*.php 又被明确排除在校验范围外。
生产部署前务必：
- 将
vendor/设为只读（如chmod -R a-w vendor/） - 单独断言
vendor/autoload.php内容未变（例如用sha256sum vendor/autoload.php固定快照并比对） - 绝不依赖
composer validate或--dry-run，它们不读vendor也不算哈希
