面向 Web 与移动端的共享验证规则

为什么验证会漂移

验证不同步的原因很简单：网页和移动端表单常常由不同的人在不同时间构建。一个团队在网站上快速添加了一个规则，另一个团队把旧版本复制到应用里，然后各自继续前进。

起初差异看起来很小，但后来某次更改会把它暴露出来。密码从 8 位改成了 12 位，电话号码现在需要带国家码，某个字段从可选变成了必填。如果只有一个客户端被更新，同一个用户在不同设备上可能会得到截然不同的结果：一个设备输入有效，另一个设备却被阻止。

这就是共享验证规则重要的原因。没有它们，每个客户端就会成为自己的事实来源。

漂移在实践中是什么样子

注册表单很快就会暴露问题。在网站上，“公司名称”可能是可选的，而移动应用里因为界面较早构建仍把它设为必填。用户在两处填写相同信息，却得到不同结果，从而认为产品有问题。

这通常发生在规则被复制到多个地方并手动更新时。发布节奏会让问题更严重：网页更改今天可以上线，而移动端修复可能要等下一次应用更新。

这种不匹配经常出现在基础项：必填字段、格式校验，以及像年龄、订单大小或折扣等业务限制。支持团队要不断解释为什么一个界面接受某个值而另一个拒绝它。随着时间推移，用户开始不信任错误提示，团队也对发布失去信心。

规则本身很少是根本问题，真正的问题是同一条规则存在于太多地方。

哪些内容应在各端保持一致

如果表单在网页和移动端表现不一致，用户会立刻注意到。最稳妥的方法是决定哪些规则属于通用规则，并在每个客户端保持一致。

从基础开始。除非有明确的产品理由，否则一个字段不应在某些设备上是必填而在另一些设备上是可选。格式校验也应一致。电子邮件、电话、日期等字段在各端应遵循相同模式。即便是一个小差异，比如一个客户端接受电话号码中的空格而另一个拒绝，也会造成困惑。

长度限制和允许字符也需要同样的处理。如果用户名在移动端允许 30 个字符但网页只允许 20 个，用户可能保存了其他客户端无法编辑的数据。名字、备注、代码和 ID 也会出现同样的问题。

业务规则同样重要。如果用户必须超过某个年龄、属于某个支持的地区或拥有特定账户状态，这些检查应在每个界面表现一致。

措辞不必在每处完全相同，尤其在较小的移动屏幕上，但含义应该保持一致。如果一个应用提示“输入有效日期”，另一个提示“日期不支持”，用户可能会误以为规则不同，即便实际规则是一样的。

一个简单的测试很有效：如果用户在网页和移动端输入相同数据，应该得到相同的结果和相同的基本修复指引。

让后端做最终决定

前端快速反馈很有用，但它永远不应成为最终裁决。后端应始终决定数据是否有效。

网页和移动客户端仍应及早捕捉明显问题，标出缺少的必填字段、邮箱格式错误、不可能的日期以及明显超出范围的值。这能节省时间并在提交前帮助用户修正错误。

但后端能看到完整的全局情况。后端可以校验与实时数据、账户状态、权限、库存或刚被其他用户修改的记录相关的业务规则。一个促销码在手机上看起来有效，但服务器可能知道它已过期或已被使用。

为了让共享验证规则发挥作用，后端应以各客户端都能理解的格式返回错误。避免模糊的回应如“输入无效”。使用稳定的错误代码或规则名，并附上清晰的提示。

几个常见示例：

• required 表示缺少字段
• invalid_format 表示邮箱或电话格式错误
• out_of_range 表示值超出上下限
• not_allowed 表示基于权限或状态的校验不通过
• already_exists 表示邮箱、用户名或 ID 重复

这些名称应在各客户端保持稳定。像在一个应用中使用 email_invalid 而另一个应用中使用 invalid_email 会制造不必要的错误。

一个好的后端测试很简单：如果有人绕过 UI 直接向 API 发送请求，相同的错误数据仍应因相同的原因被拒绝。

创建一处事实来源

最干净的解决是建立一本统一规则手册。如果每个团队都在各自的网页表单和移动界面里写验证，规则就会漂移。当规则被集中定义一次并由所有客户端遵循时，效果更好。

这个共享来源可以是 schema、后端模型或中央产品配置。格式本身不如形成习惯重要。在任何人开始构建界面前，先定义好字段。把字段名、数据类型、必填状态、格式和业务限制放在一起。

按业务对象分组规则也有帮助，而不是按设备分组。用户、订单、发票或注册请求等对象，应有一套适用于任何客户端的规则。为每个对象记录字段、必填校验、格式规则、业务约束和后端返回的错误代码。

这样更改会更安全。如果业务决定电话号码变为可选，只需更新一个共享定义，而不是在 iPhone、Android、网页与管理界面中四处查找。

版本管理也很重要。规则更改可能会破坏仍安装在用户手机上的旧应用。与其完全替换一条规则不留下痕迹，不如对更改进行版本化，让后端在短期内支持旧客户端，待新版本逐步推广后再完全切换。

一个简短的审查步骤比大多数团队预期的更有帮助。规则更改时，产品经理可以确认业务目标，支持团队可以指出真实的客户问题，例如某个姓名字段拒绝常见标点，或地址规则过于严格。

如果你使用 AppMaster，这种方法很自然，因为后端逻辑、Web 应用和原生移动应用都可以在一个无代码平台中管理。核心思想一样：规则只写一次，集中管理，让每个客户端都遵循它们。

