网页端无法直接淘汰浏览器缓存，但可通过Service Worker的Cache API结合IndexedDB时间戳实现近似LRU的主动清理：监听配额阈值、按lastAccessed排序删除最旧项，并辅以语义化标签和持久化策略提升精度。
网页端本身不直接管理缓存配额或执行淘汰逻辑——浏览器的缓存（如 HTTP Cache、Service Worker Cache、Cache API）由运行时环境控制，开发者无法主动“删除最久未使用的某条缓存”，但可以通过策略组合实现**近似 LRU 的智能清理效果**。关键在于：把“淘汰权”从浏览器被动行为，转为应用层可感知、可触发、可分级的主动管理。
明确缓存载体与控制边界
先区分三类常见缓存场景，每种的淘汰能力不同：
- HTTP 缓存（通过 Cache-Control/Expires）：完全由浏览器自动管理，前端无 API 干预；只能靠响应头声明过期策略，不能按“使用时间”动态淘汰。
- Service Worker + Cache API：前端可完全编程控制，支持遍历、匹配、删除任意缓存项，是实现 LRU 式淘汰的唯一可行路径。
- localStorage / IndexedDB：虽非传统“缓存”，但常被用作持久化数据暂存；可手动记录访问时间戳，实现自定义淘汰逻辑。
用 Cache API 模拟 LRU 淘汰流程
在 Service Worker 中维护每个缓存项的最后访问时间，并在配额告警（如 storage.estimate() 接近上限）时触发清理：
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 每次
cache.match()命中后，用cache.put()覆盖原 entry，同时在 IndexedDB 或缓存元数据中更新其lastAccessed时间戳； - 监听
navigator.storage.estimate()返回的usage / quota比值，当超过阈值（如 0.85），调用清理函数； - 清理函数读取所有缓存 key，按
lastAccessed排序，批量删除最旧的 N 条（例如删掉前 20%）； - 避免阻塞主线程：用
setTimeout分批删除，每次删 5–10 条，留出空闲周期。
配合版本化与生命周期标记提升淘汰精度
纯时间维度容易误伤低频但关键的数据（如用户配置、离线表单）。建议叠加业务语义：
- 为缓存 key 添加前缀或标签，例如
api/user/profile、asset/report/v2，淘汰时优先清理带temp/或export/前缀的临时资源； - 对导出类、对账类等“一次性使用”请求，在发起时打上
ttl: "short"元数据，后续配额紧张时优先剔除； - 在 HTML 入口强制
Cache-Control: no-cache，防止 index.html 本身长期滞留导致新 JS/CSS 加载失败，间接缓解缓存膨胀压力。
规避浏览器配额机制的硬限制
Chrome 对 Cache API 的默认配额约为磁盘空间的 10%～20%，且不提供“释放配额”的标准 API。因此更务实的做法是：
- 不依赖“清空整个缓存”，而是定期修剪：每天凌晨或每次启动时，只清理 7 天前未访问的缓存项；
- 对大文件（如 PDF、视频片段）单独走 Blob URL 或流式加载，不进 Cache API，避免单个资源吃掉大量配额；
- 用
navigator.storage.persist()申请持久化存储权限，提升配额稳定性，减少因系统自动回收导致的意外失效。
