开发机与 CI 如何共享依赖缓存

如果同一份依赖经常被不同开发机、临时 CI Runner 或新建服务器重新下载，共享依赖缓存值得试用。Depsilo 把这些客户端的依赖请求集中到一个自托管实例，让后续请求有机会复用已下载的内容。

是否有收益，取决于还有多少下载未被现有缓存满足，以及客户端到实例的网络路径。本页以稳定版 v0.11.0 为范围，帮助你判断是否需要它，再用一个项目验证。

三种缓存分别解决什么问题

方式	保存什么	复用范围	生效前提
包管理器本地缓存	包管理器保存的元数据、下载文件或内容存储，具体取决于客户端	能访问同一缓存目录的安装任务	缓存目录保留，客户端能按自己的规则复用内容
CI 缓存	工作流指定路径的文件，可能包含包缓存或构建输出	工作流允许恢复相应缓存的任务	路径、缓存键和恢复条件正确，任务确实恢复了可用内容
Depsilo 共享依赖缓存	经实例请求并缓存的依赖元数据与制品	配置为使用同一实例的开发机、服务器和 CI	客户端能访问实例，请求实际到达实例，内容可缓存且仍满足交付条件

三者可以同时使用。例如，CI 先恢复包管理器的本地缓存，包管理器再把仍需访问仓库的请求发给 Depsilo。无需为了共享缓存而关闭原有缓存。

完全由本地缓存满足的一次读取不会到达 Depsilo。 同一次安装仍可能另外请求元数据或其他制品，因此不能把“安装成功”或“第二次安装更快”直接当作服务端命中的证据。

哪些场景值得试用

• 临时运行环境反复下载相同依赖。 Runner 或虚拟机经常重建，现有 CI 缓存又未能充分复用下载内容。
• 多台机器使用有重叠的依赖集合。 每台机器有自己的本地缓存，但首次安装仍各自从上游下载。
• 需要观察实际经过服务的请求。 在同一实例查看访问记录，或统一执行已启用的包策略，也是引入代理的理由；这些能力只覆盖经过实例的请求。

如果本地或 CI 缓存已经消除了大部分下载，新增服务可能带来的下载收益就很小。如果实例离客户端更远、存储较慢或带宽不足，也可能增加等待。先确认重复下载发生在哪里，再决定是否长期运行。

区分下载缓存与构建提速

依赖元数据帮助客户端选择版本和查找下载地址；制品是实际下载的包文件。两者的缓存有效期和请求行为不同，元数据命中不代表制品也命中。已缓存内容仍需满足适用的策略与校验条件。

依赖下载之外，安装还可能包含解压、安装脚本和原生扩展编译，后续构建也可能花时间编译源码或运行测试。优化下载交付，不等于整个构建按相同比例提速。记录请求耗时与完整任务耗时，并分别解释。

编译结果复用属于另一层缓存。Depsilo 的 ccache / sccache 编译缓存需要单独配置，不会由包管理器接入自动开启，也不会替你执行编译任务。

用一个项目验证，再扩大范围

1. 准备可回退的试用。 按快速开始启动实例；其他设备接入时，配置客户端可达的地址和 HTTPS。远程客户端的 localhost 指向它自己。
2. 只连接一个代表性项目。 保存原有 registry、index 或源配置，按包管理器指南优先使用项目级配置，保留原有 lockfile 与完整性校验。
3. 确认真实请求。 按缓存验证指南发送不依赖包管理器本地缓存的制品请求，在 Admin → Access logs 中对应到具体记录，再核对重复请求是否命中。第一次也可能命中现有缓存。
4. 测量实际工作负载。 使用代表性依赖集合，固定项目版本、lockfile 和客户端缓存状态，对比直连与经过实例的下载耗时、上游流量及完整任务耗时。多测几轮，并记录网络与存储条件。
5. 试一次回退。 恢复保存的源配置，执行正常安装并确认项目可用，再决定是否接入更多机器。无需通过删除 lockfile 或增加并行公共源来回退。

长期运行需要承担什么

共享缓存是需要维护的服务。你需要安排持久化、容量管理、备份与恢复、升级，以及供客户端访问的网络和 TLS。S3 可以保存缓存对象，但配置和 SQLite 状态仍需本地持久化；完整步骤见部署指南。

v0.11.0 支持单实例部署，不支持多个实例共享数据库来实现高可用。实例不可用时，仍需访问它的依赖请求会受影响，应把恢复或切回原始源的流程纳入试用。

它也不是完整的离线镜像：未缓存的依赖仍需要上游，已有缓存是否可交付还取决于元数据、校验和策略条件。不要仅凭一次热缓存安装成功，就推断项目断网后仍能完成全部安装与构建。