一个简单的推广计划

你不需要大规模重写来修复验证漂移。先从一个表单开始，把规则明确写出来。

首先，列出每个字段并用通俗语言描述。注明接受何种值、是否必填、必须遵循何种格式，以及与之相关的任何业务条件。仅写“邮箱为必填”往往不够：如果一个客户端接受坏格式而另一个阻止，就需要更明确的描述。

然后先实现后端校验。之后在网页和移动端镜像相同的校验，让用户在提交前得到快速的反馈。

一个简单的流程如下：

1. 写一份逐字段的规则清单。
2. 先将规则放入后端验证。
3. 在网页端添加匹配的前端校验。
4. 在移动端添加相同的校验。
5. 在各端用相同示例输入进行测试。

测试是隐藏差异最常出现的地方。为每个字段准备一小组有效和无效示例：空值、格式错误、刚低于限制的值、正好达到限制的值以及刚超过限制的值。如果网页和移动端在每种情况下都与后端一致，那么你就有了一个值得信赖的系统。

示例：客户注册表单

注册表单可以很清楚地展示问题。假设表单有三个字段：邮箱、密码和出生日期。

在网页和移动端，表单在用户提交前应有相同的反应。如果邮箱为空，两个端都应阻止提交并显示相同的信息。如果格式错误，两个端也应提示。

密码规则必须完全一致。如果最低要求是 8 个字符，任一端都不能是 6 或 10。此类小差异会让频繁切换设备的用户很快困惑。

出生日期是业务逻辑常常出错的地方。如果产品只允许 18 岁以上注册，两个客户端应使用相同的截止规则和相同的“今天”定义，否则用户可能在网站上通过验证却在应用中被拒绝。

后端仍需在请求到达时再次全部校验。在那里你会发现重复账户、被编辑的请求，以及旧版本应用仍在发送过时数据的情况。

提示文案也应保持清晰与一致。好的示例包括“输入你的邮箱地址”、“输入有效的邮箱地址”、“密码必须至少 8 个字符”和“该邮箱已被注册”。当用户在各处看到相同的语言时，支持更容易，信任也更高。

导致漂移的常见错误

大多数验证问题不是来自某条明显错误的规则，而是来自随着时间积累的小不匹配。

一个常见错误是在某个客户端隐藏了规则。iPhone 应用可能把电话号码设为必填，而网页把它设为可选。另一个常见错误是对同一字段使用不同的模式：网页允许邮政编码中有空格，而 Android 应用禁止空格；或者一个客户端接受电话号码中的加号，而另一个会把它剥离掉。

更严重的问题是过分信任 UI。客户端校验可以加快用户修正错误的速度，但单靠它从来不够。旧应用、浏览器差异和直接的 API 请求都可能在后端不强制一致的情况下发送坏数据。

模糊的错误消息会使情况更糟。“输入无效”并不能告诉用户如何修复。清晰的信息才行。旧版应用也是容易被忽视的点：如果新版本增加了必填字段，旧客户端可能在数周内继续发送不完整的数据。

当验证持续漂移时，常见原因通常很简单：隐藏的必填字段、不同的格式规则、薄弱的后端校验、模糊的错误消息以及缺乏对旧版本的计划。

发布前的检查以捕捉问题

在发布前，以相同方式在每个客户端测试表单。用一组小的示例输入，在网页、移动端和后端 API 上跑一遍。如果某个客户端接受了另一个客户端拒绝的值，那么你的共享验证规则还没有真正共享。

先从基础用例开始。留空必填字段，输入格式错误的值，并尝试边界情况，比如正好达到限制的日期、只有一个字符的名字或填到最大长度的字段。

你的发布前检查应回答几个直接问题：网页是否拒绝与移动端相同的错误输入，后端是否在客户端漏检时仍能拒绝无效数据，以及用户在各处看到的错误信息是否传达相同含义？

后端的检查最重要。如果有人绕过 UI、使用旧版应用或直接向 API 发送数据，结果仍应是安全且可预测的。

并且值得并排审查错误提示文本。如果网页提示“输入有效邮箱”，而移动端提示“未知错误”，即便规则相同，人们也会认为应用行为不同。

发布后，关注几天内的支持工单和用户评论。像“在手机上可以，但桌面上不行”这样的抱怨通常比任何仪表盘更快地指向验证缺口。

更清晰的下一步

如果你的表单在网页和移动端不断以不同方式出问题，不要试图一次修复所有表单。先从造成最多问题的表单开始，通常是注册、结账或资料编辑。

先把严格的规则移入后端逻辑，包括必填字段、格式校验、重复性检查和业务限制（如年龄、账户类型或地区）。然后让网页和移动端镜像相同的校验以提高速度和清晰度。

把规则写清楚。例如不要写“校验客户状态”，而写“企业客户必须填写税号”或“当启用短信提醒时电话号码为必填”。清晰的措辞让设计师、开发者、测试人员和支持团队更容易在发布前发现漏洞。

如果想减少重复工作，AppMaster 能提供帮助，因为它允许团队在一个系统中构建后端、网页和原生移动应用。这让保持业务逻辑一致更容易，同时仍能在各客户端提供快速反馈。

目标不是一夜之间把所有表单做完美，而是减少意外、减少支持工单，并让网页与移动端在产品增长过程中保持一致的验证行为。