web worker 应仅处理耗时、可中断、无 dom 依赖的纯计算型裁剪子步骤，如时间码解析、帧对齐、重叠检测，返回结构化映射表；主线程负责渲染、状态控制与缓存同步，通过 requestid、取消机制和防抖保障响应性与一致性。
用 Web Worker 管理网页版视频编辑器的非线性裁剪逻辑，核心不是“把裁剪代码塞进 Worker”，而是把**耗时、可中断、无 DOM 依赖的媒体处理环节**剥离到后台线程，同时保障主线程流畅响应拖拽、预览、时间轴操作等交互。关键在于分层解耦：裁剪逻辑 ≠ 视频渲染，Worker 只做“算”，不做“画”。
裁剪任务必须拆解为纯计算型子步骤
非线性裁剪（如多段选取、变速片段、关键帧标记）涉及时间码解析、帧范围校验、元数据重组等，这些不依赖 canvas 或 video 元素，完全可移入 Worker：
- 接收主线程传入的原始视频元信息（时长、帧率、轨道结构）和用户裁剪方案（如[{start: 2.3, end: 5.7, speed: 1.5}, {start: 8.1, end: 12.0, speed: 0.8}]）
- 在 Worker 内完成时间码归一化、帧边界对齐（考虑 GOP 结构）、片段重叠检测、输出时间轴映射表（如[{srcFrame: 67, dstFrame: 0, segmentId: 0}, ...]）
- 不执行解码/编码/绘制——只返回结构化裁剪描述，供主线程后续调度渲染或导出
主线程需控制裁剪请求节奏与状态一致性
用户拖动时间轴或频繁调整入出点时，会触发大量裁剪计算请求。若直接转发，Worker 容易积压、结果错乱：
- 每次发起新裁剪前，先发 {type: 'cancel', requestId: oldId} 给 Worker；Worker 内用布尔标志位快速退出循环（避免 setTimeout 或 await 阻塞）
- 为每个请求生成唯一 requestId，Worker 返回时必须携带该 ID；主线程只接受最新 ID 的结果，丢弃所有旧响应
- 输入防抖用 requestIdleCallback（比 setTimeout 更精准），仅当页面空闲且距上次裁剪 > 200ms 才提交新请求
裁剪结果不能直接执行，必须沙箱化交付
裁剪逻辑本身不产生可执行代码，但若后续要生成预览帧或导出片段，Worker 可能需调用 WebAssembly 解码器（如 FFmpeg.wasm）或模拟帧提取。此时输出必须受控：
- Worker 不直接调用 createObjectURL 或写入 ；只返回 ArrayBuffer（如单帧像素数据）或 JSON 描述（含时间戳、宽高、编码格式）
- 主线程收到像素数据后，用 OffscreenCanvas 渲染（支持 transferable），避免主线程拷贝大内存块
- 若需导出 MP4 片段，Worker 生成的是 MediaRecorder 兼容的 Blob 数据流（通过 MessagePort 传递），而非完整文件——导出由主线程用 URL.createObjectURL 触发下载
多轨道与缓存需显式同步，Worker 本身无状态
非线性编辑常含音视频轨、字幕轨、特效轨。Worker 每次运行都是无状态的，所有上下文必须由主线程显式传入：
- 主线程维护当前工程快照：{video: {src: 'a.mp4', duration: 120.5}, audio: [{src: 'b.wav', offset: 1.2}], subtitles: [...]}
- 每次裁剪请求都全量传入该快照 + 当前裁剪配置；Worker 不缓存任何文件内容，但可复用已解析的元数据（如用 importScripts('parser.js') 预载解析库）
- 对重复时间范围的裁剪请求，主线程可先查本地 Map 缓存（cacheMap.get(JSON.stringify(range))），命中则跳过 Worker 调用
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
