HTML input注释与类型选择：提升表单可维护性的实践指南

1. 为什么给 input 加注释这件事值得单独聊

上周帮朋友看一段表单代码，一个页面里躺了四十多个input，全是<input type="text" class="form-control">，没有name、没有注释、没有autocomplete。我当时问了一句"手机号那栏在哪儿"，对方翻了半天说"应该是第三个吧"。这就是问题所在：input是 HTML 里最"没存在感"的标签，写起来两秒钟一个，但它承载的信息量其实极大——数据类型、输入约束、业务语义、移动端键盘、浏览器自动填充、校验规则，这些全都挤在那一个自闭合标签里。一旦不写注释，三个月后连作者自己都要靠placeholder猜。

这篇东西聊的就是HTML 常见 input 加注释这件事。核心不是教你怎么写<input>，而是讲清楚：为什么要在这些输入框旁边留注释、注释里到底该写什么、不同type在什么场景下用、加注释的时候怎么顺手把那些容易踩的属性一起配好。适合刚写表单的前端新人，也适合接手老项目被一堆无注释输入框折磨过的同行——尤其是那些需要长期维护的后台管理系统、报名表单、支付信息页。

行业里有个很普遍的误区：注释是"代码不清晰才需要的东西"，好的代码应该自解释。这话放业务逻辑层成立，但放到表单上不太成立。<input type="text" maxlength="11">这个标签本身没法告诉你这十一位到底是什么——手机号？工号？身份证后十一位？订单号？只有注释能说清楚。表单是所有前端代码里最贴近业务语义的一层，也是最容易因为人员变动而失传的一层。我在实际项目里踩过的最恶心的一个坑，就是某个输入框没注释，新人按照名字以为存的是用户昵称，结果实际上是第三方渠道传过来的标识，两边写进去的数据格式完全不同，线上对账错了小半天才定位到。

所以这篇的定位很明确：把常见的input类型挨个过一遍，每个配上能直接抄的注释写法，再把注释里应该顺带记录的属性、约束、兼容性一起讲透。看完你应该能做到两件事——给现有表单补注释的时候知道按什么维度补，新写表单的时候知道在写下<input>的那一秒就把信息固化下来。

1.1 一个无注释的表单到底埋了什么成本

先别急着谈规范，我们拆解一下无注释表单会产生的具体成本，这样才能判断注释值不值得写。

第一类是语义成本。type="text"是万能的，但它也是无信息的。一个表单里同时存在手机号、验证码、邀请码、卡号，四个全用type="text"，光看代码完全分不出来。这时候如果后端接口字段叫field1、field2，前端再没有注释，你几乎没办法做加法——想给手机号加个maxlength="11"、给验证码加个inputmode="numeric"，都得先去线上点一遍才知道哪个框是哪个。

第二类是回归成本。输入框的属性改动是最容易引起"看起来没变但实际变了"的一类修改。比如你把type="text"改成type="number"，PC 端看不出区别，但用户粘贴一个带空格的数字进去，value直接变空字符串，提交上来就是null。这类问题如果没有注释记录"这里为什么特意用 text 而不是 number"，后面接手的人百分之百会"优化"掉它，然后线上炸掉。

第三类是协作成本。表单通常不是一个人写完的，前端写结构，后端定校验，产品定文案，测试定边界。注释是这几方唯一的代码内共同语言。我在一个项目里推过一个很土但很有效的做法：每个input上方必须有一行注释，写明字段用途 + 来源 + 校验规则负责人。推行两周之后，接口字段和页面对不上的问题少了一大半。

提示：注释不是写给现在的自己看的，是写给三个月后半夜被叫起来改 bug 的自己，以及那个完全不了解业务背景的接手人。判断标准很简单——把这段代码交给一个没参与过需求评审的人，他能不能只靠注释安全地改动这个输入框。

1.2 注释到底该写哪几层内容

