已填内容的字段被隐藏时需明确其数据是否仍会提交
别名: 隐藏后还提交 · stale hidden value · 条件字段残留
概念解释
人填过发票抬头，又取消「需要发票」，抬头那一项从屏幕上消失。是否仍会提交必须有一个被说出来的规则：要么值被丢掉、这次订单没有发票；要么值还在载荷里，只是暂时不显示。沉默会让两种预期同时存在。这条不谈显隐要不要能猜到，只谈隐藏之后这份已填数据的去向。阅读器顺序和维护复杂度是另两件事。
机制
可见性被当成「还在不在这份表里」的证据。人取消条件，是想取消那一块的后果，包括已经打进去的字。若 DOM 里 display:none 的输入仍带着值随表提交，服务器会按「有抬头」去开票，人却以为自己关掉了发票。反过来，界面把值清掉却不说，人再打开条件时发现空白，会以为系统吞了输入。第二层是往返：条件被反复开关时，保留值方便再打开，但提交必须跟当前条件走——关着的分支不得进载荷。规则可以是「隐藏即不提交、值留在客户端直到再打开」，但必须写在取消动作旁边，不能只写在开发注释里。跨步的向导把隐藏值放进全局 store，更容易在最后一步把已关闭分支的数据带上。
怎么研究
填完条件块，关掉条件，提交，检查载荷。再打开条件，看值还在不在。比较「隐藏仍提交」「隐藏即剔除但本地保留」「隐藏即删除」。
自变量：隐藏后值是否出现在请求里、再打开是否恢复、是否有一句说明。 因变量：人预测「会不会开出发票」是否命中、再打开后重填次数、客服关于「我关了怎么还在」的工单原型。
不要只看界面。必须打开请求体。实验室里若下一屏还有回顾，人可能在回顾里发现残留；没有回顾的表更接近真实漏检。
边界
草稿自动保存可以在本地保留隐藏分支的值，那是草稿不是提交；提交接口仍须剔除。法规要求即使取消也要记录「曾经填写过」时，应作为审计日志而不是业务字段再去开票。浏览器会把隐藏字段纳入自动填充或随表提交，产品规则必须在序列化时强制执行，不能指望 CSS 隐藏等于不提交。只读汇总里若仍展示已关闭分支的值，等于告诉人它还会生效。
怎么落地
- 规定并实现：当前为假的条件，其字段不进入提交载荷；值可留在客户端以便再打开。
- 在取消条件的那一拍用一句人话说明「抬头不会用于这次订单，再打开仍在」。
- 提交前的回顾只列出当前为真的分支；已关闭分支不得出现在将要生效的清单里。
- 验证：填抬头后取消发票，抓提交请求，载荷里没有抬头。再打开，「抬头」还在输入框里。做隐藏仍提交的对照，确认回顾若展示了抬头，人会以为会开票。