web worker 处理高频 k 线数据应采用切片合并：预分配数组、for 循环赋值、transferableobjects 零拷贝传输、节流同步更新，并在合并时做排序、去重与时间对齐。
在 Web Worker 中处理高频金融 K 线数据时，不能直接用 push 或 concat 频繁拼接数组——这会触发大量内存分配与 GC，导致主线程卡顿、Worker 自身吞吐下降。真正高效的做法是“切片合并”，即按时间窗口或数量阈值分块接收、预分配空间、批量写入，并控制主线程通信节奏。
按固定长度切片，避免动态扩容
每次收到新 K 线（如每 100ms 一批 5–20 条），不立即合并进全局数组，而是先缓存在 Worker 内部的临时缓冲区。当缓冲区达到预设长度（例如 500 条）或超时（如 200ms），再执行一次合并操作：
- 使用
new Array(expectedLength)预分配目标数组，避免多次Array.prototype.push触发内部扩容 - 用
for循环 + 索引赋值代替arr.concat()或展开运算符，实测快 3–5 倍 - 合并后清空缓冲区，复用引用，减少 GC 压力
用 TransferableObjects 零拷贝传递最终结果
合并完成的 K 线数组（尤其是含 timestamp/open/high/low/close/vol 的对象数组）体积较大。若直接 postMessage(data)，会触发结构化克隆，耗时且占内存。应转为扁平化 typed array 传输：
- 将每条 K 线序列化为 6 个连续
Float64Array元素（时间戳用毫秒整数，价格/成交量转为 double） - 合并为一个大
Float64Array，通过postMessage(arr, [arr.buffer])实现零拷贝移交 - 主线程收到后，用
new Float64Array(transferedBuffer)快速重建视图，无需解析 JSON
配合主线程的 requestAnimationFrame 节奏同步更新
即使 Worker 合并很快，主线程若每秒接收 50+ 次消息，仍会导致图表频繁重绘、CPU 占用飙升。需做节流协同：
- Worker 内维护一个“待提交标记”，每次合并后仅置位，不立即 post
- 主线程通过
requestIdleCallback或setTimeout(..., 0)主动轮询拉取（或 Worker 在空闲时主动发） - 确保每帧最多处理 1 次完整切片，匹配 KLineCharts 的
appendData批量接口能力
异常场景下的切片对齐与去重
高频行情常出现乱序、重复、跳点。切片合并阶段就要做轻量校验：
- 每个切片内按时间戳升序排序（小数组用插入排序，O(n) 平均性能）
- 合并前比对上一片末尾与本片开头的时间戳，自动剔除重复或补空（如缺失 1 秒则插 null 占位）
- 不依赖服务端保序，Worker 自带简单滑动窗口去重逻辑，保障图表渲染连续性