很多人写注释就写一句"手机号"，聊胜于无，但信息量还是不够。我的经验是按照固定的几个层次来写，形成肌肉记忆之后每行注释花不了十秒钟。

第一层是业务语义，也就是这个字段在业务上是什么。"手机号"、"收货人姓名"、"发票抬头"这种。这一层必须写，而且要写业务叫法，不要写代码叫法。

第二层是数据约束，包括长度、格式、取值范围、是否必填。比如"11 位数字，1 开头，必填"。这一层要和后端校验对齐，前端约束只是体验优化，不能当安全边界。

第三层是技术属性选择的理由，也就是"为什么用这个 type"。比如"用 type=tel 而非 number，因为需要保留 +86 前缀"。这一层是最容易被忽略、也是最容易被后人改坏的。

第四层是特殊行为，比如"失焦时自动查询是否已注册"、"中文输入法组合期间不触发校验"、"和某个字段联动清空"。这一层是注释里最值钱的部分，因为代码上完全看不出来。

第五层是兼容或历史包袱，比如"保留 type=text 是为了兼容某个内嵌环境的旧内核，别改成 date"。这一层写出来有点自曝家丑，但它能救人的命。

1.3 注释、组件封装、文档，三种方案怎么选

有人会说，与其写注释，不如把输入框封装成组件，用 props 描述语义。这个思路对，但成本和适用场景不一样，我做了个对比：

我的实际做法是注释 + 轻封装：把重复度最高的几个类型（手机号、验证码、金额、日期）封成组件，组件内部把常用属性和注释写死；其余的散装input老老实实写行内注释。类型系统能管住数据形状，管不住业务语义，所以注释这一层省不掉。

2. 常见 input 类型逐个拆解与注释写法

这一节是主体，我把 HTML 里常用和不常用的input类型按功能分组过一遍，每个给出一个可以直接抄的注释模板。注意我这里说的"注释"是 HTML 注释<!-- -->，写在标签上方或行尾，行尾注释适合短说明，上方注释适合多行说明。

2.1 文本输入组：text、search、password、email、tel、url

这一组是最常用的，也是最容易被写成清一色type="text"的重灾区。

type="text"是默认值，写上它主要是为了显式表达"这里确实不需要特殊键盘和校验"。注释要写清楚它为什么是 text。比如用户名这种既要允许中文又要允许字母的，用 text 完全合理，但注释得写明允许的字符集和长度。

<!-- 用户名：4-20 位，允许中英文、数字、下划线；不允许纯数字（后端规则） 用 text 而非其他类型，因为要兼容中文昵称 --> <input type="text" name="username" id="username" minlength="4" maxlength="20" required autocomplete="username" spellcheck="false">

type="search"在一些浏览器里会渲染出清除按钮，回车键会显示"搜索"。它适合搜索框，但注意search在部分环境下和text表现一致，别指望它带来太多差异。注释里要写明"清空后是否触发查询"这种交互逻辑。

type="password"的关键在autocomplete。注册场景用new-password，登录场景用current-password，这两个值直接决定浏览器会不会弹出保存密码的提示。改密码场景还有个坑：如果三个密码框（原密码、新密码、确认密码）全部用current-password，浏览器的填充行为会很混乱。我通常这样写：

<!-- 新密码：8-32 位，必须含字母和数字；前端不校验复杂度只校验长度， 复杂度校验交给后端，避免前端规则和后端不一致导致注册失败 autocomplete=new-password 防止浏览器把旧密码自动填进来 --> <input type="password" name="newPassword" id="newPassword" minlength="8" maxlength="32" required autocomplete="new-password">

type="email"自带一个非常弱的格式校验（有@就能过），不要把它当真实校验用。它的真实价值在移动端会唤起带@和.的键盘。注释要写明"允许的邮箱域名范围"这类业务规则，因为type="email"本身管不了。

