防抖和节流是工具而非自动优化方案；用错场景或参数会恶化体验。debounce需正确处理immediate逻辑并透传参数；throttle应据场景选leading/trailing；框架中需稳定函数引用；实时性高、必响应的场景禁用。
防抖和节流不能“自动优化体验”，它们只是工具；用错场景、参数不合理，反而会让交互变卡顿或失灵。
debounce 函数怎么写才不丢事件？
常见错误是只在定时器里 clearTimeout，却没处理「最后一次调用后立即执行」的逻辑。比如搜索框输入，用户敲完回车，你得确保这次请求发出去，而不是被清掉。
- 必须把
immediate参数作为开关：为true时首次调用立刻执行，后续触发重置定时器；为false时等停顿后再执行 - 返回的函数要能接收任意参数，并透传给原函数（用
...args） - 每次调用都要存一份新的
timeoutId，避免闭包捕获旧值导致清除失败
function debounce(func, wait, immediate = false) {
let timeoutId;
return function(...args) {
const later = () => {
timeoutId = null;
if (!immediate) func(...args);
};
const callNow = immediate && !timeoutId;
clearTimeout(timeoutId);
timeoutId = setTimeout(later, wait);
if (callNow) func(...args);
};
}
throttle 的 leading / trailing 怎么选？
滚动监听、鼠标拖拽这类高频连续动作，leading: true 能保证“动起来就有响应”；但如果你只关心最终位置（比如 resize 后重排版），trailing: true 更合适——否则窗口快速拉伸时会反复触发，而最后一次可能被截断。
-
leading控制是否在第一次触发时立即执行（默认true） -
trailing控制是否在停止触发后补一次执行（默认true） - 两者都为
false就退化成普通定时器，基本没意义 - 注意：如果
leading和trailing都为true，且间隔刚好卡在边界上，可能同一周期内执行两次
Vue/React 里直接用 Lodash 的 debounce 有坑吗？
有。Lodash 的 debounce 返回的是新函数，但 React 的 useCallback 或 Vue 的 watch 依赖数组里如果没稳定引用，会导致重复绑定或内存泄漏。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- React 中不要在 render 里直接调用
debounce(fn, 300)，应提前定义并 memo 化：const debouncedFn = useCallback(debounce(handler, 300), [handler]) - Vue 3 的
watch若监听响应式对象，且回调里用了防抖函数，需确保该函数是同一个引用，否则每次 watch 触发都会新建一个防抖实例 - Lodash 的
debounce不支持取消（cancel）时清空 pending 状态，自定义实现更可控
什么时候不该用防抖或节流？
实时性要求高的场景，比如游戏按键、手写笔迹、语音输入状态更新——这些需要每一帧或每次事件都响应，加防抖/节流等于主动丢帧。
- 表单校验：输入中实时提示可以节流（如每 500ms 校一次），但失焦（
blur）必须立刻校验，不能防抖 - 接口请求：防抖适合搜索建议，但提交按钮点击必须立刻发请求，防抖会导致用户点了没反应
- 动画控制：用
requestAnimationFrame替代节流，它天然对齐屏幕刷新率，比基于setTimeout的节流更精准
最常被忽略的一点：防抖节流解决的是「频次问题」，不是「性能问题」。如果函数本身执行慢（比如遍历万级数组），光防抖没用，得先优化函数内部逻辑。
