Composer私有代理基于LRU淘汰算法的元数据缓存更新设计-composer-PHP中文网

私有代理元数据缓存实际靠http缓存机制控制，包括cache-control、etag、last-modified协商及代理配置的硬性ttl（如artifactory的remoterepocachettl），而非lru算法。

composer私有代理基于lru淘汰算法的元数据缓存更新设计

Composer 私有代理（如 Satis、Private Packagist、Artifactory 的 Composer 支持）**不实现 LRU 淘汰算法**，也不对元数据做内存级访问排序或自动剔除。所谓“缓存更新”，本质是 HTTP 层的 Cache-Control、ETag 和 Last-Modified 协商，以及代理自身配置的 TTL 策略。如果你在私有代理后台看到“缓存过期”“元数据刷新失败”或“包列表不一致”，问题几乎从不来自 LRU 逻辑缺失——而是 HTTP 缓存头配置、上游源同步延迟或客户端 composer update 行为误判导致。

私有代理元数据缓存实际靠什么控制？

所有主流 Composer 私有代理（Satis、Packagist Private、JFrog Artifactory、Nexus Repository）都依赖标准 HTTP 缓存机制，而非自研 LRU：

Cache-Control: public, max-age=3600 —— 代理会按此秒数缓存 packages.json 等元数据，到期后才向源（如 GitHub 或 GitLab）发起条件请求
ETag 或 Last-Modified 响应头 —— 代理用它发起 IF-NONE-MATCH / IF-MODIFIED-SINCE 请求，避免重复传输
代理自身配置的 remoteRepoCacheTtl（Artifactory）、cache_ttl（Satis）等参数，是硬性过期时间，不是基于访问热度的动态淘汰

为什么你改了 composer.json 却没触发元数据更新？

常见于私有代理未监听到上游变更，或客户端跳过了代理协商流程：

本地执行 composer update --no-cache 或 COMPOSER_NO_CACHE=1 composer update —— 强制绕过所有缓存，包括代理层和本地 ~/.composer/cache/repo/
私有代理未配置 webhook 或定时 sync，上游 Git 仓库推送新 tag 后，代理仍返回旧 packages.json
代理缓存了 /packages.json，但没缓存 /p2/{vendor}/{package}.json —— 导致 composer require 时能拉到包，却无法解析版本约束（报错 Could not find package xxx at any version）
客户端 PHP 进程复用 cURL 句柄，Connection: keep-alive 下某些代理未正确刷新响应头，造成缓存“粘连”

如何验证私有代理是否返回了新鲜元数据？

直接 curl 对应 URL，检查响应头与 body 是否匹配预期：

curl -I https://your-private-repo.example.com/packages.json

重点关注：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

Cache-Control 中的 max-age 值是否合理（如 60–3600 秒）
是否有 ETag 且值随内容变化（两次相同请求应返回相同 ETag；内容变则 ETag 变）
X-Artifactory-Fallback-Cache（Artifactory）或 X-Satis-Generated（Satis）等自定义头，可辅助判断来源

再查一次 body：

curl https://your-private-repo.example.com/packages.json | jq '.packages."myorg/mylib" | keys'

确认最新 tag 是否出现在结果中。

别碰“LRU”这个词，先检查这三件事

当元数据看起来“不更新”，优先排查以下真实瓶颈点：

私有代理是否启用了 上游源健康检查？若上游 Git 服务不可达，代理可能 fallback 到 stale 缓存，且不报错
代理配置中是否设置了 offline_mode=true 或类似开关（如 Artifactory 的 offline mode）？这会导致完全不尝试回源
客户端 composer.json 中是否写了 "repositories": [{"type": "composer", "url": "https://..."}]，但漏掉了 "packagist.org": false？未禁用 packagist.org 时，Composer 会并行请求公有源，干扰私有源响应顺序

LRU 是内存缓存场景下的经典策略，但它在 Composer 私有代理的 HTTP 代理链路里根本不存在。真正决定元数据“新不新鲜”的，是 HTTP 协议语义、代理配置粒度、以及你有没有让上游变更被可观测地传播下来。