企业官网建设流程全解析

简介：一份基于Canvas开发的时间轴交互插件，源自实际视频回放项目，适合Web前端工程师或需要快速实现时间轴功能的开发者。插件涵盖拖动时间轴、点击返回指定时间点、动态增加录像块、视图放大缩小等常见操作，能够满足安防监控、视频编辑等场景中对时间定位与片段时间块的展示需求。资源为zip压缩包，共6个文件，其中3个JavaScript文件负责核心逻辑与依赖（含jQuery 1.10.2），2个HTML文件为可直接运行的使用示例，1个Markdown文档提供说明。整体体积仅90KB，轻量易集成，便于在此基础上理解Canvas绘图与鼠标/触摸事件的结合方式。目前已有4077人学习/下载，验证了其在同类需求中的实用价值。下载后可从示例页面入手，快速查看插件初始化、回调事件与样式配置；深读源码可学习如何用原生Canvas绘制刻度、录像块和拖拽手柄，以及如何将时间轴交互与外部播放器状态同步。对于正在开发视频回放、录像检索或时间轴标注功能的读者，这套代码提供了完整的参考实现与改造起点。

1. 用 Canvas 自研时间轴插件前，先想清楚这几个问题

做监控录像回放、云存储检索、录播课复盘这类产品时，时间轴始终是绕不开的交互核心。很多人第一反应是拿现成组件改一改，或者用一堆 DOM 绝对定位硬拼，但等录像块到了几千条、拖到 7×24 小时跨度时，DOM 方案会明显卡顿，选中态、缩放重排还会经常顾此失彼。这也是我最终转向 Canvas 自绘时间轴的原因：画布只负责像素输出，数据和渲染彻底分离，把拖动、点击返回时间点、录像块增删、放大缩小全部建立在一条像素与时间戳的换算链路上，实现反而比 DOM 方案更简单、更可控制。

这篇文章我会把这个方向拆成四条主线：坐标系怎么建、拖动与点击怎么命中、录像块数据结构怎么设计、缩放时的视觉锚点怎么处理，最后集中讲五个最常见的踩坑点。适合的对象很明确：要么正在给某个回放系统做时间轴，要么评估过但被交互细节劝退了的人。照着我给出的最小命令和代码路径走，两三天就能拿到一个可以继续加功能的自绘版本。

2. Canvas 时间轴的地基：坐标系、像素刻度与最小骨架

2.1 为什么核心选择落在 Canvas，而不是 DOM 定位或 SVG

在拆代码之前，先说明为什么这条路值得走。时间轴的本质是一段一维时间到一维像素的映射，而录像块、播放头、选中框全都是在这个映射关系上的矩形绘制。用 DOM 实现时，每个录像块都是一个独立节点，定位改一次就要触发一次重排；设计 10 万像素宽度的 7×24 小时轴时，大量节点的创建、移动、销毁会让主线程应接不暇。SVG 虽然保留了 DOM 事件，但几千个 rect 节点同样让事件绑定和重绘成为瓶颈。

Canvas 的做法是全量重绘：数据不在节点里，而在内存数组中；每次交互只改数据，再统一绘制。单个绘图指令的 GPU 加速使得一次几百个矩形的绘制成本远比改动几百个 DOM 节点低，而且 Canvas 天然支持点击命中检测（见 2.3 的坐标换算与反算），不用像 DOM 那样递归冒泡。这个选择在录像块数量超过 200 条时优势会非常明显，数据量小时也并无劣势，界面上看起来像素级一致。

2.2 最小骨架：画一条时间刻度和像素底图

第一版不需要弹出菜单、颜色管理、交互逻辑，先验证一条链路：把时间戳变成 x 坐标，把 x 坐标变回时间戳。下面这个骨架代码是我常用的起步写法，能跑出刻度和每小时的灰度背景，是整个插件的最底层基础设施：

