节流函数在游戏逻辑中用于对齐渲染节奏而非降帧，它将高频输入压缩为稳定状态快照，由requestanimationframe统一执行更新，避免布局抖动与重复计算。
节流函数在游戏逻辑循环中不是用来“降帧”或“减慢响应”，而是把高频输入、状态检查或更新操作，对齐到渲染节奏（通常是 60FPS），避免逻辑挤占主线程、引发强制重排或重复计算。
节流用于输入控制，而非替代 requestAnimationFrame
游戏里玩家按住方向键，keydown 可能每秒触发几十次；如果每次都在事件回调里直接移动角色、检测碰撞、更新坐标，会导致：同一帧内多次执行位移逻辑，但只渲染一次画面；DOM 读写混杂引发 layout thrashing；监听器或定时器未及时清理造成堆积。
正确做法是：
- keydown / gamepadbuttondown 仅记录按键状态（如 direction = { x: 1, y: 0 }），不执行任何逻辑
- 用节流（例如 100ms）限制状态采集频率，防止“抖动式输入”产生无效中间态
- 所有位置更新、动画推进、碰撞判定统一放在 requestAnimationFrame 回调中执行
节流与 RAF 的分工要清晰
节流负责“收口”——把密集输入压缩成稳定、可预测的状态快照；RAF 负责“同步”——确保这些快照只在浏览器准备绘制前一刻被消费。两者配合，既保留操作即时感（按键立刻被记录），又保障逻辑执行不干扰帧率。
常见误区：
- 在节流回调里直接修改 transform 或读取 offsetHeight → 触发布局，破坏流畅性
- 把每帧都要做的逻辑（如 UI 动画插值）也塞进节流 → 实际需要的是恒定频率，不是节流
- 用节流代替性能优化（如遍历千个敌人）→ 节流解决“太密”，不解决“太重”
滚动类游戏 UI 的节流要点
视差背景、滑动菜单、技能栏拖拽等交互常绑定 scroll 或 touchmove，原生事件频率远高于屏幕刷新率（可能达 120Hz+）。
必须做到：
- 事件监听加 { passive: true }，否则浏览器会强制同步阻塞滚动
- 节流回调只做两件事：缓存当前 scrollY 或 touch.clientY，设一个 dirty 标志
- 真实动画更新（如 translateY、opacity 插值）全部延迟到 RAF 中执行
- 避免在节流阶段调用 getBoundingClientRect、clientWidth 等触发布局的 API
节流参数要贴合游戏节奏
不能简单套用通用值（如 16ms 或 100ms）。需结合玩法设计：
- 格斗游戏连招判定：节流间隔设为 8–12ms，接近输入采样精度
- 策略类游戏单位移动：200–300ms 足够过滤微小抖动，又不牺牲操控感
- 射击游戏瞄准微调：建议用 RAF + 差分计算，而非节流，因需亚帧精度
节流本身不改变帧率，它只是让逻辑执行更可控、更可预测。真正影响流畅度的，是逻辑是否与渲染同步、是否触发昂贵操作、是否合理分层。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
