高频计算卡顿主因是冗余触发，需用节流（如scroll每50ms一次）、防抖（如input延时200–400ms）控频；加判断跳过无效计算；超10ms运算移至web worker；数值密集场景优先用typedarray。
高频数值计算本身不慢，卡顿往往来自“不该算的时候反复算”。关键不是加速单次运算，而是控制频率、跳过冗余、卸载重活。
用节流和防抖压住触发节奏
滚动、拖拽、窗口缩放这类事件每秒可能触发几十上百次，但你并不需要每次都响应。
- 节流适合周期性更新场景：比如 scroll 中计算可视区域元素位置，设为每 50ms 最多执行一次，既保证感知流畅，又避免过度消耗
- 防抖适合用户输入类场景：数值型输入框做千分位格式化或精度校验时，200–400ms 延迟能合并多次输入，大幅减少 parseFloat / toFixed 调用次数
- 别混用——resize 用节流，input 用防抖；也别用 setTimeout 嵌套实现节流，推荐时间戳 + 定时器组合，更稳定
加轻量判断跳过无效计算
很多计算根本没必要跑完。在入口处加几行判断，省下的开销远超想象。
- 检查值是否真变了：prevValue === currentValue 或 Number.isNaN(newValue) 直接 return
- 验证输入有效性：超出业务范围（如负数传入只接受正数的函数）、无穷大、非数字，提前拦截
- 数组批量处理时善用 some/every：比如找第一个满足条件的元素，some 找到就停，不用遍历到底
- 公式结果可缓存时，用布尔标记+中间变量，相同参数直接返回上一次结果
超 10ms 的密集运算交给 Web Worker
主线程一旦被占用超过 16ms（一帧），就会掉帧、卡顿。科学计算、加密、图像像素处理等纯数值逻辑，必须移出。
- 把计算封装成独立脚本，用 postMessage 传入 Number 或 TypedArray（传输快、零拷贝）
- Worker 不能访问 DOM，所有依赖数据需序列化传递；避免传整个对象，只传必要字段
- 典型适用场景：实时 FFT 音频分析、金融复利模型迭代、大规模矩阵运算
- 注意测试耗时——用 performance.now() 实测核心函数，持续 ≥10ms 就该考虑 Worker
搭配 TypedArray 提升数值密集型操作效率
处理大量同类型数值时，普通数组会带来隐式类型转换和内存碎片开销。
- 按数据范围选最小合适类型：Uint8Array 存颜色值，Float32Array 存 3D 坐标，省内存且访问更快
- 用 ArrayBuffer + 多视图共享内存：同一块二进制数据，可用 Int32Array 读整数、Float64Array 读浮点，无需复制
- 配合 Web Worker 使用效果更佳：Worker 接收 TypedArray 后直接运算，主线程专注渲染
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
