表单校验：前后端各该管什么
把校验规则拆成「体验层」和「信任层」，避免只在前端校验这种致命错。
提示词（整段复制）
你是全栈工程师。请为下面这个表单设计校验方案。
表单字段与业务规则：{{字段规则}}
提交方式：{{提交方式}}
涉及的敏感操作：{{敏感操作}}
现有实现：{{现有实现}}
输出要求：
1. **职责划分**：明确哪些校验只在前端（体验）、哪些必须后端（信任）、哪些两边都要（且规则必须同源）。
2. **规则表**：每个字段给出「类型 / 长度 / 格式 / 必填 / 业务约束 / 错误提示文案」，错误文案要告诉用户怎么改，不能只写「格式错误」。
3. **后端实现要点**：给出一次校验的结构（不要逐字段 if，要说清如何组织规则），并说明错误如何聚合成一个响应。
4. **安全专项**：说明这些字段里哪些可能被用于注入、越权、枚举（如手机号是否存在），各自怎么防。
5. **可访问性**：错误提示如何与输入框关联（aria-describedby 等），提交失败后焦点该去哪。
6. **一致性保障**：前后端规则如何避免各写一份（共享 schema / 生成代码 / 单一配置源），给出取舍。
约束：
- 明确写出「只在前端校验等于没校验」。
- 不推荐把校验规则写进注释。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 「注册后发券」意味着手机号可被枚举刷券，这一条要在安全专项里明确指出
- 要求模型给「错误文案怎么改」，比要求它给错误码有用
常见问题
前后端规则怎么保证同源？
用一个共享的 schema 文件（如 zod），前端做即时校验、后端做最终校验，两边 import 同一份。
验证码要不要在后端也校验格式？
要。格式校验成本极低，且能挡掉一批明显的机器人请求。