一个表单提交量翻倍：公共服务别把 JavaScript 做成门槛

一家公用事业公司的线上申请表，重做后完成提交的人数一夜之间翻倍。

反常点在于，它没有换更炫的前端框架，也没有加更复杂的状态管理。团队撤掉上一版失败的 React 单页应用，改成 HTML-first、渐进增强的多页表单。每一步提交到后端。数据和上传都保存。没有 JavaScript，也能走完。

这件事适合给前端工程师、技术负责人，以及公共服务、政务、基础设施数字团队当镜子。很多前端复杂度看起来很先进，实际效果却可能只是提前筛掉最弱的用户。

上线 3 天被撤，问题不在框架名字

这家公司是受监管的垄断型公用事业公司。客户满意度如果低于大约 96%，可能面临数百万英镑罚款。

所以，这个申请表不是普通的“体验优化”。它直接连着投诉、监管和成本。

旧流程也不轻松。用户要么用一个老 ASP 表单，要么走人工流程。人工流程更贵，也更慢。公司曾经做过两次昂贵尝试，最近一次是外包团队做的 React 应用，上线 3 天就因为投诉被撤。

投诉背后的技术问题并不玄：页面加载转圈，全局 JavaScript 状态容易出事，可访问性不好。更麻烦的是，图片和表单数据被塞进 localStorage，而 localStorage 通常只有 5MB 左右限制。对需要上传图片的大表单来说，这个设计太脆。

这里要说清楚：这不是 React 原罪。

复杂客户端应用当然有位置。实时协作、数据密集型后台、复杂交互工具，都可能需要它。但一个公共服务申请表，本质是任务型流程。用户要完成提交，不是来欣赏前端架构。

场景错了，技术越“现代”，越容易把代价甩给用户。

HTML-first 的重点，是失败时还能用

新版本用了 Astro。核心做法很朴素：每个步骤一页，用户点下一步，表单提交到后端。后端校验，通过后重定向到下一步。数据和上传在每一步保存。

JavaScript 没有被赶走。它以 Web Components 和现代 CSS/JS 的方式做增强。

比如表单校验。增强脚本能把错误提示放进对应的可访问区域，输入合法后清除提示，失焦和提交时再检查。脚本失败，还有浏览器原生校验。浏览器能力不够，还有后端兜底。

这套方案真正值钱的地方，是它认真设计了失败路径。

很多前端项目只设计理想路径：新浏览器，好网络，强手机，脚本顺利执行，用户一次填完。公共服务刚好不能这么想。它要面对旧设备、弱网、辅助技术、中途离开、隔很久再回来的人。

原文里提到，有用户确实在开始一个月后才完成表单。后端会话和每步保存，在这种场景下不是保守，是必要。

GOV.UK 那个老故事也能说明问题：有人用 PlayStation Portable 的破浏览器查住房福利页面。PSP 浏览器慢，内存小，标签少，但简单 HTML 页面能打开。

不完全一样，但重复的是同一种权力结构：公共服务没有资格只服务设备最好、网络最好、耐心最多的人。

“民惟邦本”放到数字服务里，就是入口不能变成技术筛选器。被挡在门外的人，往往正是最需要服务的人。

对团队的提醒：别只看埋点里的用户

新版本上线后，完成表单的人数翻倍。注意口径：不是公司总用户翻倍，不是营收翻倍，也不是注册用户翻倍。只是完成这个申请表的人变多了。

但这个变化已经够刺眼。

更刺眼的是，分析团队一开始不知道这些用户从哪里来。原因可能很简单：依赖 JavaScript 的分析工具，看不到那些被 JavaScript 故障挡在门外的人。你以为漏斗没有大问题，只是因为失败者连埋点都没触发。

这对两类人影响最大。

前端工程师和技术负责人，应该把“大表单是否必须 SPA”重新拉出来评审。不是所有流程都要迁到重客户端。采购框架、定脚手架、做技术选型时，至少要加一条硬约束：无 JS、弱网、旧设备、辅助技术下，核心任务能不能完成。

公共服务、政务和基础设施数字团队，则要把验收标准从“页面能跑”改成“最差条件下能交付”。WCAG AA、服务端校验、每步保存、上传恢复、非 JS 路径，都不该是上线前的补丁。它们应该进入需求、招标、验收和投诉复盘。

现实约束也别回避。HTML-first 不是省事按钮。

团队要处理后端状态、重定向、校验一致性、文件上传恢复、错误提示可访问性。开发者可能会觉得工作更多。某些复杂交互也确实更适合客户端应用。

但公共服务的工程目标，不是让开发最省事，而是让用户最不容易失败。

接下来真正该看的，不是又有多少团队喊“回归 HTML”。那太浅。

更该看三件事：完成率是否稳定，投诉是否下降，弱设备和辅助技术用户是否真的能走完流程。如果这些指标没有改善，HTML-first 也只是换了一套话术。

这件事的分水岭不在 HTML 赢了 React。它至少表明一件事：在公共服务入口，可靠抵达比前端体面更重要。