type="tel"最容易和type="number"混淆。记住一个原则：电话号码不是数字，它可能有+、-、空格、括号，甚至分机号。所以电话一定要用tel，配合pattern做格式约束，再配合inputmode="tel"保证键盘。这里有个细节，pattern在tel上是生效的（因为tel的格式由作者定义），但在number、date上会被忽略。

<!-- 联系手机：中国大陆 11 位，1 开头；允许用户输入带空格的格式， 提交前在 JS 里统一去空格，不要在这里用 pattern 强制无空格， 否则用户从通讯录粘贴会直接校验失败 --> <input type="tel" name="mobile" id="mobile" maxlength="13" inputmode="tel" autocomplete="tel" placeholder="请输入手机号">

type="url"会要求输入带协议头的地址，用户体验一般，除非字段确实要求完整 URL，否则我倾向于用type="text"加注释说明"允许省略 https://，提交时补全"。这一点一定要在注释里写清楚，因为它和type="url"的默认行为是冲突的。

2.2 数值组：number 与 range 的真实差异

type="number"被滥用的程度仅次于type="text"。它有三个特性必须知道：一是允许输入e、E、+、-、.（科学计数法和符号），二是当输入不合法时value返回空字符串而不是原始文本，三是step和min配合会产生stepMismatch校验错误。

第三条是最坑的。假设你写了min="0" step="0.01"，用户输入1.005，浏览器会认为它不匹配步长而拒绝提交，但用户完全不知道发生了什么。我的处理方式是在注释里明确写出"允许几位小数、超出的如何处理"：

<!-- 商品单价：单位元，保留两位小数，范围 0.01 - 99999.99 用 number 而非 text，为了移动端唤起数字键盘并拿到浏览器的范围校验 注意：number 允许输入 e/E，若业务不允许科学计数法，需在 input 事件里过滤 --> <input type="number" name="price" id="price" min="0.01" max="99999.99" step="0.01" required inputmode="decimal">

金额场景我个人更偏向type="text"+inputmode="decimal"+ 手动格式化，因为number在小数位补齐、千分位显示、粘贴带逗号的金额这几种情况下表现都不好。如果团队决定用number，注释里一定要写清"为什么选它"和"已知缺陷是什么"。

type="range"是滑块，它提交的值永远是字符串，取到的永远是范围内某个值，没有"未选择"这个状态。这一点经常被忽略——如果这个字段是选填的，用户不拖动滑块，你还是会提交一个值。所以选填的场景要么加一个"是否指定"的开关，要么初始化时把值设为空并在 JS 里判空。

<!-- 满意度评分：0-10，选填 坑：range 没有空值状态，不拖动也会提交默认值 所以这里额外配了一个 hidden 的 selected 标记位，见下方 JS 注释 --> <input type="range" name="score" id="score" min="0" max="10" step="1" value="5">

2.3 日期时间组：date、time、datetime-local、month、week

这一组的问题是浏览器 UI 差异巨大，而且老环境里会直接降级成普通文本框。降级之后用户能随便输入，格式完全不受控，后端拿到的可能是"2024年3月"，也可能是"03/2024"。

使用它们的正确姿势是：前端用 date 类控件提升体验，后端必须重新解析校验，同时前端在提交前做一次格式归一化。注释里要把这个分工写清楚，避免后人以为原生控件已经保证了格式。

<!-- 生日：格式 YYYY-MM-DD 用 date 是为了让用户少打字，但部分内嵌环境不支持会降级为 text 所以提交前必须走一次 formatDate 归一化，不要直接信任 value 的格式 --> <input type="date" name="birthday" id="birthday" min="1900-01-01" max="2024-12-31">

datetime-local的value格式是YYYY-MM-DDTHH:mm，中间那个T经常被新手忽略，手动赋值时漏掉T会直接导致控件显示为空。month的value是YYYY-MM，week是YYYY-Www（注意是 ISO 周，一年可能有 53 周）。这些格式细节非常值得写进注释，因为它们是"看代码看不出来、试一次才知道"的东西。

