镜像源返回304但Composer不更新元数据，根本原因是镜像服务缺失Last-Modified或ETag响应头，导致缓存协商失败；应运行curl -I -H "Accept: application/json"检查响应头，确认缺失后使用composer update --refresh（≥2.5）或手动删除repo缓存目录（≤2.4）强制刷新。
为什么镜像源返回 304 但 Composer 不更新元数据？
镜像站（如阿里云、腾讯云）在同步 packages.json 时，若未正确设置 Last-Modified 或 ETag 响应头，会导致 Composer 误判“资源未变更”，即使服务端已更新元数据，客户端仍复用本地缓存。现象是：镜像站网页能查到新包，curl -I https://mirrors.aliyun.com/composer/packages.json 返回 HTTP/2 200，但 composer update 仍不识别新版本——本质是缓存协商失败。
如何验证镜像源是否缺失关键 Header？
别信浏览器或 curl -I 的状态码，重点看响应头是否含缓存标识：
- 运行
curl -I -H "Accept: application/json" https://mirrors.aliyun.com/composer/packages.json - 检查输出中是否存在
Last-Modified:或ETag:字段；若只有Date:和Content-Type:，说明镜像服务未透传或生成这些头 - 对比官方源：
curl -I https://packagist.org/packages.json，官方源必有ETag和Last-Modified
临时绕过 Header 缺失导致的缓存卡死
当确认镜像源无有效缓存头，又不能等它修复时，必须强制跳过协商逻辑：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Composer ≥ 2.5：直接用
composer update --refresh，它会忽略所有本地缓存的packages.json，不走 304 判定，硬拉新内容 - Composer ≤ 2.4：删对应 repo 缓存目录，路径由
composer config --global cache-dir+/repo/https---mirrors-aliyun-com-composer拼接，删完再跑composer update - 绝对不要依赖
composer clear-cache，它不清元数据缓存策略，只清 ZIP 包和部分 JSON 文件
项目级配置如何规避镜像 Header 问题？
某些镜像（如部分企业内网源）长期不修 Header，这时靠客户端策略更可靠：
- 在项目
composer.json中显式关闭元数据缓存："config": {"cache-files-ttl": 0}，让每次请求都重拉 - 或改用
preferred-install策略避开元数据依赖：composer config --global preferred-install source，直接 clone 源码而非查 dist 包 - 注意：若项目含
"repositories"字段，全局config设置可能被覆盖，需写进项目级composer.json的config下
Header 缺失是服务端问题，但客户端无法等待修复；最稳的解法永远是绕过协商逻辑本身——--refresh 或删 repo 子目录，而不是反复 clear-cache 或改镜像 URL。