const canvas = document.getElementById('timeline'); const ctx = canvas.getContext('2d'); const dpr = window.devicePixelRatio || 1; // 时间范围，单位秒；默认看最近 24 小时 const timeline = { startTime: Date.now() / 1000 - 86400, endTime: Date.now() / 1000, pixelsPerSecond: 2, // 初始密度：每秒 2 像素 width: 0, }; function resize() { const rect = canvas.getBoundingClientRect(); canvas.width = rect.width * dpr; canvas.height = rect.height * dpr; ctx.setTransform(dpr, 0, 0, dpr, 0, 0); timeline.width = rect.width; draw(); } function timeToX(t) { return (t - timeline.startTime) * timeline.pixelsPerSecond; } function xToTime(x) { return timeline.startTime + x / timeline.pixelsPerSecond; } function draw() { ctx.clearRect(0, 0, timeline.width, canvas.height / dpr); const hourSec = 3600; const hourW = hourSec * timeline.pixelsPerSecond; // 画每小时交替背景 for (let i = 0; i < timeline.width / hourW; i++) { ctx.fillStyle = i % 2 === 0 ? '#f7f8fa' : '#ffffff'; ctx.fillRect(i * hourW, 0, hourW, 28); } // 画刻度线：每 5 分钟一条短刻度，每小时一条长刻度 ctx.strokeStyle = '#d0d7de'; ctx.fillStyle = '#57606a'; for (let t = Math.ceil(timeline.startTime / 300) * 300; t <= timeline.endTime; t += 300) { const x = timeToX(t); const major = (t % 3600 === 0); ctx.beginPath(); ctx.moveTo(x, major ? 20 : 24); ctx.lineTo(x, 28); ctx.stroke(); if (major) ctx.fillText(formatClock(t), x + 4, 14); } } function formatClock(t) { const d = new Date(t * 1000); const hh = String(d.getHours()).padStart(2, '0'); const mm = String(d.getMinutes()).padStart(2, '0'); return hh + ':' + mm; } resize(); window.addEventListener('resize', resize);

这段代码里有三个点是你后续所有功能的基石，需要讲清楚。首先是 devicePixelRatio 处理：不乘 dpr 的话，在 Retina 屏上画出的线条会明显发虚，拖动时更加明显，所以初始化画布宽高必乘 dpr，再通过 setTransform 把坐标系映射回 CSS 像素，之后所有绘图代码都不需要感知物理像素。

其次是时间范围的锚定方式。startTime与endTime是插件的唯一事实来源（single source of truth），所有像素换算都相对它们计算，不做任何状态缓存。pixelsPerSecond可以直接理解为缩放级别，2、4、8、16、32、64 这种 2 的幂次档位，避免非整数倍缩放造成的刻度突变，这是体验上很重要的一个细节。

最后是刻度步长的计算，代码里用 300 秒（5 分钟）作为基础步长。实际工程中你会发现，pixelsPerSecond 变大时，5 分钟刻度会挤成一团。我一般会根据比例自动跳档：hourW小于 120 像素时只画 1 小时刻度，大于 120 时切到 30 分钟，再扩展到 5 分钟。你可以在 draw() 开头先把 hourW 算出来再决定步长，这和录像机厂商播放器里的自适应刻度是同一种机制。

2.3 点击命中的根基：时间戳↔像素双向换算的精确定义

很多人踩过这类坑：鼠标点下去播放头没到位，差了几秒甚至几分钟；拖到一半再缩小时间轴，播放头自己飘走了。根因都是换算函数不够封闭——有的实现里把「当前时间」单独存成一个 state，绘制时又再算一次，两边就产生了细微偏差。

正确的做法是：所有交互逻辑只依赖 timeToX 和 xToTime 两个纯函数，播放头的位置永远从当前时间实时计算，不缓存绘制坐标。拿点击返回时间点这个功能为例，点击事件拿到的是 CSS 像素坐标，要先用rect.left减掉画布偏移，再传给 xToTime：