还有一个高频坑：min和max在日期类控件上只做 UI 限制，用户手工输入（降级情况下）或者用脚本赋值都能绕过，所以服务端校验不能省。

2.4 选择组：checkbox 与 radio 的语义边界

checkbox和radio的注释重点不在类型本身，而在分组关系和提交格式。

radio靠相同的name互斥，这一点必须有注释说明，因为如果两个 radio 的name不一样，它们就会变成两组，用户能同时选中，而这个 bug 在 UI 上看起来只是"选项都能点"。checkbox提交时同名多值，后端是按数组收还是按逗号拼接收，也要在注释里写清楚。

<!-- 发票类型：单选，必选一项 注意：三项必须用相同 name（invoiceType）才互斥， 新增选项时千万别改 name，否则会变成独立分组 --> <label><input type="radio" name="invoiceType" value="personal" checked> 个人</label> <label><input type="radio" name="invoiceType" value="company"> 单位</label>

复选框有一个反直觉的点：不勾选时浏览器根本不会提交这个字段，后端收到的是"字段缺失"而不是false。所以选填的布尔开关要么用hidden配一个默认值，要么在后端把缺失当成false处理。这个约定必须写进注释，否则前后端会为了"为什么没勾选反而报参数缺失"扯半天。

2.5 文件与其他类型：file、color、hidden、submit 系列

type="file"的注释重点在accept只是提示不是强制、multiple影响后端接收方式、以及文件大小限制前端拿不到。accept用户可以手动切成"所有文件"然后选一个.exe，所以真正的类型校验必须在服务端做。

<!-- 资质附件：仅图片，单文件，大小限制 5MB（前端校验 + 后端二次校验） accept 只是给文件选择器一个过滤提示，不是安全边界，用户可绕过 --> <input type="file" name="certFile" id="certFile" accept="image/png,image/jpeg" required>

type="hidden"必须写注释说明这个值从哪来、能不能被篡改。它是明文的，用户在开发者工具里改一下就能改掉，所以任何涉及权限、金额的隐藏字段都不能只靠前端传值。这句提醒我觉得每个hidden旁边都该有。

submit、reset、button这三个在注释里主要写"提交到哪个地址、是否有二次确认、是否阻止默认行为"。表单里最隐蔽的 bug 之一就是按钮没写type，默认变成submit，点一下整页刷新。

type="color"提交的是#rrggbb格式的小写十六进制，部分场景需要#rgb简写时不支持，注释里说明一下即可。type="image"用作提交按钮且会额外提交点击坐标，现在基本不用了，见到了在注释里标一句"历史遗留"比较合适。

3. 从零搭一个带注释的完整表单

前面拆了类型，这一节完整走一遍搭建流程，把注释放在真实语境里看效果。场景选一个常见的"活动报名表单"，包含姓名、手机、邮箱、生日、人数、附件、协议勾选，字段不多但覆盖面够广。

3.1 结构骨架与 label 关联的正确写法

先定骨架。这里第一个决定就是label和input的关联方式，两种都行：for+id配对，或者label直接包裹input。前者结构更松，方便布局；后者不用管 id 唯一性。我倾向于配对写法，因为在做多列布局和自定义单选样式时更灵活。

id的唯一性是个隐形炸弹。同一个页面如果复用了两次表单组件，id重复会导致label的点击焦点跑到第一个输入框上。这种情况在弹窗里嵌套表单时特别常见。我的处理是给组件加一个前缀参数，注释里标明"id 需带实例前缀"。

<!-- 报名表单 v2 注意：本表单可能在同一页面出现多次（弹窗内嵌）， 所有 input 的 id 必须加实例前缀 instanceId_， 否则 label 的 for 会指向第一个实例，点击标签焦点跑偏 --> <form id="signupForm" action="/api/signup" method="post" enctype="multipart/form-data" novalidate> ... </form>

