哈希校验失败是 composer.lock 中记录的 dist.sha256 与实际包内容不匹配，需同步清理 vendor、composer.lock 和缓存，并切换回官方源后重新 install 生成新锁文件。
哈希校验失败不是缓存脏了，是 composer.lock 里写的值和包对不上
报 hash verification failed 时，别急着 composer clear-cache。这个命令只清 ~/.composer/cache/ 下的 ZIP 和元数据，但 composer.lock 里硬编码的 dist.sha256 完全没动。安装时 Composer 仍拿旧哈希去比新包，差一个字节就直接中断。
- 删
vendor/单独没用：install 会照搬composer.lock里记录的版本和哈希 - 换镜像后不删
composer.lock：它仍指向旧源的哈希，新镜像返回的包内容自然不匹配 - Windows 用户常漏掉
del composer.lock，必须配对执行：rd /s /q vendor & del composer.lock
真正有效的三步清理流程（顺序不能乱）
目标是让 Composer 抛弃所有旧上下文，从同一时刻快照拉取元数据，生成带当前有效哈希的新 composer.lock。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先备份：
cp composer.lock composer.lock.bak - 切回官方源保真（Composer 2.5+）：
composer config -g --unset repos.packagist.org - 清缓存：
composer clear-cache，确认输出含Clearing cache (all) - 删干净：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 重装生成新锁：
composer install——此时会拉取完整packages.json，所有dist.sha256都来自同一时刻快照
verify-checksums --strict 才能暴露真实文件篡改
composer install 只校验下载包解压前的哈希；而 verify-checksums --strict 是打开 vendor/ 目录，递归读所有文件再算一次 SHA256。两者时机与对象完全不同。
- 必须启用实验模式：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict - 不加
--strict仅警告且返回 0，CI 流水线会误判为成功 - 它跳过
type: "path"或无dist.sha256字段的包（如老旧私有包），容易漏检 - 不校验
vendor/composer/autoload_*.php这类生成文件，但会扫描vendor/autoload.php——手动改过它就会失败
CI/CD 中最常被忽略的细节
流水线里报错往往不是本地环境的问题，而是缓存挂载或配置覆盖导致的静默失效。
-
COMPOSER_CACHE_DIR挂在 NFS 或持久卷上时，composer clear-cache可能根本没清到实际路径 - 项目级
composer.json中若存在"repositories"字段（哪怕空数组[]），全局镜像配置会被绕过 - 用了
--prefer-source：走 git clone，完全绕过哈希校验，verify-checksums会跳过该包 -
vendor/autoload.php等关键引导文件游离在校验体系外，被注入恶意代码时 Composer 无法感知
