E3.03.3switch not for deferred submit设计
需要提交才生效的场景不应使用开关
别名: 开关误用于表单 · deferred toggle · 提交后才生效
概念解释
只要字段的新值还要跟其他输入一起校验、签字或一次性写入，就不该用开关。随提交生效（submit-deferred）的二值属于复选框：勾选只是草案，保存才是承诺。开关的外形已经把「现在已经改了」说出去了，后面再要求按保存，等于让同一屏发出两种生效时钟。新建账户时的「接收营销邮件」、审批单上的「加急」、向导最后一步才提交的偏好，都是提交时钟，不是拨杆时钟。
这条限制针对的是时机，不是「看起来像不像开关」。把复选框画成滑块，时机错误仍然在。
机制
人不会为同一张表维持两套时钟。看见滑块，就按立即写入去计划下一步：关掉通知后立刻检查手机，而不是先填完地址再保存。若实际写入还在队尾，检查结果会对不上，用户会认为系统丢了操作，于是再拨、或放弃填后面的字段。
提交时钟需要一次明确的提交动作把多字段收成原子写入，以便失败时整单回滚。开关把单字段提前提交，原子性被切开：其余字段还在草案里，这一项却已经进了服务器。部分成功比整体失败更难解释，也更难撤销。
边界
自动保存的设置页看起来没有提交按钮，但每一项仍是独立的立即写入，开关可以用。真正冲突的是「页脚有保存，行内却是滑块」。预览态可以模拟开关，但必须标明尚未应用，且离开预览要能还原；否则预览就是一次偷偷的立即写入。弱网下的立即写入若必须排队，开关要进入未决，而不是假装已经提交成功——排队仍是立即语义下的延迟，不是改回表单提交。向导中途的开关如果会写进最终 payload、而中途退出会丢掉，中途就不该用开关。
怎么落地
- 页脚有保存、提交、下一步的屏幕上，二值字段用复选框，不用滑块。
- 若产品坚持自动保存，就去掉页脚提交，让每一项都走立即写入，不要两套时钟并存。
- 需要整单回滚的审批、签约、付款，所有二值都跟表单走。
- 验证：改一个滑块，不按保存，去另一个客户端或刷新后看值在不在。值已在，说明这不是提交场景，开关用对了；值不在而滑块已翻，就是时钟说了谎。