novalidate这个属性值得单独说。加上它意味着关闭浏览器原生气泡提示，改用自己的校验 UI。加不加取决于产品对提示样式的要求，但一定要在注释里写明"为什么关"，因为下一个人看到required和novalidate同时出现会以为写错了。

3.2 关键属性的取舍与参数计算

逐个字段配属性，重点讲取舍过程。

姓名字段：maxlength定多少？中文姓名极端情况能到十几个字，少数民族姓名加上间隔号可能更长，英文名带中间名也会超。我一般定 30，注释写清"30 是按后端字段 varchar(30) 定的，改这里必须同步改表结构"。这种"前端约束来自后端存储"的注释非常关键，它建立了两边的对应关系。

手机号：maxlength定 13 而不是 11，原因是允许用户输入"138 0013 8000"这种带空格的格式，提交前统一replace(/\s/g,'')。如果把maxlength卡死在 11，用户粘贴带空格的号码会被截断，反而更糟。这个取值过程必须写进注释，否则后人看到 13 会以为写错了改成 11。

报名人数：min="1" max="5"，这个 5 不是随便定的，是场地容量除以每单平均人数算出来的业务上限。注释里写清来源，产品改规则时才能找到该改哪里。

生日：max设成"今天"需要 JS 动态计算，HTML 里只能写死。所以注释要标明"max 由 JS 初始化时按当前日期回填，HTML 里写死的是兜底值"。

<!-- 姓名：必填，2-30 字符 30 对应后端 varchar(30)，改这里必须同步改表结构，否则超长会被截断 --> <input type="text" name="realName" id="realName" minlength="2" maxlength="30" required autocomplete="name"> <!-- 手机：必填，允许带空格输入，提交前去空格 maxlength 取 13 而非 11，是为了让用户粘贴 "138 0013 8000" 不被截断 --> <input type="tel" name="mobile" id="mobile" maxlength="13" required autocomplete="tel" inputmode="tel"> <!-- 报名人数：1-5 人，上限来自场地容量规则（每场限 30 人，单人最多报 5 位） 产品调整规则时同步修改此处与后端配置 --> <input type="number" name="personCount" id="personCount" min="1" max="5" step="1" value="1" required inputmode="numeric"> <!-- 生日：选填，格式 YYYY-MM-DD max 由 JS 在初始化时设为当天，HTML 里的值只是兜底，勿删 --> <input type="date" name="birthday" id="birthday" max="2024-12-31">

3.3 autocomplete 与 inputmode 的配置逻辑

这两个属性是表单体验里投入产出比最高的，但也是最容易被整段忽略的。

autocomplete的正确用法是给每个语义明确的字段配对应的值。姓名name、手机tel、邮箱email、地址street-address、邮编postal-code、验证码one-time-code。配好之后用户在手机上点输入框，键盘上方会出现"自动填充"的建议条，一次点击省掉十几次打字。反过来，如果所有字段都不写，浏览器只能靠启发式猜，经常把手机号填到姓名框里。

有个细节：autocomplete="off"在现代浏览器里对密码类字段基本无效，浏览器该填还是填。真要阻止，得用autocomplete="new-password"或者随机字符串，但后者会影响正常的自动填充体验。这个取舍我一般写成注释：

<!-- 验证码：6 位数字 autocomplete=one-time-code 让 iOS/Android 能直接从短信里读取并填充 如果产品要求禁止自动填充，改成 off 在部分浏览器无效，需配合 readonly 技巧 --> <input type="text" name="smsCode" id="smsCode" maxlength="6" inputmode="numeric" autocomplete="one-time-code" pattern="\d{6}">

inputmode决定弹什么键盘，比type更细粒度。numeric是纯数字键盘（无小数点），decimal带小数点，tel是电话键盘（带+、*、#），search的回车键显示"搜索"。这个属性在桌面端没有任何效果，所以很多人写完 PC 端测试通过就以为没问题了，实际上移动端的键盘类型完全取决于它。

