表单提交必须用节流而非防抖，因提交是明确动作需即时响应；节流可防狂点且不牺牲体验，uButton已内置，手写需标志位+定时器双控，注意this绑定和定时器清理时机；@input搜索才用防抖，但须配合后端兜底。
uni-app 表单提交必须用节流，不是防抖
表单提交是明确动作，用户点一下就要响应，不能等“停手”才发请求。防抖会延迟执行，导致点击后无反馈，体验断层，重试逻辑也难兜底。
节流保证「500ms 内只执行一次」，既防狂点，又不牺牲响应感。uView 的 u-button 从 1.5.8 版本起已内置节流，直接加 throttle-time="500" 即可生效。
- 自己手写节流时，别只靠
setTimeout+return，必须用标志位（如isThrottling = true）+ 定时器双控，否则真机触摸穿透可能绕过判断 - 节流函数返回的新函数内部，要用箭头函数或显式
.bind(this)，否则编译到小程序时this会丢失 -
onUnload里不要清理定时器——请求可能还在飞，清理反而让下次进页失效；应在回调完成后再手动置timer = null
@input 搜索必须用防抖，但仅前端不够
输入框频繁触发 @input，适合防抖（debounce），典型设为 300–500ms：太短拦不住连输，太长用户感知明显延迟。
但只靠前端防抖是危险的。网络抖动、用户切后台再切回、或多次绑定事件（比如 uni.$on 或 addEventListener 重复注册），都会导致防抖“失灵”，漏掉中间关键词。
- 防抖函数里先校验输入值：
if (!keyWord || keyWord.length ，避免空请求或无效防抖 - 别在防抖回调里直接发请求，应先走校验、再调用实际请求函数，便于统一控制 loading 和错误提示
- 后端必须配合做关键词缓存或模糊匹配兜底，前端防抖只是减量，不是替代服务端逻辑
真机上节流失效的三个隐藏原因
开发工具里正常，一上真机就重复提交？大概率不是代码错，而是平台特性被忽略：
- 触摸事件穿透：按钮父容器缺少
catchtouchmove，或样式写了pointer-events: none，导致底层 view 接收了第二次点击 - 双击误判：iOS 小程序对快速双击识别不稳定，
@tap可能触发两次，得加event.detail.tapCount === 1过滤 -
uni.showToast后立即点按钮：提示框关闭动画未结束，此时按钮仍可响应，需在success回调里延后启用，或用uni.hideToast同步控制
防连点必须三重防护，光靠函数封装远远不够
防抖/节流只是第一道过滤，生产环境必须叠加状态锁和 UI 反馈。否则网络慢时用户点完没反应，必然再点——这恰恰放大问题。
- 点击后立即设
disabled = true，并配合loading样式（如置灰、加旋转图标）给出明确反馈 - 请求完成（无论 success 或 fail）后，必须在业务逻辑里手动恢复
disabled = false，不能依赖防抖函数自动解锁 - 如果用请求拦截器统一控制，注意区分接口类型：登录、支付、提交类接口需加锁，而获取配置、埋点上报等非关键请求不必锁死
防抖和节流的边界容易混淆，最常踩的坑是把节流硬套在搜索输入上，或把防抖塞进表单提交里。真正关键的不是函数怎么写，而是想清楚「这个操作用户期待何时生效」——提交要立刻响应，搜索要等最后敲定，滚动加载要匀速触发。这些判断一旦错位，再稳的代码也救不了体验。
