OffscreenCanvas 不能单独解决日志实时渲染卡顿，因其仅负责绘制，而文本布局、换行、滚动、搜索高亮等 DOM/CSS/JS 操作才是性能瓶颈；需结合分块预渲染、Worker 批处理与降级机制协同优化。
不能靠 OffscreenCanvas 单独解决日志实时渲染的卡顿，它只负责“画”，不负责“文本布局+换行+滚动+搜索高亮”——这些才是高频日志场景真正的性能黑洞。
为什么日志渲染卡顿和 Canvas 本身关系不大
日志流通常是纯文本、逐行追加、需支持搜索/折叠/语法高亮/自动滚动到底部。这些操作本质是 DOM 操作（textContent、insertAdjacentText）、CSS 布局（行高、字体度量、换行断点）和 JavaScript 字符串处理（正则高亮、行号计算），全部挤在主线程。即使你把“画一行文字”挪到 OffscreenCanvas，仍要面对：
- 主线程必须先完成所有文本解析、分段、样式映射，才能把结果传给 Worker
-
fillText在 Worker 的OffscreenCanvas.getContext('2d')中静默失败（不报错，也不显示） - 无法响应鼠标选中、双击跳转、右键菜单等交互，因为 Worker 里没有
getSelection()或事件系统
真正该用 OffscreenCanvas 的地方：只渲染“已排版好的位图块”
把日志当作“不可编辑的只读视图”，提前把固定高度的文本块（比如每 100 行）渲染成 ImageBitmap，由 Worker 批量生成并缓存，主线程只做拼接与滚动定位。这要求：
- 主线程控制分块逻辑：按容器高度 + 行高预估可见行数，算出需要哪几块（例如第 2000–2099 行）
- Worker 不处理原始日志字符串，只接收结构化数据：
{ lines: string[], fontSize: number, fontFamily: string, width: number } - Worker 内复用同一个
OffscreenCanvas实例，调用ctx.fillText前先用ctx.font = ...设置字体——但注意：字体必须已在主线程加载并确认可用（Worker 里document.fonts.load不可用） - 每次调用
offscreen.transferToImageBitmap()后，立刻复用 canvas，不要 new 新实例（GC 压力会反向拖慢主线程）
绕不开的兼容性与退化处理
一旦遇到以下任一情况，OffscreenCanvas 渲染链就会断裂，必须降级回 DOM：
- Safari（截至 2026 年 4 月 17 日）仍不支持
OffscreenCanvas.getContext('2d')中的字体渲染，fillText完全空白 - 用户启用系统级字体缩放（如 Windows 的 125% 缩放），Worker 里测得的
ctx.measureText().width会失真 - 日志含 emoji 或 CJK 混排时，不同浏览器对
ctx.textBaseline和垂直居中的实现不一致，导致行间错位
所以必须在初始化阶段跑一个探测函数：self.onmessage 收到测试文本后，立即 fillText + transferToImageBitmap + postMessage 回主线程，主线程用 createImageBitmap 解码并检查是否非全黑。失败则标记 useDomFallback = true，后续所有日志走 div + CSS containment: layout paint 优化。
高频追加时最容易被忽略的同步点
日志是持续写入的，但 Worker 渲染不是。常见误操作是每来一条就发一次消息、每条都触发一次 transferToImageBitmap——这会导致：
- 主线程频繁调用
requestAnimationFrame去 drawImage，帧率被拉低 - Worker 内反复创建临时字符串数组、正则匹配对象，内存碎片飙升
- 未做节流的滚动定位（
scrollTop = scrollHeight）和 DOM 插入，在降级模式下直接卡死
正确做法是：主线程用 setTimeout(() => { batchAndPost(); }, 0) 聚合最近 50ms 内新增日志；Worker 内维护一个滚动缓冲区（比如保留最近 3 屏内容），只重绘“变化区域”，其余复用旧 ImageBitmap。最终效果是：视觉上仍是“实时”，但线程负载稳定可控。