3.4 提交前的归一化与校验分层

表单提交那一刻做的事情必须分清楚层次，否则会出现"前端校验了但后端还是报错"的困惑。

我的分层是这样的：浏览器原生校验（required、pattern、min/max）负责即时反馈，JS 归一化负责把用户输入整理成后端要的格式，后端校验负责最终的合法性。三层缺一不可，注释里要标明每一层的职责边界。

// 提交前归一化：只做格式整理，不做业务合法性判断 // 业务合法性（如手机号是否已注册）由接口返回，前端不要重复实现 function normalize(form) { return { // 去空格 + 去横线，兼容用户从通讯录粘贴的格式 mobile: form.mobile.value.replace(/[\s-]/g, ''), // 日期为空时传 null 而非空字符串，避免后端解析报错 birthday: form.birthday.value || null, // 复选框未勾选时显式传 false，避免字段缺失 agree: form.agree.checked, }; }

这段代码我特意在注释里写了"不要重复实现业务校验"，因为实际项目里最常见的浪费就是前端又写了一遍手机号归属地判断，结果和后端规则不一致，用户被前端拦住但后端其实允许。

4. 常见问题与排查技巧实录

这一节全部来自实际踩过的坑，整理成速查表加几条排查路径。

4.1 类型选错引发的连锁反应速查

这张表里最容易被忽视的是最后一条。iOS 上输入框字号小于 16px 时，聚焦会自动放大页面，用户得手动缩回去，体验极差。而这个问题的表现形式是"页面突然变大"，很少有人第一时间联想到字号。我的做法是在表单样式里统一写死输入框字号16px，或者用transform做缩放适配，注释里标一句"字号不可低于 16px，否则 iOS 会缩放"。

4.2 注释本身失效的几种情况

注释写了也可能白写，这个得承认。三种情况最常见。

第一种是注释和代码分离。HTML 的注释写在标签上方，如果后来有人把标签挪了位置，注释留下了，就变成了张冠李戴。这个没办法完全避免，只能靠格式化工具和代码评审时留意。

第二种是注释被压缩工具删掉。部分构建流程会移除 HTML 注释，这是正常的，注释的价值在源码阶段，不在产物里。但要提醒一句：如果你把业务提示写在注释里指望它出现在页面上，那方向就错了，那是placeholder或者提示文案的活。

第三种是注释写成了废话。<!-- 输入框 -->、<!-- 这里是姓名 -->这种，等于没写。判断标准我前面说过：注释里有没有代码本身看不出来的信息。没有就是废话，不如不写。

注意：注释里不要写具体的接口地址、密钥、内部系统名这类信息。编译产物里的 HTML 注释是能被用户看到的，虽然不是主要攻击面，但属于不必要的信息暴露。

4.3 表单体验层面的几个细节坑

placeholder不能当 label 用。输入内容后提示就消失了，用户看到一屏填好的输入框完全不知道每个框是什么。而且占位符的对比度通常偏低，可读性差。正确做法是永远有可见的label，placeholder只放格式示例。

readonly和disabled别混用。两者在 UI 上都表现为不可编辑，但disabled的字段不会提交，readonly会提交。这个差异在"展示订单号但需要提交"的场景里会直接导致数据丢失，我见过不止一次。

中文输入法的compositionstart问题。做实时校验（边输入边查重）时，拼音输入过程中input事件一直在触发，用户还没选字就开始查询，白白浪费请求。正确做法是监听compositionstart和compositionend，组合期间不触发校验。这个细节一定要写进注释，因为从代码上完全看不出为什么加了这两个监听。

回车键的行为。表单里有多个输入框时，在任意一个框按回车会触发表单的第一个提交按钮。如果第一个按钮是"取消"或者"重置"，就出大事了。处理方式是把主提交按钮放在 DOM 靠前的位置（用 CSS 调整视觉顺序），或者给按钮显式写type="button"。这个坑一旦踩过就忘不掉。