canvas.addEventListener('pointerdown', (e) => { const rect = canvas.getBoundingClientRect(); const px = e.clientX - rect.left; const t = xToTime(px); // 播放头是一等公民，先移动它 setCurrentTime(t); });

这段逻辑的坑不在事件绑定，而在边界处理。要在 xToTime 里做 clamp，把返回值限制在[startTime, endTime]区间内，不然点击画布左侧空白处会产生负时间；同时点击右侧时可能出现超出界面的时间戳。另一个历史上常被遗忘的细节是：交互拿到的是 CSS 像素，绘制时用的是变换过的物理像素坐标系，两套坐标体系之间不需要手动转换，因为 setTransform 已经铺好了路，这里千万不要自己再乘一次 dpr，否则会翻车。

3. 拖动播放头与点击返回：事件模型选型和命中策略

3.1 用 pointer 事件统一鼠标与触控，避免 mouse 事件的三件套后遗症

早期实现方案大多基于mousedown、mousemove、mouseup三件套。这套方案在触屏设备上会遇到一个很尴尬的局面：手指按下去时浏览器会同时触发滚动、长按菜单、触摸事件与鼠标事件的顺序问题。后来我统一改成pointerdown、pointermove、pointerup，一套逻辑同时覆盖鼠标、触笔和手指，还能拿到pointerId做多点触控区分。

拖动播放头的基本流程分四步：pointerdown 时记录起始像素、判断是否命中播放头热区；pointermove 中把即时像素转为时间戳并更新数据；pointerup 收尾释放指针捕获；最后统一走 draw() 重绘。注意 pointermove 里一定要做节流，用requestAnimationFrame标记位，否则每秒几百个输入事件会对 Canvas 高密度绘制造成额外压力：

let dragging = false; let rafPending = false; function setCurrentTime(t) { timeline.currentTime = Math.min(Math.max(t, timeline.startTime), timeline.endTime); } canvas.addEventListener('pointerdown', (e) => { const px = e.clientX - canvas.getBoundingClientRect().left; const t = xToTime(px); const hitX = timeToX(timeline.currentTime); // 播放头热区 12px，命中才开启拖动 if (Math.abs(px - hitX) <= 12) { dragging = true; canvas.setPointerCapture(e.pointerId); } }); canvas.addEventListener('pointermove', (e) => { if (!dragging) return; // 核心：不在 move 回调里直接 draw，只记录坐标 const px = e.clientX - canvas.getBoundingClientRect().left; if (!rafPending) { rafPending = true; requestAnimationFrame(() => { setCurrentTime(xToTime(px)); rafPending = false; draw(); }); } }); canvas.addEventListener('pointerup', (e) => { dragging = false; canvas.releasePointerCapture(e.pointerId); });

这段额外写了setPointerCapture而不是依赖 mousemove 自带的命中特性，原因是拖动一旦移出画布边界，不带捕获的话事件源会切换，播放头就卡在边缘了；捕获后事件持续流向画布，体验和原生播放器一致。当前时间更新后还要主动通知外部系统，通常我在这里抛一个onCurrentTimeChange(t)回调，通知视频播放器做 seek，而不是让插件直接控制视频元素，这样插件和播放器解耦，可以复用到非视频场景。

3.2 点击空白区域返回具体时间点：判断什么该响应、什么不该响应

点击返回的语义不是一键回到某个预设位置，而是“单击时间轴任意位置，播放头跳到该处”。但直接无脑跳会带来两个问题：用户想点录像块本身来编辑，却触发了跳转；用户想拖拽选中区域，却触发了跳转。所以点击命中要分层。

我的做法是：先遍历录像块数组看点击坐标是否落在某个块内，如果落在块内就不触发跳转，交给块的 click 处理；如果没落在块内，才执行播放头定位。这个分层顺序很关键，一定不能反过来，否则录像块自身的编辑永远弹不出来：

canvas.addEventListener('pointerup', (e) => { const px = e.clientX - canvas.getBoundingClientRect().left; const t = xToTime(px); // 先看是否命中录像块 for (let i = blocks.length - 1; i >= 0; i--) { const b = blocks[i]; if (t >= b.start && t <= b.end) { // 命中录像块，交给块的逻辑处理（如弹详情） onBlockClick(b, e); return; } } // 没命中块，再看是否点了播放头 if (Math.abs(px - timeToX(timeline.currentTime)) <= 12) return; // 都不是，执行点击返回时间点 setCurrentTime(t); draw(); });

这段主要想表达两点判断逻辑。第一层，命中检测走倒序遍历，这样上层块会优先于底层块被命中，和视觉层级保持一致。第二层，播放头热区需要额外留白，12 像素是手指触控的最小宽度，鼠标用户也不会觉得太宽。还有个小坑：如果把逻辑放在pointerdown而不是pointerup，用户想框选区域时会看到播放头先跳了一次，所以跳转动作放pointerup更符合编辑习惯。

3.3 录像块也可拖动微调：选中、偏移计算与重绘的关系

录像块不是静态贴上去的贴纸，至少两个场景要求它必须可以拖动：多段时间轴里用户想调整某段录像的起止，或者在剪辑时对某一段切头去尾。实现方式与播放头类似，但额外要管理三态——未选中、选中、拖拽中。未选中画灰色描边块；选中画外发光边框；拖拽时要把原始起点坐标记下来，注意必须基于 timeToX 实时算，绝不能缓存拖动前的像素坐标，因为拖拽过程中可能触发缩放。

拖拽录像块时的偏移计算，核心是「起点对齐」还是「终点对齐」。我一般实现为：按住块的中部进入平移模式，按住头部边缘 6px 内进入起点调整模式，按住尾部边缘 6px 内终点调整。三种模式用同一个 mousedown 判定，逻辑上的区分点在命中时记录的dragMode：

function hitTestBlock(px) { const t = xToTime(px); for (let i = blocks.length - 1; i >= 0; i--) { const b = blocks[i]; const x1 = timeToX(b.start); const x2 = timeToX(b.end); if (px >= x1 - 4 && px <= x2 + 4) { if (px - x1 <= 6) return { block: b, mode: 'resize-left' }; if (x2 - px <= 6) return { block: b, mode: 'resize-right' }; return { block: b, mode: 'move' }; } } return null; }

这段 hitTest 要注意一个原则：录像块的几何位置永远从时间和缩放级别实时换算，不缓存。许多初版实现会在拖动时改块的 x 坐标，一旦缩放级别改变，块的位置就彻底乱了。正确的做法是拖拽时只改块的start和end时间，坐标永远由 timeToX 现算。缩放和拖拽两条链路虽然都作用于时间轴，但数据入口完全独立，互不污染。

4. 录像块的数据结构与放大缩小的锚点算法

4.1 录像块数组与渲染：字段怎么设计、颜色怎么映射、点击后的行为挂在哪

录像块的字段设计会直接影响后续所有功能的复杂度。我按实际项目需要保留以下字段，你可以按需增减，但四个基础时间字段尽量不要省略：

渲染录像块时，除了矩形的起始坐标，还必须在顶部留出 2px 的录制状态色条。这是监控回放产品的常见细节：每段录像块内填充色用低饱和度底色，顶部一条颜色鲜艳的状态条表示录像源类型，用户一眼看出哪些是定时录像、哪些是报警联动录像。绘制和校验同在一个循环里，块宽低于 8px 时只画 2px 竖条，不画文字，避免文字挤压重叠：

function drawBlocks() { const top = 32, height = 46; for (const b of blocks) { const x1 = timeToX(b.start); const x2 = timeToX(b.end); const w = x2 - x1; // 宽度不满足 8px 时降级为竖条，视觉更干净 ctx.fillStyle = typeColorMap[b.type].bg; ctx.fillRect(x1, top, w, height); ctx.fillStyle = typeColorMap[b.type].accent; ctx.fillRect(x1, top, w, 2); // 宽度足够再画名称+时间范围 if (w >= 52) { ctx.fillStyle = '#24292f'; ctx.font = '11px sans-serif'; ctx.fillText(b.name, x1 + 4, top + 18); } } }

块的颜色映射建议单独维护一个typeColorMap，而不是写死在代码里。报警、计划录像、手动录像各占一条，以后从后端接口扩展新类型时只要加一个映射项就行。这里额外提醒一个渲染细节：for 循环里不要频繁在 fillStyle 属性之间切换，超过 100 个块时比较影响渲染效率；可以在循环体外先按 type 分组，同色批次连续绘制，Canvas 内部的 fillStyle 切换成本会明显下降。

4.2 放大缩小时以鼠标位置为视觉锚点：公式推导与防抖设计

时间轴的缩放交互，用户当前视觉中心要么在鼠标位置，要么在当前播放头位置。实现逻辑上两者等价，只需给定一个锚点时间戳anchorT，缩放后该时间戳所在的屏幕 x 坐标保持不变。推导过程很简单：缩放前anchorT的屏幕坐标为x_anchor = (anchorT - startTime) * oldPps；缩放后要让(anchorT - newStartTime) * newPps === x_anchor，所以新的起始时间等于anchorT - x_anchor / newPps。

对应到代码里，就是先记录鼠标所在的时间，再更新pixelsPerSecond，最后计算新startTime：

canvas.addEventListener('wheel', (e) => { e.preventDefault(); // 阻止页面滚动 const rect = canvas.getBoundingClientRect(); const px = e.clientX - rect.left; const anchorT = xToTime(px); const factor = e.deltaY < 0 ? 1.5 : 1 / 1.5; const newPps = clamp(timeline.pixelsPerSecond * factor, 0.5, 1024); // 核心：缩放后 anchorT 的屏幕位置保持不动 const anchorXBefore = (anchorT - timeline.startTime) * timeline.pixelsPerSecond; timeline.startTime = anchorT - anchorXBefore / newPps; timeline.pixelsPerSecond = newPps; // 限制平移范围，防止缩到时间范围之外 timeline.startTime = Math.min(Math.max(timeline.startTime, 0), timeline.endTime - 300); draw(); });

这里我额外加了factor = 1.5和上下界[0.5, 1024]。0.5 意味着 7 天能塞进一屏，1024 意味着单分钟占 60 像素，能看清细节漏录；这两个值按实际场景调整：如果是安防回放，建议下界放宽到 0.02，对应整月视图。e.preventDefault()之所以显式写出来，是因为 wheel 事件默认会滚动页面，不阻止的话放大缩小时整页乱跳。

缩放时还有两个养成习惯。一个是startTime的范围 clamp 必须做，不然缩放到最左端之后继续缩小，时间轴会跑到负数区间去，再想拖回来就会出现空白轴；另一个是 resize 和 wheel 触发的 draw 要共用同一条 rAF 队列，连续滚轮事件在 16ms 内合并成一次绘制，不然快速缩放时帧率会掉，在慢速设备上甚至会出现视觉上的抖动。

4.3 缩放级别与时间刻度自适应：30 分钟档、5 分钟档怎么平滑切换

许多半成品插件在缩放中间态会露出一个问题：刻度标签密度失控。放大到每像素 16 秒时，5 分钟一刻度完全没必要，也不会挤成一团；但缩小到 1 像素代表 1 小时时，5 分钟刻度之间只有 5 像素，标签全部重叠。刻度的步长必须是一个动态函数，和当前pixelsPerSecond挂钩。

我的刻度算法分成三个区间：小时刻度始终画；半小时刻度在小时宽度大于 90px 时画；5 分钟刻度在小时宽度大于 180px 时再画。你也可以再细分一层，2 分钟级在小时宽大于 600px 时画。这套区间互相独立，绘制时只是多几层 for 循环：

const hourW = 3600 * timeline.pixelsPerSecond; if (hourW >= 90) { /* 画 30 分钟刻度 */ } if (hourW >= 180) { /* 画 5 分钟刻度 */ } if (hourW >= 600) { /* 画 1 分钟刻度 */ }

这个做法的好处是不用写复杂的取模逻辑，刻度切换完全由像素宽度自然驱动。更讲究一点的实现还会在切换临界点做渐变淡出旧刻度再淡入新刻度，但那是后话，基础版本先用直接切换即可。视觉上注意长刻度配标签，短刻度只画线不出字，避免小字号拥挤产生的廉价感。

5. 自研 Canvas 时间轴的高频踩坑：五个值得记录的问题

5.1 高 DPI 屏幕下时间轴文字模糊，线条发虚

现象：在 Retina 屏幕上有明显模糊感，时间数字和刻度线边缘全是毛刺，长时间操作后眼睛特别累。看起来是 canvas 默认渲染质量问题，改字体大小没有效果。

原因：canvas 的width属性是物理像素，单位默认是 CSS 像素 1:1。不处理 dpr 时，高分屏会用 2 个物理像素显示 1 个逻辑像素的图形，但 canvas 渲染时只用了逻辑分辨率，导致浏览器做了二次放大插值，画面自然变糊。

解决：初始化时把画布物理宽高设为 CSS 宽高的 dpr 倍，同时调用ctx.setTransform(dpr, 0, 0, dpr, 0, 0)，之后所有绘图全部按 CSS 像素坐标走。注意 resize 事件里也要重新设置物理尺寸和 transform，窗口改变时如果漏了，恢复窗口大小后同样会模糊潜藏下来。这是我到现在每次拿到新项目都会第一时间落地的基础设施，避免了后续反复排查。

5.2 播放头拖出画布再回来，时间戳跳变

现象：拖动播放头向左快速移动，松手时间戳不是预期的秒数，忽前忽后；在较慢的设备频率下尤为明显。

原因：pointermove 事件频率远高于 rAF（通常 60Hz），每次 move 都同步更新播放头时间戳，两个连续事件之间产生了时间戳回退。另一个来源是：move 里做了setCurrentTime(xToTime(px))，但没有用 rAF 合并，导致时间戳在计算时快时慢。

解决：按 3.1 的样式增加 rAF 标记位，让 timeStamp 的同步频率与绘制频率一致。注意这里不要为了省事直接降低 pointermove 的监听频率，触控板的惯性滚动事件间隔不规则，频率过滤会造成拖拽边缘卡顿；正确的做法是保留全部输入事件，只在绘制层做合并。

5.3 缩小时间轴后录像块不翼而飞或重叠成一坨

现象：编辑好的录像片段，执行缩小操作后有些块突然消失，有些块颜色条挤在同一个像素行里，无法分辨先后顺序。

原因：渲染层直接按timeToX(b.start)与timeToX(b.end)计算，但缩放后startTime变了，而有的实现是在用户拖拽录像块时才更新块的位置，两套信息不同步。更隐蔽的原因是缩小时像素宽度不足 1px，渲染函数认为宽度为负直接不画了。

解决：录像块位置永远实时根据 timeToX 计算，不缓存坐标。对宽度小于 1px 的块要设置最小可见宽度，我在 4.1 里说到的竖条降级就是为这个坑准备的。再补一个标准做法：把 width 小于 2px 的块统一绘制成 2px 竖条，这样缩到单月视图时还能看出哪些时间段有录像，而不是凭空消失。

5.4 缩放时整页在滚动，滚轮方向混乱

现象：鼠标悬停时间轴上滚轮，页面上下滚动而不是时间轴缩放；在某些浏览器里偶尔还会缩放页面字体。

原因：wheel 事件默认行为是滚动容器。canvas 区域的滚轮事件不做 preventDefault 就会被浏览器接管，chrome 系的页面缩放快捷键Ctrl + 滚轮同样会走同一事件通道。

解决：监听 wheel 时显式添加{ passive: false }，并在回调第一行阻止默认行为。这段代码要注意兼容性：passive 默认值在不同浏览器版本里不同，旧版本对 addEventListener 第三个参数支持有差异，建议用 try/catch 动态检测被动事件是否可用。只要挂上 preventDefault，页面本身的滚动和浏览器缩放快捷键在画布区域就不会再触发。

5.5 大量录像块导致渲染掉帧，拖动到 200 条后开始卡顿

现象：时间轴只有 20 个块时一切正常，增加到 200 个后拖动播放头开始掉帧，CPU 占用飙升，在集成显卡设备上尤其明显。

原因：每一个块从 timeToX 开始经过 fillRect、fillText 多次绘图调用，200 个块的全部重绘成本相当可观。更严重的是拖动播放头时每一帧都执行了完整重绘，而页面顶部区域完全不需要参与刷新。

解决：两个方向同时做。第一，把播放头区域、当前时间文本、录像块列表拆分到两个 canvas 图层，播放头本身在顶层独立移动，拖动时只重绘顶层画布的局部区域，底层画布不动，这样把每帧的开销从 O(块数) 降到了 O(1)；第二，块数量超过 500 时用离屏 canvas 把静态刻度背景预渲染一次，缩放完成后再把离屏画面 drawImage 到主画布，连续拖动时只做一次绘制。这两个优化叠加后，千块级别的轴也能保持流畅。

6. 自绘时间轴的性能验证与两处值得继续深挖的优化

完成功能只是第一步，交付前建议把性能验证插到开发流程里。最简单的方式是在 draw() 前后各取一个performance.now()，把耗时直接输出到页面角落，确认稳定在 16ms 以下，也就是 60FPS 的预算。用性能计时器时要注意：debug 输出本身有成本，建议用url参数开关控制，只在调试时打开，不会污染线上逻辑：

function draw() { const t0 = performance.now(); // 原有绘制逻辑 const dt = performance.now() - t0; if (debugMode) console.log('draw cost:', dt.toFixed(2) + 'ms'); }

另一个值得继续做的优化是脏矩形重绘。当只拖动播放头时，改动只影响播放头左右各 12px 的范围内，用ctx.clearRect把这个窄条清掉重绘即可；但缩放和录像块拖拽时改动范围大，反而全量重绘更干净。所以优化要按交互类型区分：高频小改动走局部重绘，低频大改动走全量重绘，两个通道分开处理。

关于缩放，我最后的建议是做一个「动画过渡」：滚轮缩放时不要瞬间跳到目标 pps，而是在 100ms 内从当前 pps 线性插值到目标 pps。这样做的原因有两个：一是人眼需要一个短暂的视觉收敛过程，直接跳变会让人找不到方向；二是监播联动场景中，录像显示区域如果与时间轴实时同步，跳变会引发下游组件连续多次布局计算，插值可以把下游更新摊到一个动画周期里均匀处理，整体体感平顺很多。

回想我从初版十几块都卡顿的 DOM 方案折腾到今天，最大的教训是「先锁定换算关系，再谈交互」。录像轴所有看似复杂的交互，本质上都只有timeToX / xToTime这一条逻辑闭环，数据结构稳定了，借力打力地往上加什么功能都顺了，希望这套思路对你也有帮助。

本文还有配套的精品资源，点击获取