clear-cache不能修复hash verification failed，因其仅清除~/.composer/cache/files/中的zip包和元数据，不更新composer.lock中已失效的dist.sha256哈希值，导致校验时仍用旧哈希比对新包而必然失败。
为什么 clear-cache 不能修复 hash verification failed
composer clear-cache 只删 ~/.composer/cache/files/ 里的 zip 和元数据，但 composer.lock 中记录的 dist.sha256 没变。下次 composer install 仍用旧哈希去比对新下载的包——哪怕你换镜像、重试十次，只要 lock 文件没更新，校验就必然失败。
这不是缓存“脏了”，是信任锚点断了：lock 文件和实际分发内容已脱钩。
- 只清缓存 → 错误照常出现
- 只删
vendor/→composer.lock还在，重装时继续拿错哈希校验 - 加
--no-cache或换镜像源 → 若镜像本身未同步，哈希仍不匹配
真正有效的双清重建流程
必须同时清除“元数据描述”和“安装产物”，让 Composer 从头拉取可信源并生成新锁文件。
- 先备份：
cp composer.lock composer.lock.bak - 彻底清除：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 切回官方源保真：
composer config -g --unset repos.packagist，再确认生效：composer config -g repos.packagist应输出空或默认值 - 重装生成新 lock：
composer install—— 此时会从packagist.org拉最新元数据，写入当前有效哈希
别跳过切源这步。国内镜像若未同步完成，直接指定它只会把错误哈希再次固化进新 lock。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
怎么确认是代理污染而非镜像滞后
代理篡改响应体时，composer install -vvv 日志里会出现异常 URL，比如 http://internal-proxy.example.com/... 或域名明显非镜像源；更关键的是，用 curl -I 对比响应头 Content-Length 和实际下载 zip 大小是否一致——不一致就是被截断或重写了。
- 运行
curl -I https://packagist.org/packages.json，看是否秒回HTTP/2 200 - 检查环境变量：
echo $HTTP_PROXY $HTTPS_PROXY（Linux/macOS）或set HTTP_PROXY（Windows），非空则大概率干扰 - 临时禁用：
export HTTP_PROXY= HTTPS_PROXY=再试composer install
CI/CD 环境下最容易被忽略的坑
很多构建失败不是因为命令写错，而是缓存复用逻辑埋了雷：vendor/ 和 composer.lock 被跨构建保留，而镜像源状态已变，导致新构建加载旧 lock + 新包 → 哈希必然崩。
- CI 脚本开头加：
rm -rf vendor composer.lock，别依赖缓存 - 不要在 CI 中执行
composer config -g修改全局配置——不同 job 间可能冲突 - 若必须用镜像，显式指定可信地址：
composer config -g repo.packagist composer https://repo.huaweicloud.com/repository/php/，而非依赖系统代理
最隐蔽的问题往往不在 Composer 命令本身，而在构建上下文里那个没被清理的 composer.lock，和那个静默劫持请求的代理。
