应动态调整防抖节流延迟：依据价格波动幅度缩放间隔，结合页面可见性、元素可视状态及用户活跃度降频，协同服务端按客户端节流能力过滤推送。
在实时股票价格刷新场景中，防抖（Debounce）和节流（Throttle）不能简单套用固定延迟值，而需根据数据变化烈度、用户交互状态和网络/渲染负载动态调整频率。核心思路是：**让延迟时间成为可响应的变量，而非静态配置**。
根据价格波动幅度自适应节流间隔
当股价剧烈波动（如涨跌幅 > 0.5% / 秒），需缩短节流窗口以保证及时性；平稳期则可放宽间隔节省资源。
实现方式：
- 维护一个滑动窗口（如最近10次更新），计算单位时间内的标准差或最大变动率
- 设定基准节流间隔（如 500ms），按公式动态缩放：
currentDelay = Math.max(100, Math.min(2000, baseDelay * (1 / (1 + volatilityScore))))
其中 volatilityScore 可为近1秒内价格变动绝对值的均值（单位：元/秒） - 每次新价格到达时重新计算 delay 并重置节流器（注意：节流器需支持运行时更新间隔）
结合用户焦点与滚动行为降频
用户未关注该股票卡片、页面被最小化、或股票列表处于非可视区域时，主动延长间隔甚至暂停更新。
立即学习“Java免费学习笔记（深入）”；
建议做法：
- 监听 document.hidden 判断页面可见性；用 IntersectionObserver 监测股票项是否在视口内
- 用户鼠标长时间未移动（如 > 30s）或键盘无输入，视为“低活跃态”，将节流间隔翻倍
- 一旦检测到 hover、click 或 scroll 事件，立即触发一次强制刷新，并恢复默认间隔
服务端推送节奏协同（避免客户端过载）
若后端通过 WebSocket 按固定频率（如 200ms）推送全量行情，客户端不应盲目接收并渲染——需与服务端协商“订阅粒度”或启用“按需拉取”模式。
实用策略：
- 前端向服务端上报当前节流能力（如 “maxUpdateRate: 600ms”），服务端据此过滤冗余推送
- 对冷门股票（日均成交额
- 当本地渲染帧率持续低于 50fps（可用 performance.now() + requestAnimationFrame 监控），自动延长 delay 并记录告警
防抖用于搜索/筛选输入，不用于价格刷新本身
需明确区分场景：价格流是**持续、不可丢弃的数据源**，适合节流；而用户搜索股票代码、切换周期等操作才适用防抖。
典型误用纠正：
- ❌ 对每条 price tick 做防抖 → 会丢失中间价格，造成跳变
- ✅ 对搜索框输入做 300ms 防抖，防无效请求；对价格渲染逻辑做动态节流
- ✅ 若需“只显示最新价”，可用防抖模拟“最终值捕获”，但必须配合心跳保活（如 5s 强制刷新一次，防止卡死）
