企业官网建设流程全解析

很多项目里都有这样一个瞬间：用户在下单页填完信息，点了一下提交按钮，网络一卡，页面没立刻反应，他又点了一下。一秒钟后，两条几乎相同的订单落库。这类问题放在 uni-app 小程序里有统一说法，叫表单重复提交。它不是用户手速造成的偶发事件，而是代码结构里缺少拦截机制导致的必然结果。

这篇文章想聊清楚三件事：为什么常见的按钮禁用方案在小程序端经常挡不住重复提交、我在实际项目中沉淀的双层防护是怎么写的、以及那些只有跑到真机上才会暴露的边界场景。适合刚接触 uni-app 的开发者，也适合项目里已经出现重复数据但还没找到根因的团队参考。

1. 重复提交的真相：按钮的“锁”和请求的“锁”是两回事

1.1 连续点击时究竟发生了什么

每次点击按钮，事件处理函数都会被重新调用一次。如果函数内部没有判断“是否已有相同操作正在执行”，那连续点几下就会发出几条请求。这里的核心问题不在网络，而在于函数入口缺少一个“请求是否已经在途”的标记。

我在调试这类问题时习惯先打开后端日志确认请求数量，再回到前端模拟连点。实测下来用户连点两次的时间间隔通常在 100 到 300 毫秒之间，恰好是网络请求尚未返回、页面还在等待的阶段。用户感知是“没反应”，于是继续点击，而每一次点击都会触发一次真实的请求。

1.2 为什么只靠 disabled 挡不住重复提交

按钮的disabled状态本质上是视图层的表现。小程序里setData更新视图是异步的，第一次点击触发了置灰逻辑，但视图层还没完全渲染出来，第二次点击就已经进入事件处理函数了。尤其当提交按钮外层包了自定义组件，状态传递链路变长，这个窗口会更明显。

所以我会把防重逻辑分成两层：视图层负责给用户反馈，逻辑层负责真正拦截。视图层用disabled和loading让按钮看起来不可用，逻辑层必须在事件处理函数的第一行用标志位直接 return。只做前者而不做后者，线上出重复数据只是时间问题。

1.3 节流和防抖为什么不适合提交场景

很多人第一反应是用节流或防抖，这两个方案在滚动加载、搜索联想里很合适，但放在提交按钮上都有明显副作用。

节流限制的是调用频率，如果用户第一次提交失败后想立刻重试，只要时间窗没结束，合法的第二次提交就被吞了。防抖要等一段时间才执行，对于提交这种需要即时反馈的操作，延迟感会让用户反复点击，反而加剧问题。防重复提交的锚点应该放在“请求是否还在飞行中”，而不是“距离上次点击间隔多久”。所以最终我选择了请求锁，也就是“手动标志位 + 生命周期释放”的方案。

2. 第一层防线：把锁放到函数体第一行，代码要这样写

2.1 锁的载体：我为什么不用 this.data 里的标志位

在 uni-app 的 Vue 2 选项式写法里，最常见的做法是往data里加一个submitting，点击时置为 true，请求结束再置回 false。这个方案能工作，但我实际项目里更习惯用一个普通实例属性this._submitLock。

原因主要有两个。第一，锁的状态不应该参与视图渲染。如果把它放在data里，每次锁定都要触发一次setData，这在提交瞬间属于多余的性能开销。第二，锁的逻辑和视图状态分离后，后续维护的人不会因为改了按钮样式而不小心影响提交拦截逻辑。submitting仍然可以留在data里，但它只负责按钮的 loading 和 disabled 样式，不负责拦截。

对于 Vue 3 组合式写法，对应的做法是在setup作用域里用普通let变量存锁。这里要注意：不要把这个变量声明在模块顶层，否则所有页面会共享同一把锁，A 页面提交中，B 页面也提交不了，这是比不加锁更麻烦的线上事故。

2.2 一个完整的带锁提交函数

下面这段代码是我在项目里使用的模式，覆盖了锁定、校验、提交、失败和最终释放。

