缓存失效时不能只运行 composer clear-cache，因为它仅删除 ~/.composer/cache/ 下的 files/、repo/ 和 http/ 目录，不修复镜像配置、属主错位、dns 缓存或项目级 repositories 覆盖；常见表现是仍卡在 packagist.org 或报 zlib_decode() 错误。
缓存失效时为什么不能只跑 composer clear-cache
因为 composer clear-cache 只删 ~/.composer/cache/ 下的 files/、repo/ 和 http/，但不会重载镜像配置、修复属主错位、跳过 DNS 缓存或绕过项目级 repositories 覆盖。常见现象是清完缓存后仍卡在 https://packagist.org/packages.json 或报 zlib_decode(): data error——说明问题不在缓存本身。
自动修复脚本必须包含的三个动作
真正有效的修复不是“一键清理”，而是原子化组合操作：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先验证当前镜像是否可达：
curl -I https://mirrors.aliyun.com/composer/packages.json | head -1，非HTTP/2 200则跳过后续 - 强制切换并写入全局镜像：
composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}'（注意键名是repositories.packagist.org，不是repo.packagist） - 清缓存 + 强制跳过本地包复用：
composer clear-cache && composer install --no-cache --prefer-dist
脚本里最容易被忽略的权限和路径陷阱
运维脚本常在 CI 或 sudo 环境下运行，导致缓存目录属主错乱：
-
ls -ld $(composer config --global cache-dir)必须显示当前用户为 owner，否则composer clear-cache会静默失败 - Windows Git Bash 用户需确认
COMPOSER_HOME已设，否则实际读取的是%APPDATA%\Composer\config.json，全局配置写入无效 -
vendor/目录若存在且含损坏包，--no-cache不会自动清理它；脚本应加rm -rf vendor/前置判断（仅当composer.lock存在才执行）
生产环境慎用 --no-cache 的真实代价
它让每次 composer install 都重拉 ZIP 包，对带宽和上游镜像压力大，CI 场景可接受，但线上发布脚本应加条件判断：
- 仅当
composer config repo.packagist输出为空或含已下线域名（如phpcomposer.com）时才启用--no-cache - 避免在 Docker 构建中无条件使用——应改用多阶段构建，把
composer install --no-cache放在 build 阶段，而非 runtime 阶段 - 所有自愈操作日志必须带
HEAL:前缀，方便后续用 Filebeat 过滤，比如：echo "HEAL: cleared cache and forced reinstall" >> /var/log/mirror-heal.log
