在 HTML 编辑器中直接实现 LRU 图片缓存不现实，因其仅处理文本，图片加载与缓存需在宿主页面中配合预览功能实现，核心是用 Map 模拟 LRU 并标准化 URL、按需加载、及时清理。
为什么直接在 HTML 编辑器里实现 LRU 图片缓存不现实
HTML 编辑器（如 CodeMirror、Monaco、ACE）本身不负责图片加载或资源生命周期管理，它只处理文本内容和语法高亮。所谓“图片缓存”，实际发生在浏览器的 Image 对象、fecth() 请求、或前端框架的资源加载逻辑中。编辑器里看到的 <img src="..."> 只是字符串，不会自动触发加载——除非你额外写逻辑去解析并预取。
因此，真正要做的不是“在编辑器里实现 LRU”，而是：在编辑器的宿主页面中，为图片预览/渲染功能配套一套 LRU 缓存策略，并与编辑器状态联动。
用 Map + 自定义类模拟 LRU 缓存，避免依赖第三方库
浏览器原生没有 LRU 数据结构，但用 Map 可以高效实现：它的插入顺序可遍历，且 delete/set 操作都是 O(1)。关键不是“多 fancy”，而是控制缓存大小、及时淘汰、避免内存泄漏。
-
Map的 key 是图片 URL（注意含查询参数，需标准化）；value 是{ img: HTMLImageElement, timestamp: number } - 每次
get(url)时，先delete再set，把该条目移到末尾（最新访问） - 每次
set(url, img)后，检查size > MAX_SIZE，若是，则用map.keys().next().value拿到最久未用的 key 并删除 - 务必在
img加载失败或编辑器卸载时调用revokeObjectURL或清除src，否则缓存的Image实例会持续占用内存
class LRUCache {
constructor(maxSize = 20) {
this.cache = new Map();
this.maxSize = maxSize;
}
get(url) {
if (!this.cache.has(url)) return null;
const item = this.cache.get(url);
this.cache.delete(url);
this.cache.set(url, item);
return item.img;
}
set(url, img) {
this.cache.set(url, { img, timestamp: Date.now() });
if (this.cache.size > this.maxSize) {
const firstKey = this.cache.keys().next().value;
this.cache.delete(firstKey);
}
}
}
图片 URL 标准化是缓存命中的前提，别忽略 query 参数和 base64
同一张图不同尺寸、压缩质量、裁剪参数生成的 URL，浏览器视为不同资源——但业务上可能想复用。比如："photo.jpg?w=200" 和 "photo.jpg?w=400" 不应共用缓存项。
立即学习“前端免费学习笔记（深入）”；
- 若业务允许模糊匹配，可在
get()前对 URL 做归一化：去掉无关 query（如v=123版本号）、统一协议和 host - 若含
data:base64 图片，建议不进 LRU 缓存——体积大、无法复用、且每次字符串都不同；应提前转成Blob+URL.createObjectURL()，再把该 blob URL 作为 key - 绝对路径、相对路径、`/api/image?id=123` 这类动态接口，必须确保服务端返回的
Cache-Control头合理，否则 LRU 缓存只是在重复做无意义 work
与编辑器联动时，只缓存“真正在预览区渲染”的图片
别一打开编辑器就扫描所有 <img> 标签并预加载——用户可能根本没滚动到那块内容，或只是临时粘贴未保存的 Markdown。缓存应按需触发。
- 监听编辑器的
scroll或renderLine（CodeMirror）/onDidScrollChange（Monaco）事件，在视口内才解析并尝试get()缓存 - 若缓存 miss，用
new Image()加载，成功后set()；失败则 fallback 到占位图，且不写入缓存（避免污染） - 编辑器内容变更（如删掉某段 HTML）时，应从缓存中清理对应 URL——可通过维护一个
url → Set<editorId>映射来追踪，但多数场景下直接不清理也问题不大，靠 LRU 自动淘汰更轻量
真正难的不是算法本身，而是判断“这张图是否值得缓存”：是缩略图？高清原图？是否带用户敏感信息？这些决策点比 Map.delete() 调用时机重要得多。