// Vue2 选项式写法示例 export default { data() { return { form: { name: '', amount: '' }, submitting: false // 只负责按钮 UI 状态 } }, methods: { async onSubmit() { // 锁必须是进入函数后的第一件事 if (this._submitLock) { return } this._submitLock = true this.submitting = true try { // 校验也放在锁内，别把 await 写在 lock 之前 const result = await this.checkForm(this.form) if (!result.valid) { uni.showToast({ title: result.message, icon: 'none' }) return // 校验失败时 finally 会负责解锁 } const res = await this.$request.post('/order/create', this.form) if (res.code === 0) { uni.showToast({ title: '提交成功', icon: 'success' }) setTimeout(() => uni.navigateBack(), 800) } } catch (e) { // 这里过滤掉请求层标记的重复请求 if (e && e.code === 'DUPLICATE_REQUEST') { return } uni.showToast({ title: '提交失败，请重试', icon: 'none' }) } finally { this._submitLock = false this.submitting = false } } } }

几个关键点：锁判断必须放在函数体第一行，checkForm这种异步校验必须在锁内执行。如果为了视觉上更快，把锁定放在 await 校验之后，那用户在等待校验期间连点，第二次点击照样能进来，锁形同虚设。finally里统一解锁，能保证请求失败、超时、校验不通过时锁都能释放，不会出现“点击一次后按钮永久禁用”的局面。

2.3 校验失败时锁怎么处理

上面代码里校验失败直接 return，靠finally释放锁。这意味着用户修正表单后能立刻再次提交，不会感觉到被卡住。

但有些业务场景要求“校验失败后短时间内不允许再次点击”，比如防止用户疯狂点提交导致后端同时进来多笔校验请求。这时我会把需求细化为：校验失败后按钮进入 500 毫秒的冷却期。实现上不是在finally里解锁，而是在catch分支单独处理：

