React 表单提交的 pending 态要先于按钮禁用

很多表单页面对提交态的处理都很机械：点一下按钮，按钮变灰，结束。可真正的体验问题往往不在“有没有禁用”，而在用户是否明确知道请求已经开始、当前能不能继续操作、如果慢了应该看哪里。

我越来越觉得，pending 态首先是信息传达，其次才是交互限制。只禁用按钮而没有任何可见反馈，用户很容易怀疑自己没点上，于是又去刷新页面或者重复触发别的动作。反过来，如果有明确的提交状态、局部 loading 和结果提示，重复点击往往自然就少很多。

在 React 里做这件事，关键不是多一个布尔值，而是把“提交中”当成页面状态的一部分来看。哪些区域需要继续可操作，哪些区域应该暂时锁住，失败后要恢复到哪个状态，这些都要事先想清楚。

我一般会尽量把 pending 态做成局部且明确的，而不是整个页面一刀切变灰。这样既能告诉用户系统正在处理，也不会让页面突然失去所有反馈。

交互体验常常就差在这种细节里。按钮禁用只是动作，pending 态才是完整沟通。

前端里的很多“体验问题”本质上都是边界问题

围绕「React 表单提交的 pending 态要先于按钮禁用」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。