COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict 是唯一能严格校验 vendor 文件真实哈希的命令，它递归计算 vendor/ 下各包源文件 SHA256 并与 composer.lock 中 dist.sha256 比对，但跳过 path 类型包、生成文件及无哈希记录的文件。
verify-checksums --strict 是唯一能校验 vendor 文件真实哈希的命令
清完缓存不等于依赖文件没被篡改或损坏。composer clear-cache只删下载缓存，对已解压到vendor/里的文件毫无影响。真正验证它们是否和composer.lock里记录的一致，必须用实验性命令：COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict。
不加--strict时，哪怕发现哈希不匹配也只警告并返回 0；不设COMPOSER_EXPERIMENTAL=1则该命令根本不可见。它会递归扫描vendor/下每个包的源文件（跳过.git、tests/等），合并字节流计算 SHA256，并与composer.lock中对应包的dist.sha256字段比对。
- 跳过
type: "path"包或没有dist.sha256字段的包（如私有仓库旧包） - 不校验
vendor/composer/autoload_*.php这类生成文件 - 但会扫描并失败于手动改过的
vendor/autoload.php——它虽关键，却无哈希记录
为什么 composer install 成功后 verify-checksums 却报 mismatch
composer install只在校验刚下载的 zip/tar 包解压前的哈希，一旦解压完成，就不再回看。而verify-checksums是真打开磁盘上的vendor/目录，逐文件读取再算一次 SHA256。两者校验时机和对象完全不同。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 中用了
--prefer-source：走 git clone，无dist.sha256，verify-checksums直接跳过，不报错也不校验 - 本地缓存曾被污染，重装时复用了坏包：
install阶段因缓存命中绕过校验，verify-checksums立刻暴露磁盘上已存在的篡改 - 镜像源替换了 dist 包但未同步原始哈希：
install阶段“匹配”，verify-checksums必然失败
verify-checksums 报错但不指明具体哪个文件出问题
它只告诉你某个包哈希不匹配，不会列出是哪个文件。要定位，得手动提取该包在composer.lock中的dist.sha256，再进vendor/{vendor}/{package}目录，用find . -type f ! -name "*.php" -o -name "*.php" | xargs shasum -a 256 | shasum -a 256（Linux/macOS）或类似方式归并计算，比对结果。
最危险的是autoload.php这类引导文件：完全游离在校验体系外，被注入恶意代码时 Composer 无法感知。生产部署前务必设vendor/为只读，并单独断言vendor/autoload.php内容未变。
