不能用 html 直接调用 lodash.debounce，必须在 javascript 中预先创建防抖函数并绑定到事件监听器；oninput="debounce(...)" 错误，因 html 属性内执行会丢失闭包、timerid 隔离且 this 失效；正确做法是提前定义唯一引用的防抖函数，配合 maxwait、abortcontroller 和参数快照确保请求与 ui 状态一致。
直接说结论：不能用 HTML 调用 lodash.debounce，它必须在 JavaScript 运行时环境里执行；所谓“HTML 中用 debounce”本质是把防抖后的函数绑定到 DOM 事件上，不是在 HTML 标签里写函数。
为什么 oninput="debounce(...)" 是错的
HTML 属性值里写的 JavaScript 是在全局作用域即时求值的，debounce 返回的是一个新函数，你不能把它当字符串塞进属性里再执行——浏览器会报 ReferenceError: debounce is not defined 或静默失败。
- 错误写法：
<input oninput="_.debounce(fetch, 300)(this.value)">→ 每次输入都新建一个防抖函数，timerId 彼此隔离，根本清不掉前一个定时器 - 更糟的是：这个调用发生在事件触发时，
this指向可能丢失，参数也拿不准 - 正确路径只有一条：在 JS 中提前创建好防抖函数，再把它赋给事件监听器
lodash.debounce 必须提前声明、稳定复用
防抖函数的核心是闭包内共享 timerId，所以它必须是同一个引用，不能每次事件都重新生成。
- ✅ 正确：在组件
data或setup里定义一次，如search = debounce(fetchSuggestions, 500)，然后input.addEventListener('input', search) - ❌ 错误：在事件回调里写
input.addEventListener('input', () => debounce(...))→ 每次都新建函数，防抖失效 - Vue 里尤其注意：不要在
watch或@input.native的内联函数中调用debounce，那等价于每次重造轮子
maxWait 不是可选项，搜索框里它比 wait 更关键
纯靠 wait（比如 500ms）扛不住用户持续敲字。每敲一下就 clearTimeout 再 setTimeout，结果就是永远不发请求。
-
maxWait: 1000表示：不管用户敲多快，最多等 1 秒就必须发一次请求，兜底保障响应及时性 - 典型配置：
debounce(fetch, 500, { maxWait: 1000 })—— 用户慢敲，500ms 后发；狂敲，1000ms 内必发一次 - 漏掉
maxWait是线上搜索框卡顿、无响应的常见原因，尤其在移动端长词输入场景
别忘了 abort + loading 状态，否则 UI 会乱
防抖只管“节流”，不管“取消”。如果用户输 “abc” 触发请求，还没返回又输成 “abcd”，旧请求还在跑，结果可能覆盖新数据或造成状态错乱。
- 必须配合
AbortController：每次新请求前abort()上一个实例 - 必须管理 loading 状态：防抖函数开始执行时设
loading = true，请求结束（无论成功失败）再设false，否则按钮/输入框可能被误锁 - 参数快照很重要：防抖函数执行时，应使用当时保存的输入值（如
const q = input.value），而不是在 fetch 里现场读input.value，后者可能已是新值
真正难的从来不是写对那一行 debounce 调用，而是把 timer 生命周期、请求生命周期、UI 状态生命周期三者对齐。稍有错位，就会出现 loading 不消失、建议列表闪退、点击无反应这些“玄学问题”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
