uni-app中表单提交必须用节流而非防抖，因提交是明确动作需即时响应；输入搜索则适用防抖，但需前后端协同兜底。
页面防抖和节流在 uni-app 里不是“选配”，而是必做项；尤其按钮提交、搜索输入、滚动监听这类高频交互，不做控制，真机上大概率出现重复请求、UI卡顿、后端报错。
uni-app 表单提交该用节流还是防抖？
表单提交必须用节流（throttle），不是防抖（debounce）。防抖会等用户“停手”才发请求，但提交是明确动作——用户点一下就要立刻响应，只是不能让他连点多次。
- 节流保证「500ms 内只发一次」，既响应及时，又拦住狂点
- 防抖会导致用户点完没反应，等 500ms 才发，体验断层，且失败重试逻辑难兜底
- uView 的
u-button已内置节流（1.5.8+），直接加throttle-time="500"即可生效 - 自己手写节流时，别用
setTimeout简单 return，要靠标志位 + 定时器双控，否则真机触摸穿透会绕过判断
手写节流函数要注意 this 和定时器清理
uni-app 编译到小程序时，throttle 函数若用普通函数声明，this 会丢失；若用闭包缓存定时器但没清，多次进入页面后定时器堆积，导致节流失效。
- 节流函数必须返回新函数，且内部用箭头函数或
.bind(this)绑定上下文 - 每次调用前先检查
timer是否存在，存在就直接 return，不重设 -
setTimeout回调里必须手动置timer = null，不能只靠 clearTimeout - 不要在
onUnload里清理 timer——页面卸载时请求可能还在飞，清理反而让下次进页失效
输入框搜索该用防抖，但不能只靠前端
搜索场景下，@input 频繁触发，必须用防抖（debounce）；但只前端防抖不够，网络延迟或用户切后台再切回，仍可能漏掉中间输入。
- 防抖时间建议设 300–500ms，太短拦不住连输，太长感知延迟
- 防抖函数里别直接发请求，先校验非空、长度、格式，校验失败就提前 return，避免无效防抖
- 后端必须配合做关键词缓存或模糊匹配兜底，前端防抖只是减少请求数，不是替代服务端逻辑
- 真机调试时发现防抖“失灵”，优先查是否用了
uni.$on或addEventListener多次绑定，导致多个防抖实例共存
小程序真机上节流失效的三个隐藏原因
开发工具里一切正常，一上真机就重复提交，大概率不是代码问题，而是平台特性被忽略。
- 触摸事件穿透：按钮父容器有
catchtouchmove缺失或pointer-events: none，导致底层 view 接收了第二次点击 - 双击误判：iOS 小程序对快速双击识别不稳定，
@tap可能触发两次，得加event.detail.tapCount === 1过滤 - uni.showToast 后立即点按钮：提示框关闭动画未结束，
isSubmitting已重置，但用户已点下，此时需在uni.hideToast的 success 回调里才允许重置状态
节流和防抖的边界很清晰：按钮类操作看「单位时间最多一次」，输入类操作看「停止输入后才执行」；但所有方案都绕不开一个事实——uni-app 的生命周期、异步 API（比如 uni.showLoading）、真机事件模型，会让看似简单的定时器逻辑变得脆弱。真正稳的方案，永远是「标志位 + 时间窗口 + 后端幂等」三层兜底，而不是只信一个 debounce 包裹。
