别让提交按钮被连续点穿：用 AI + SwiftUI disabled 防止重复提交 (2026)

提交按钮为什么会被点两次

用户点下「提交」后，网络请求通常不会立刻完成。如果按钮还保持可用，用户再点一次，App 可能会发出两个请求，结果是重复创建订单、重复发送消息，或者页面跳转两次。慢网速下，这个问题尤其容易出现。

SwiftUI 的 disabled(_:) 可以给视图加一个条件，控制用户是否还能与它交互。1 对 PM 来说，关键不是记住这个修饰符，而是先把提交过程写成一条清楚的状态链：空闲时可以提交，提交中的这一小段时间不能再次提交，成功或失败后再决定下一步。

先写清楚四个提交状态

在让 AI 改代码前，先把下面这张表写进需求或缺陷单。disabled 只解决「提交中的按钮还能不能点」，不会替你决定成功后的页面行为。

状态	按钮能否点击	按钮显示	用户下一步看到什么
空闲	可以	提交	可以修改内容并发起一次提交
提交中	不可以	提交中，加一个进度指示	请求还没结束，输入内容先保留
成功	视页面流程而定	已保存，或进入下一页	只完成一次跳转或刷新
失败	可以	重新提交	错误原因可见，用户不必重新填写

提交中可以使用 ProgressView 表示任务正在向完成推进。2 但不要只放一个转圈：按钮文字从「提交」变成「提交中」，用户更容易判断当前动作已经接收。

还有一条要先定好：本地校验失败时，不要进入提交中。只有确认必填项和格式都通过，并且准备真正发起请求时，才把状态切到提交中。

把现有提交按钮交给 AI

在 Xcode 里找到提交按钮，同时复制三段上下文给 AI：按钮所在的 View、当前表单状态，以及真正执行保存或发送的函数。只贴一个 Button，AI 很容易写出能编译的演示，却没有接上现有请求。

可以直接使用这段指令：

请只改造当前 SwiftUI 提交按钮的交互状态，不要重写网络层、数据模型、校验规则和成功后的页面流程。
请先检查当前提交动作是同步还是异步，并指出最小改动范围。增加一个只表示「请求是否正在进行」的状态，例如 isSubmitting。本地校验通过后，在真正发起请求前把它设为 true；请求完成、失败或取消时都恢复为 false。将这个状态用于提交按钮的 .disabled(isSubmitting)，提交期间把按钮文案改成「提交中」，并显示一个轻量的 ProgressView。
请保留原有输入内容和错误处理。提交失败后用户可以修正问题并再次提交，成功后只允许现有流程执行一次。请列出你改动的文件、状态变化路径，以及需要在 Xcode 里验证的连续点击、慢请求、失败重试和大字号场景。

这段指令把 AI 的工作范围限制在一个状态变量和一个按钮上。它也明确要求失败、取消都要解锁，否则一次异常请求就可能把按钮永久留在不可用状态。

只看懂这段最小结构

如果现有项目已经有异步提交函数，改动通常可以接近下面的结构。函数名和错误处理要让 AI 按项目实际代码替换，不要直接把示例当成完整业务实现。

@State private var isSubmitting = false

var body: some View {
    Button {
        guard !isSubmitting else { return }
        guard formIsValid else { return }

isSubmitting = true
        Task {
            defer { isSubmitting = false }
            await submitForm()
        }
    } label: {
        HStack {
            if isSubmitting {
                ProgressView()
                Text("提交中")
            } else {
                Text("提交")
            }
        }
    }
    .disabled(isSubmitting)
}

检查 AI 结果时，先看四个地方：

isSubmitting 是否在真正发起请求前设为 true，而不是页面一打开就锁住按钮。
.disabled(isSubmitting) 是否确实挂在提交按钮上，是否误伤了用户仍需要使用的取消、返回或编辑控件。
请求成功、失败和取消是否都能走到恢复状态的路径。defer 是一种常见写法，但要以项目的并发结构能正确编译为准。
提交中的按钮是否仍显示明确的状态，用户是否知道应该等待，而不是以为点击没有反应。

guard !isSubmitting 是第二道保护，.disabled(isSubmitting) 是用户界面的第一道保护。两者都保留，能让代码在按钮状态更新稍有延迟、或提交动作被其他入口触发时更稳一些，但它们都不是服务端的重复请求保护。

用 Xcode 验收真实边界

不要只在本地网络很快时点一次按钮。用一个能人为延迟返回的测试接口或假提交函数，按下面的顺序验收：

点击一次提交，确认按钮马上变成「提交中」，再次点击不会出现第二次提交记录。
连续快速点击按钮，确认日志里只有一次提交调用；如果页面还有键盘上的「完成」、列表行入口或快捷操作，也要检查它们不会绕过同一套提交状态。
让请求故意等待几秒，确认输入内容保留，按钮没有跳动，进度指示和「提交中」文字在窄屏上都能完整显示。
让请求返回失败，确认错误信息可见，按钮恢复可点，用户修改一个字段后可以再次提交。
在本地校验失败时点击提交，确认不会显示「提交中」，首个错误仍按原有规则展示。
让请求返回成功，确认只出现一次成功提示、一次页面跳转或一次列表刷新，不会因为重复回调再次执行。
在大字号和 VoiceOver 下操作，确认按钮的名称和当前状态都能被理解；不要把唯一反馈藏在颜色或一个看不懂的转圈里。
提交中返回上一页、关闭弹层或切换到另一个窗口，确认产品规则明确：请求继续、取消请求，还是禁止离开。不要让 AI 自己猜。

如果只测「按钮变灰了」，你验收的只是外观。真正要确认的是：状态有没有在正确的时间切换，失败后能不能恢复，成功后有没有重复执行。

这招解决不了什么

.disabled 只改变当前界面的交互条件。它不能保证网络重试、后台重复投递或多个设备同时操作时，服务端只处理一次。下单、付款、发消息、创建不可重复资源这类动作，还需要后端使用请求 ID、幂等键或等价的去重规则。PM 不一定要自己写后端，但要把这条要求写进接口验收条件。

也不要把整个表单一提交就全部锁死。如果用户需要取消请求、查看帮助、返回上一页或复制错误信息，就只锁住会重复触发同一动作的控件。锁定范围过大，用户虽然不会重复提交，却会觉得页面失控。

最后检查按钮的业务语义。如果提交动作很快完成，强行显示进度可能让界面反而显得拖沓；如果请求确实可能等待，就给用户一个明确的处理中状态，并规定超时、取消和重试怎么处理。

PM 今天可以独立完成的清单

找一个存在重复提交风险的表单，记录当前按钮、请求函数和成功后的页面动作。
写出空闲、提交中、成功、失败四个状态，以及每个状态下按钮能否点击。
明确本地校验失败时不进入提交中。
把 View、表单状态和提交函数一起交给 AI，要求只做最小状态改造。
检查 isSubmitting 是否只代表请求进行中，而不是代表表单是否有效。
检查按钮是否使用 .disabled(isSubmitting)，提交中是否有文字和进度反馈。
用慢请求测试快速连点、失败重试和成功后的单次跳转。
在窄屏、大字号和 VoiceOver 下检查按钮状态是否清楚。
对订单、付款、消息等重要动作补上服务端去重要求。

先选一个已有的保存或发送按钮完成这条状态链，再决定是否推广到其他表单。只要用户知道请求已经开始，错误时能重新操作，成功时不会重复执行，这个改造就完成了它该完成的事情。

别让提交按钮被连续点穿：用 AI + SwiftUI disabled 防止重复提交