粘贴超长文本的处理。用户从 Excel 粘贴一列数据到单行输入框，maxlength会直接截断，用户以为全粘上了其实只留了前面一小段。这种情况在批量录入场景很常见，注释里至少要标明"本字段不接受批量粘贴"，产品层面加个提示更稳妥。

autofocus的副作用。移动端自动聚焦会立刻弹起键盘，遮挡页面内容；页面如果有滚动定位，还会导致定位偏移。我的习惯是不用autofocus，需要聚焦时用 JS 在合适的时机手动调用。

size属性的误解。它控制的是可见宽度（按字符数），不是最大长度，和maxlength完全是两回事。很多人用size想限制输入，结果用户还是能输进去，只是看不见。这个错误在老旧代码里特别多，看到size就顺手在注释里标一句它的真实含义。

5. 团队落地：注释规范怎么定才不会被当成废话

写注释这件事，个人做起来容易，团队推起来难。我参与过两次表单规范落地，一次失败一次勉强成功，把经验摊开说。

5.1 一份可以直接抄的注释模板

模板的核心是"固定位置 + 固定顺序 + 可省略"，不要搞得像填表格，否则没人愿意写。我给团队定的模板是这样的：

<!-- [字段名]：[业务语义] [约束]：长度/格式/范围/必填 [选型]：为什么用这个 type（可省略，默认类型时必写） [特殊]：联动、异步、归一化等行为（可省略） [风险]：已知缺陷、兼容包袱（可省略） -->

方括号里的标签不是强制标记，而是提醒你从哪几个角度想。实际写出来就是一段自然语言。举一个完整的例子：

<!-- 邀请码：8 位大写字母数字，选填 选型：用 text + pattern 而非 number，因为含字母 特殊：失焦时调 /api/checkInvite 校验有效性，组合输入期间不触发 风险：pattern 在部分内核不生效，后端必须二次校验格式 --> <input type="text" name="inviteCode" id="inviteCode" maxlength="8" pattern="[A-Z0-9]{8}" autocomplete="off">

多行注释能用一行写完的就不写多行。像"手机号，11 位，必填"这种一句话说完的，就别拆成五行。模板是给你打底的，不是给你凑字数的。

5.2 评审时真正该检查的几项

规范定了之后靠什么落地？靠评审清单。我在评审表单相关代码时会固定看几项：

第一，每个input是否有name和id。没有name就不参与提交，没有id就没法关联label，这两个是最基础的结构完整性。

第二，每个input上方是否有说明。搜索一下文件里type="text"出现的次数，逐个对照有没有注释，这一步很机械但很有效。

第三，autocomplete是否配了有意义的值。全空或者全是off，说明写的人没考虑过填充场景。

第四，type的选择是否有理由。看到number和date就多问一句"降级和格式问题怎么处理的"，问到两次之后，写的人下次就会主动写注释了。

第五，注释里的约束和后端字段长度是否对得上。这一步需要拉后端一起看，但对齐一次能省掉后面无数次截断排查。

第六，有没有type缺失的按钮。<button>不带type默认是submit，这个在表单里是高频事故点。

我个人在实际操作中的体会是，规范能不能落地不取决于文档写得多漂亮，取决于评审时有没有人真的去问。只要连续两三个需求都有人问"这个为什么用 number"，第三个需求开始，大家自己就会把理由写在注释里。反过来，如果规范发下去之后没人看没人问，两周之后就没人记得还有这回事了。

最后分享一个小技巧：给团队里的高频字段（手机号、邮箱、金额、身份证、日期）做一个代码片段库，编辑器里敲缩写就能展开成带完整注释的模板。这招比任何规范文档都管用，因为它把"写注释"这件事的成本降到了零，而人只会做零成本的事。片段里的注释写得糙一点没关系，用得多了自然会被改进，最怕的是没人用。