uni-app防抖函数必须用普通函数封装，闭包捕获this并透传args，通过fn.apply(context, args)确保上下文正确；不能直接在methods里写setTimeout或使用多层箭头函数，否则this丢失。
uni-app 里防抖函数怎么写才不丢 this
直接在 methods 里写 setTimeout 会出问题：箭头函数中 this 指向丢失，fn.apply(this, args) 执行时可能报错或调用错对象。必须确保被包装函数能拿到正确的上下文。
- 用普通函数声明，显式传入
this（比如debounce(this.handleSubmit.bind(this), 500)） - 或封装时把
args和this一起保存，如fn.apply(context, args)，其中context来自闭包捕获 - 别在防抖函数内部改
this.requestStatus这类状态——那是业务逻辑该管的，防抖只负责“延迟+清除” - 示例：
function debounce(fn, delay = 300) { let timer = null return function(...args) { const context = this clearTimeout(timer) timer = setTimeout(() => { fn.apply(context, args) }, delay) } }
节流函数用在按钮上反而会引发连点
节流（throttle）不是按钮防重复提交的解法。它强制“固定间隔最多执行一次”，用户点得快，中间几次直接被吞掉，UI没反馈，人就会再点——结果更糟。
- 按钮场景必须用防抖（
debounce），目标是“最后一次点击有效” - 真正该用节流的，是
onReachBottom、scrolltoupper、地图拖拽回调等高频连续触发事件 - 如果硬要用节流，
immediate: true会导致首次点击立即执行，但后续仍可能因网络慢、无 loading 反馈而被重点 - 节流实现必须记录上次执行时间戳，不能只靠
setTimeout延迟后执行——否则无法判断“是否已过间隔”
光靠防抖函数根本挡不住真实连点
防抖只是第一道过滤，它解决不了“请求发出去了但还没回来，用户又点了一次”的问题。生产环境必须叠加 UI 锁 + 状态管理。
- 点击后立刻设
button disabled并加 loading 样式，视觉上阻断二次操作 - 用
data中布尔值（如submitting: false）做状态锁，@tap中先判断再执行 - 请求无论成功失败，都必须在
finally或complete钩子里恢复按钮状态和变量 - 不要依赖防抖延迟时间来“猜”请求耗时——网络差时 500ms 完全不够，该锁还得锁
uni-app 的 tap 事件比 click 更容易连点
小程序底层对 @tap 的响应更快、冒泡机制不同，加上 touchstart 到 touchend 的判定窗口短，手速稍快就触发多次。这不是 bug，是平台特性。
- 别指望调高防抖 delay（比如设成 1000ms）来覆盖所有情况——体验卡顿，用户流失
- 必须结合三重防护：防抖函数（过滤高频）、按钮
disabled（拦截交互）、状态变量（控制逻辑入口） - 测试时用真机连点 3–5 次，看是否只发一次请求；模拟弱网（Chrome DevTools 的 Network → Slow 3G）再测 UI 是否及时置灰
- 注意：uni-app 不支持 Vue 指令（如
v-debounce），所有封装必须走 JS 函数 +methods绑定
