规范H5表单需统一认知、分层控制、前后端对齐、体验一致：一、字段与交互前置对齐；二、校验分浏览器层、前端脚本层、后端服务层三层各司其职；三、上传覆盖选择、预处理、执行、结果四阶段闭环；四、靠Checklist文档、封装组件、CI检查工具落地。
规范团队在 H5 场景下的表单交互、校验与上传闭环设计，核心在于统一认知、分层控制、前后端对齐、体验一致。不是堆功能，而是建规则；不是靠个人经验，而是靠可复用的流程和约束。
一、字段与交互逻辑必须前置对齐
开发前不写一行 input，先完成三件事：
- 明确账号标识方式：统一用“手机号或邮箱”单字段（loginName），后端按正则识别类型，前端只校验格式+唯一性，避免用户名重名、特殊字符等管理黑洞
- 确认必填/选填、实时校验节点（blur 还是 input）、错误反馈时机（失焦即提示 or 提交时聚合）
- 定义上传类字段的业务语义：是头像？证件照？还是多文件附件？不同用途对应不同的 size 限制、type 白名单、压缩策略和失败重试机制
二、校验分三层，各司其职
把校验拆成“浏览器层 → 前端脚本层 → 后端服务层”，每层不越界、不重复、不遗漏：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 浏览器原生层：用 required、type="email"、pattern、minlength 等属性兜住基础格式，触发 :valid/:invalid 伪类做视觉反馈，零 JS 即可拦截明显错误
- 前端脚本层：处理跨字段逻辑（如密码与确认密码一致性）、动态规则（如“身份证号校验码”“手机号归属地拦截”）、异步唯一性检查（邮箱/手机是否已注册），通过 Constraint Validation API 的 setCustomValidity + checkValidity 控制提示
- 后端服务层：做最终裁定——防刷、幂等、脱敏、权限校验。前端所有校验都可被绕过，所以后端必须独立验证，且返回结构化错误码（如 1002 表示手机号已被占用），前端据此映射到具体字段高亮
三、上传流程要闭环，不能只管“发出去”
文件上传不是加个 input type="file" 就完事，需覆盖完整生命周期：
立即学习“前端免费学习笔记（深入）”；
- 选择阶段：设置 accept 属性（如 accept="image/*,.pdf"）、multiple 属性控制单/多选、用 inputmode="none" 防误唤键盘
- 预处理阶段：前端做轻量压缩（图片）、格式转换（HEIC→JPEG）、分片准备（大文件）、生成签名凭证（如临时 token）
- 上传执行阶段：用 XMLHttpRequest 或 Fetch + FormData 提交，监听 progress 事件更新进度条，失败时自动重试（最多 2 次）并记录错误原因
- 结果处理阶段：成功后拿到后端返回的 file_id 或 CDN URL，存入隐藏字段供后续提交；失败则还原按钮状态，提示具体原因（如“文件大于5MB，请压缩后重试”）
四、团队落地靠三样东西
让规范真正跑起来，靠文档、组件、检查工具：
- 维护一份《H5 表单开发 Checklist》，含字段命名规范（name 必须语义化，如 loginName、idCardFront）、错误文案模板（禁止写“提交失败”，统一为“手机号格式不正确，请检查后重试”）
- 封装基础表单控件组件（如 FormInput、FormUploader），内置默认校验逻辑、loading 状态、无障碍支持（label 关联、role 属性），新项目直接调用不造轮子
- 在 CI 流程中加入 HTML 格式扫描（如 html-validate），强制要求所有 input 必须有 name 和 label，禁用无语义的 div 模拟表单控件