try { const result = await this.checkForm(this.form) if (!result.valid) { this._submitLock = false this.submitting = false // 追加一个冷却锁 this._coolDownLock = true setTimeout(() => { this._coolDownLock = false if (!this._unloaded) this.submitting = false }, 500) return } // ... 正常提交 }

这个写法比在finally里无条件解锁更精细。不过大多数表单场景并不需要冷却期，所以我默认还是用finally统一释放，只有明确产品需求时才加冷却。

2.4 页面里多个表单时，锁的粒度要拆开

一个页面只有一个提交按钮时，单个this._submitLock够用了。但实际项目里常见的是：页面底部有一个常规提交按钮，中间还嵌着两个弹窗表单，每个弹窗都有自己的提交操作。

这种场景不能共用一个锁。弹窗 A 提交过程中，用户不该被拦着不能用弹窗 B。我会把锁改成对象结构：

data() { return { submittingMap: {} } }, methods: { onSubmit(formKey) { if (!this._submitLocks) { this._submitLocks = {} } if (this._submitLocks[formKey]) { return } this._submitLocks[formKey] = true this.submittingMap[formKey] = true try { // 提交逻辑 } finally { this._submitLocks[formKey] = false this.submittingMap[formKey] = false } } }

用formKey作为锁的维度，每个表单互不影响。这个习惯在维护复杂页面时特别重要，否则等你发现弹窗 A 提交时页面底部按钮也被禁用，排查起来会很费劲。

3. 第二层防线：在请求层做全局去重，兜底所有页面

3.1 页面锁挡不住的三类漏网之鱼

页面锁已经能覆盖大部分场景，但它不是银弹。我碰到过三类情况，页面锁完全无能为力。

第一类是提交成功后立即跳转。比如订单提交成功，页面navigateBack返回列表，用户从列表再次进入详情又提交一次，此时原页面的锁已经销毁，新页面的锁从 false 开始，拦截不住跨页面重复。

第二类是多个页面共用同一个写接口。列表页能删除数据，详情页也能删除，两个页面各自有锁，但它们调用的后端接口是同一个。如果用户在两个页面里快速操作，后端会收到两次删除请求。

第三类是加了锁但加晚了的存量代码。比如函数里先做异步校验再做请求，锁在异步之后才置位。这种代码页面锁形同虚设，线上事故往往就从这里爆发。

所以我在封装请求层时会顺手做一道全局去重。它不看页面，只看请求本身。如果完全相同的请求已经在途，后续相同请求直接拦截。

3.2 用 pendingMap 记录在途请求

核心思路是维护一个pendingMap，在每次请求发出前计算一个 key，请求完成后删除。只要 key 存在，说明相同的请求正在飞行，新请求直接拦截。

// utils/request.js const pendingMap = new Map() function getRequestKey(options) { return [ options.method || 'GET', options.url, JSON.stringify(options.data || {}) ].join('&') } function request(options) { const key = getRequestKey(options) if (pendingMap.has(key)) { uni.showToast({ title: '正在处理中，请勿重复提交', icon: 'none' }) return Promise.reject({ code: 'DUPLICATE_REQUEST', message: 'duplicate request' }) } pendingMap.set(key, true) return new Promise((resolve, reject) => { uni.request({ url: options.url, method: options.method || 'GET', data: options.data || {}, header: options.header || {}, success: (res) => resolve(res.data), fail: (err) => reject(err), complete: () => { pendingMap.delete(key) } }) }) } export default request

连接点之间的时间差通常在几百毫秒内，这段代码能保证第二次点击时，第一次请求还挂在 pendingMap 里，于是直接被拦截。complete回调无论请求成功、失败还是超时都会触发，所以锁的清理是完备的。

3.3 业务侧如何区分“重复请求”和“真实失败”

被拦截的请求返回的是一个带DUPLICATE_REQUEST错误码的 Promise 对象。业务侧在catch里要注意区分，不要让用户看到“提交失败”的错误提示。

catch (e) { if (e && e.code === 'DUPLICATE_REQUEST') { return } uni.showToast({ title: '提交失败，请重试', icon: 'none' }) }

这里有人会问：为什么不直接让第二次请求共享第一次请求的 Promise，这样两个点击都能拿到结果？我也试过，但问题在于共享 Promise 后，两个点击事件都会执行成功回调。如果成功回调里有页面跳转，用户会被跳转两次。所以对于写操作，我更推荐“第二个请求直接丢弃并提示”，而不是共享结果。

3.4 构造 key 时的三个细节

key 的构造决定了请求锁的准确度，这里有几个容易踩的坑。

第一个是对象属性顺序。JSON.stringify会严格按照对象属性顺序序列化，如果同一个接口在不同页面构造 data 时属性顺序不一致，会产生不同的 key。实际项目中表单 data 通常来自固定的数据结构，顺序基本稳定，但如果担心，可以在序列化前对 key 排序。

第二个是提交参数里不要混入随机值或时间戳。有些项目会在提交时往 data 里塞一个timestamp或者requestId，每次点击都不一样，导致 key 每次都变，请求锁直接失效。如果后端要求时间戳，构造 key 时要先把变化字段剔除，只保留业务字段。

第三个是同一接口的重复请求被拦截后，pendingMap.delete(key)必须写在complete里，不能只写在success里。请求超时或断网时，fail会触发，如果没在complete清理，key 会一直留在 Map 里，后续所有相同请求都会被误拦截。

4. 实测踩到的边界场景：回车、弹窗、回跳和条件编译

4.1 H5 端回车提交会绕过按钮拦截

在 uni-app 编译到 H5 端时，如果页面里有form组件，用户在输入框里按回车，浏览器可能会触发表单提交行为。这个行为不会经过按钮的点击事件，所以你在onSubmit第一行加的锁根本不会被触发。

我的处理是在form上阻止默认提交，或者在输入框的键盘事件里手动拦截。

<!-- #ifdef H5 --> <form @submit.prevent="onSubmit"> <input type="text" v-model="form.name" placeholder="请输入名称" @keydown.enter.prevent /> <button type="primary" form-type="submit" :loading="submitting" :disabled="submitting"> 提交 </button> </form> <!-- #endif -->

条件编译前缀保证了这段代码只影响 H5 端，编译到小程序时不会带上额外的 DOM 事件逻辑。小程序端不存在回车提交表单的问题，所以不需要这段处理。

4.2 事件冒泡导致提交被二次触发

小程序端view的tap事件存在冒泡机制。如果提交按钮外层包了一个绑定tap事件的容器，点按钮时冒泡会触发外层容器的事件，外层事件里如果又调用了提交方法，就会产生第二条请求。

页面结构类似下面这种写法时最容易踩坑：

<view @tap="onContainerTap"> <button @tap="onSubmit">提交</button> </view>

用户点击按钮，onSubmit已经执行了，冒泡又触发onContainerTap，如果onContainerTap里也做了什么写操作，问题就大了。常规解法是改成catchtap阻止冒泡，或者在按钮事件里调用stop方法：

<view @tap="onContainerTap"> <button catchtap="onSubmit">提交</button> </view>

这个点容易被新手忽略，因为它只在特定页面结构下出现。我建议凡是按钮存在嵌套容器的页面，都统一用catchtap处理提交事件，成本几乎为零，但能省去一个隐形的重复提交隐患。

4.3 页面卸载后的 setData 告警和锁残留

提交成功后立即uni.navigateBack或uni.redirectTo是很常见的交互。但请求返回的时机不一定早于页面跳转，当 finally 里的代码执行时，原页面可能已经销毁了。此时调用setData虽然不一定会崩溃，但控制台会报警告，而且如果后续逻辑里还有页面跳转，可能造成跳转混乱。

我习惯在页面生命周期里维护一个卸载标记，finally 里先判断再更新视图状态：

onLoad() { this._unloaded = false }, onUnload() { this._unloaded = true }, async onSubmit() { if (this._submitLock) return this._submitLock = true this.submitting = true try { // 提交逻辑 } finally { this._submitLock = false if (this._unloaded) return this.submitting = false } }

注意锁变量本身不需要判断_unloaded，因为它只是普通属性，页面销毁后不会再有人读取。需要保护的是submitting这种会触发视图更新的数据。

4.4 弹窗表单的手动解锁是个坑

我在维护一个老项目时见过这种写法：弹窗提交按钮里submitting置 true，然后在弹窗关闭回调里把submitting置 false。这个逻辑表面看没问题，但弹窗关闭和请求完成是两个独立的事件。如果用户提交后马上关闭弹窗，锁被提前释放，请求还在飞行，重新打开弹窗再次提交，重复请求就来了。

手动解锁必须和请求完成同步，而不是和 UI 关闭事件同步。所以提交锁的释放统一放在请求封装或finally里，不要在弹窗的close事件里碰锁状态。同样，不要在onShow里重置锁，因为onShow触发时请求可能还在途中。

4.5 条件编译处理多端差异时的思路

uni-app 的优势是一套代码多端跑，但多端的事件和交互细节并不完全一致。我的习惯是：把所有防重复逻辑收敛到一个公共请求封装里，页面里只负责 UI 层的 loading 状态。这样条件编译只需要处理交互层面的差异，不需要在每个页面里写两套防重逻辑。

如果项目里有很多表单提交按钮，可以考虑封装一个“提交按钮”组件，内部直接集成带锁的提交逻辑。业务页面只需要传入提交函数和表单数据，组件自动完成防重拦截。这也是我把请求层去重作为第二道防线的另一个原因——页面层写得再乱，只要请求层把住了关口，线上就不会出现重复数据。

5. 一次线上事故复盘：两条重复订单是怎么产生的

5.1 初看以为是网络重试

某个订单模块的后端日志里同时出现两条几乎完全相同的下单记录，时间差约 200 毫秒。第一反应是运营商网络重试或者后端重复消费消息。但排查后发现两次请求来自同一设备、同一会话，间隔只有 200 毫秒，这不符合典型的服务端重试特征——服务端重试一般会有明确的间隔或重试标记。

翻出前端请求日志对照，确认是两次独立的 POST 请求，而且都到达了后端。到这里基本可以断定，问题出在前端的重复点击，不是后端消费逻辑。

5.2 代码里真正的问题点

打开提交函数的代码，发现onSubmit先执行await this.checkForm(...)，校验通过后才调用创建订单的请求。第一次点击后，校验还没结束，第二次点击就又进入了同一个函数。两个校验都通过了，于是两条创建请求发出。

更可惜的是，按钮上其实有disabled的逻辑，可它只控制了样式，事件处理函数里并没有在入口读取状态并 return。等于加了半套防护，从安全的角度看等于没加。这正是我在第 2 章强调的：视图锁不是逻辑锁，逻辑锁必须独立存在，并且放在第一行。

5.3 修复方式和验证结果

修复分两步走。第一步是页面锁提前，锁必须在校验之前置位。第二步是请求封装加pendingMap，对完全相同且还在途中的请求直接拦截。修复后我用自动化脚本模拟连点 30 次，后端日志只收到 1 条创建请求。

这次复盘之后，我手上所有项目的关键写接口都加上了请求层去重，页面层再配合按钮 loading，基本没再出现过重复数据。如果你现在要改一个老项目，别只在前端加锁，把请求封装那一层也一起改了，效果会翻倍。这也是我做过的所有防重方案里，性价比最高的一套组合。