最轻量可控的防抖方式是 setTimeout + 响应式标志位：提交前判断 isSubmitting，为 true 则 return；设为 true 后启动 1500ms 定时器重置，且必须放在请求发起前、finally 中清除，避免漏请求或重复提交。
uni-app 表单提交时怎么加防抖
直接用 setTimeout + 标志位是最轻量、最可控的方式，比套第三方节流库更稳——uni-app 的生命周期和异步行为（比如 uni.showToast 后的延时）容易让节流逻辑错乱。
常见错误是只在点击事件里设 disabled，但用户快速连点+网络慢时，button 状态恢复了，请求其实还在后台发着；或者用了 lodash.throttle 却没清空定时器，导致多次提交堆积。
- 声明一个响应式变量控制按钮状态：
data() { return { isSubmitting: false } } - 提交前判断：
if (this.isSubmitting) return; - 设标志位 + 定时器重置：
this.isSubmitting = true; setTimeout(() => { this.isSubmitting = false; }, 1500); - 务必把
setTimeout放在请求发起前，而不是then或finally里——否则失败重试时会被卡住
uni-app 的 uni.request 怎么配合防抖不漏请求
防抖不是“丢请求”，而是“等上一次发完再发下一次”。如果用户填完立刻点两次，第二次应该被忽略；但如果第一次失败了，第二次就得顶上——这得靠业务逻辑兜底，不能全靠防抖。
典型坑是把防抖和 loading 混为一谈：uni.showLoading 关闭不代表请求结束，uni.request 的 fail 回调可能滞后，此时若已重置 isSubmitting，就又放行了重复提交。
- 防抖标志位必须和请求生命周期强绑定：发起请求前设
true，无论成功失败都在finally里设false - 别依赖
uni.hideLoading()的时机，它和网络请求无直接关系 - 后端也建议加幂等 key（如
form_id或时间戳哈希），前端防抖只是第一道防线
为什么不用 lodash.debounce 直接包 submit 方法
会出问题。uni-app 编译到小程序时，lodash 的闭包和 this 指向容易丢失；H5 端倒是可以，但多端一致性差，而且 debounced 函数无法被 Vue 响应式系统追踪，isSubmitting 状态更新不同步。
更麻烦的是，debounce 返回的新函数每次调用都可能延迟执行，而表单校验、参数拼装这些前置逻辑如果写在 debounce 外面，就会被反复执行；写在里面，又没法做同步校验反馈（比如弹个 uni.showToast({ title: '请填写手机号' })）。
- 防抖逻辑要拆成两层：同步校验（立刻执行）+ 异步提交（带防抖）
- 不要把整个
submitHandler传给debounce，只包真正发请求的部分 - 如果真要用，确保
lodash.debounce在onLoad里初始化，并用箭头函数绑定 this
小程序真机调试时防抖失效的几个原因
开发工具里跑得挺好，一上真机就重复提交，大概率是触摸事件穿透或双击误判导致的。iOS 微信内置浏览器对 touchend 和 click 的触发有延迟和合并行为，uni-app 的 @tap 绑定有时会触发两次。
- 统一用
@tap，别混用@click（尤其 H5 端） - 在
button上加catchtouchend阻止冒泡，避免父容器重复捕获 - 检查是否在
scroll-view内部嵌套了可点击区域，滚动过程中松手可能触发意外 tap - 真机测试时打开 vConsole，打印
isSubmitting变化，确认是不是状态没及时更新
