React 19 的价值不只是新 API
很多团队升级 React 时只看语法变化，但 React 19 更值得关注的是交互模型的收敛。过去做一个表单，通常要自己维护提交中、成功、失败、错误字段、乐观展示和回滚逻辑。项目小的时候还能靠经验压住，页面多了以后，同一类交互会散落在不同组件里。
React 19 让 Action、表单状态和乐观更新更容易组合。它不是要求所有业务都改成一种写法，而是给高频交互提供了更清晰的边界：用户触发一次提交，界面进入待处理状态，服务端或异步逻辑返回结果，组件根据结果展示成功或错误。
先从普通表单开始改
升级时不要先动最复杂的后台页面。更稳的做法是选择一个字段较少、提交逻辑清晰的表单，例如登录、订阅、反馈或资料编辑。先把提交状态、错误信息和按钮禁用逻辑统一起来。
一个表单至少要回答四个问题：提交中按钮是否禁用；失败后错误显示在哪里；成功后是否清空输入；重复点击会不会造成重复请求。把这四点做稳，比追求 API 新鲜感更重要。
乐观更新适合哪些场景
乐观更新适合低风险、可回滚的动作，例如点赞、收藏、切换开关、标记已读。它不适合金额、库存、权限这类强一致业务。前者可以先让界面响应，再在失败时回退；后者应该等服务端确认后再改变关键状态。
做乐观更新时，要明确失败路径。很多页面只写了“先显示成功”，却没有处理失败后的提示和回滚，结果网络抖动时用户看到的状态和真实状态不一致。
错误回显要靠结构化结果
不要只从接口返回一段字符串。更实用的结果结构包括：全局错误、字段错误、业务状态和可重试标记。这样前端能把邮箱错误显示在邮箱输入框旁边，把权限错误显示在表单顶部，把临时网络错误做成可重试提示。
如果项目使用 TypeScript，建议把表单输入、服务端返回和字段错误都定义成类型。表单越多，类型带来的收益越明显。
渐进迁移比一次重写更稳
React 19 的新能力适合逐步引入。先选 1 到 2 个页面建立范式，再抽出通用的提交按钮、错误展示和状态提示。不要在升级当天把所有表单都重写，否则很难区分框架升级问题和业务改动问题。
总结
React 19 的落地点不是“把代码写得更新”，而是把表单交互变得更一致。提交状态、错误回显、乐观更新和回滚路径都清楚以后，用户体验会更稳定，后续维护也更轻。
表单状态要覆盖完整路径
React 表单交互不只是提交成功。一个可靠表单至少要覆盖填写中、提交中、成功、字段错误、系统错误和重复提交六种状态。乐观更新可以提升体验，但必须能在服务端失败时回滚，并给用户明确反馈。
错误信息要贴近字段，而不是统一显示“提交失败”。比如邮箱格式错误、标题为空、权限不足、网络超时，对用户的下一步动作完全不同。把错误分清楚，表单体验才不会显得粗糙。
渐进接入
如果项目已有成熟表单逻辑，不建议一次性全部改成新写法。可以先选低风险表单试点，确认校验、异常处理、埋点和可访问性都稳定，再推广到核心流程。新 API 的价值应体现在更清楚的状态管理，而不是为了升级而升级。