表单代码怎么写：从 HTML 结构到常用输入项

表单是网页收集用户信息并提交给程序处理的标准方式。登录、注册、搜索、预约、反馈和文件上传，都可以用 HTML 表单实现。写好一个表单，不只是把几个输入框放到页面上：还要让字段含义清楚、键盘操作顺畅、提交方式正确，并在服务端重新检查收到的数据。

本文从表单的基本结构开始，依次介绍常用输入项、提交参数、约束校验和安全边界。示例中的服务端地址需要替换为你自己的接口；HTML 本身可以完成界面和提交动作，但不会替代后端处理。

一、表单的基本结构

表单内容放在 <form> 元素中。最常用的属性是 action 和 method：

• action：接收表单数据的 URL。省略时，浏览器通常提交到当前页面。
• method：提交方法，常见值为 get 和 post。
• name：提交时标识字段的名称。没有 name 的表单控件通常不会作为字段提交。

<form action="/contact" method="post">
  <label for="email">电子邮箱</label>
  <input id="email" name="email" type="email" required>

  <button type="submit">发送</button>
</form>

id 用于在页面中唯一标识元素，for 用来把标签和对应控件关联起来；name 则用于构造提交数据。三者用途不同，不能因为已经写了 id 就省略 name。

GET 与 POST 怎么选

GET 会把表单字段编码到 URL 的查询字符串中，适合搜索、筛选等读取数据的操作。例如搜索词可能显示为 /search?q=keyboard。这样的 URL 可以收藏、分享，也便于浏览器缓存和导航。不要把密码、身份证号、访问令牌等敏感信息放进 GET 请求：查询字符串可能出现在浏览器历史记录、服务器日志、代理记录或引用信息中。

POST 会把数据放在请求体中，适合提交注册信息、创建记录等操作。它不会像 GET 那样直接把字段放入 URL，但这不等于数据自动加密或安全。包含敏感信息的请求仍需通过 HTTPS 传输，并由服务端妥善处理。具体使用 GET 还是 POST，还应与接口约定一致。

二、先把标签和控件写清楚

每个控件都应有可见且明确的标签。推荐使用 <label>，并通过 for 与控件的 id 对应。点击标签也能聚焦或激活对应控件，屏幕阅读器也更容易读出字段含义。

<label for="username">用户名</label>
<input id="username" name="username" type="text">

也可以把控件放进标签内部，这时通常不必写 for 和 id 的配对：

<label>
  用户名
  <input name="username" type="text">
</label>

尽量不要只用占位提示代替标签：

<!-- 不推荐：占位提示不能替代字段标签 -->
<input name="email" placeholder="请输入邮箱">

占位提示会在用户输入后消失，也可能因为颜色对比不足而难以辨认。可以用它补充格式示例，但标签仍应保留。需要说明错误或格式要求时，可通过说明文字和 aria-describedby 建立关联。

三、常用输入项及适用场景

文本、邮箱和电话

type="text" 适合姓名、标题等普通单行文本。type="email" 可以启用适合邮箱输入的键盘和浏览器格式检查，但浏览器判断并不代表地址真实存在，也不能确认用户拥有该邮箱。type="tel" 适合电话号码，主要提供输入语义和设备上的键盘优化；电话号码格式受国家和地区影响，不能假设它只由固定长度数字组成。

<label for="full-name">姓名</label>
<input id="full-name" name="fullName" type="text" autocomplete="name" required>

<label for="email-address">电子邮箱</label>
<input id="email-address" name="email" type="email"
       autocomplete="email" required>

<label for="phone">联系电话</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

autocomplete 用来提示浏览器字段含义，例如 name、email 和 tel。它通常有助于自动填充，不是必填校验规则，也不应当被当作安全控制。

密码

type="password" 会遮挡输入内容，但遮挡只影响页面显示，不会加密数据。传输和存储的安全要由 HTTPS、服务端密码存储方案等机制保证。登录字段常用 autocomplete="current-password"，设置新密码时常用 autocomplete="new-password"。

<label for="password">密码</label>
<input id="password" name="password" type="password"
       autocomplete="new-password" required>

多行文本

<textarea> 用于留言、说明等多行内容。初始文本应放在开始标签和结束标签之间，而不是使用 value 属性。

<label for="message">留言</label>
<textarea id="message" name="message" rows="5"
          maxlength="1000"></textarea>

rows 控制初始可见行数，不限制用户最终提交的字数。maxlength 可以限制浏览器允许输入的长度，但服务端仍需按自身规则再次检查。不同语言字符、编码和后端长度计算方式可能不同，设计限制时要统一单位和处理规则。

数字、日期和时间

type="number" 适合有数学意义、允许数值运算的字段，例如数量或温度，不适合电话号码、邮编、账号等标识符。标识符可能有前导零，也不应该接受加减运算。min、max 和 step 可用于浏览器端的数值约束：

<label for="quantity">购买数量</label>
<input id="quantity" name="quantity" type="number"
       min="1" max="20" step="1" required>

这些属性能参与浏览器的约束校验，但不能保证请求一定满足限制。用户可以绕过页面直接发送请求，因此后端必须重新验证数值范围、整数要求以及业务规则。step 也不是显示格式的设置。

日期和时间输入项在不同浏览器、系统中的呈现可能不同，应在目标设备上测试。提交时，日期类字段通常使用标准化的值，而页面控件的显示样式由浏览器决定。

<label for="visit-date">预约日期</label>
<input id="visit-date" name="visitDate" type="date" required>

<label for="start-time">开始时间</label>
<input id="start-time" name="startTime" type="time">

单选、复选和下拉选择

一组选项中只能选一个时，使用同名的单选框；允许同时选择多个时，使用复选框。单选框必须使用相同的 name 才会组成一组。每个选项应有自己的 value，提交时发送的是这个值，而不是标签文字。

<fieldset>
  <legend>希望的联系时间</legend>

  <label>
    <input type="radio" name="contactTime" value="morning" required>
    上午
  </label>

  <label>
    <input type="radio" name="contactTime" value="afternoon">
    下午
  </label>
</fieldset>

<fieldset>
  <legend>感兴趣的主题</legend>

  <label>
    <input type="checkbox" name="topics" value="html">
    HTML
  </label>

  <label>
    <input type="checkbox" name="topics" value="accessibility">
    无障碍
  </label>
</fieldset>

<fieldset> 和 <legend> 用于标记一组相关控件及其标题，对阅读和理解分组选项有帮助。复选框未选中时通常不会提交对应字段；如果业务需要表达“明确为否”，不能简单假设没收到参数就代表用户选择了否，应在接口设计中定义清楚。

选项较多时，可以用 <select>：

<label for="region">所在地区</label>
<select id="region" name="region" required>
  <option value="">请选择</option>
  <option value="north">北区</option>
  <option value="south">南区</option>
</select>

提示选项的 value="" 配合 required，可以让浏览器把它视作尚未选择有效值。后端仍应验证收到的值是否属于允许范围，不能因为它出现在页面下拉列表里就默认可信。

隐藏字段

type="hidden" 可以随表单发送页面流程需要的普通参数，但隐藏不等于保密。用户可以查看页面源码或修改请求，不能把价格、权限、折扣资格等重要决定只放在隐藏字段里。

<input type="hidden" name="campaign" value="spring">

文件上传

文件控件使用 type="file"。表单通常需要设置 method="post" 和 enctype="multipart/form-data"，否则文件内容不会按预期以多部分数据上传。

<form action="/upload" method="post"
      enctype="multipart/form-data">
  <label for="attachment">选择附件</label>
  <input id="attachment" name="attachment" type="file"
         accept=".pdf,image/*">

  <button type="submit">上传</button>
</form>

accept 是给文件选择界面的类型提示，不是可靠的文件安全校验。用户或客户端可以绕过它，上传的扩展名、MIME 类型和文件内容也可能不一致。服务端应结合业务需要检查文件大小、允许的类型和实际内容，采用安全的文件名与存储策略，并考虑恶意文件扫描、访问控制和下载时的响应头。浏览器端的文件限制不能替代这些措施。

四、表单校验：便利，不是安全边界

HTML 提供了一些客户端约束属性，能帮助用户在提交前发现常见输入问题：

• required：要求控件有值。不同类型对“有效值”的含义不同。
• minlength、maxlength：限制文本输入长度。
• min、max、step：对支持这些约束的数字或日期时间控件设置范围和步长。
• pattern：用正则表达式约束部分文本输入，完整匹配规则应按 HTML 的 pattern 语义编写。
• type="email"、type="url"：提供相应类型的格式约束和输入体验。

<label for="code">项目代码（6 位大写字母或数字）</label>
<input id="code" name="code" type="text"
       pattern="[A-Z0-9]{6}" required>

为避免正则表达式在浏览器和后端之间产生差异，复杂规则最好由服务端定义并作为最终依据；页面上的校验主要用于尽早提示用户。不要用客户端校验来保护权限、价格或隐私数据，也不要认为禁用提交按钮就能阻止伪造请求。

对于无效控件，浏览器通常会阻止常规表单提交并显示提示。添加 novalidate 会关闭表单的原生提交校验；如果使用它，就要自行实现清楚、可访问的校验反馈，并确保服务端仍执行验证。JavaScript 中调用表单的 submit() 方法也可能绕过原生校验；需要触发浏览器校验时，可使用相应的校验流程，而不是把前端行为视作后端保障。

五、按钮类型与重复提交

表单中的按钮要明确设置 type。普通的 <button> 在表单内默认可能充当提交按钮；如果它只是用于展开说明、清空输入或运行页面脚本，未设置类型可能导致意外提交。

• type="submit"：提交表单。
• type="button"：普通按钮，不会自动提交。
• type="reset"：把控件恢复为初始值，容易让用户误删内容，应谨慎使用。

<button type="submit">保存</button>
<button type="button" id="preview">预览</button>
<button type="reset">清空恢复为初始值</button>

前端禁用按钮可以减少误点造成的重复操作，但网络重试、多个标签页、脚本调用或直接请求仍可能产生重复提交。对创建订单、付款或其他有副作用的接口，服务端应设计合适的幂等机制，不能只依赖按钮状态。

六、一个可改造的完整表单

下面的示例包含基本文本字段、下拉选项、单选框、复选框和留言框。它使用 POST 提交，字段都具有明确的标签和名称。将 /feedback 替换成实际接口后，服务端仍需验证字段并返回适当结果。

<form action="/feedback" method="post">
  <div>
    <label for="name">姓名</label>
    <input id="name" name="name" type="text"
           autocomplete="name" maxlength="100" required>
  </div>

  <div>
    <label for="email">电子邮箱</label>
    <input id="email" name="email" type="email"
           autocomplete="email" required>
  </div>

  <div>
    <label for="category">反馈类别</label>
    <select id="category" name="category" required>
      <option value="">请选择</option>
      <option value="bug">问题反馈</option>
      <option value="suggestion">功能建议</option>
    </select>
  </div>

  <fieldset>
    <legend>是否需要回复</legend>

    <label>
      <input type="radio" name="reply" value="yes" required>
      需要
    </label>

    <label>
      <input type="radio" name="reply" value="no">
      不需要
    </label>
  </fieldset>

  <div>
    <label for="details">反馈内容</label>
    <textarea id="details" name="details" rows="6"
              maxlength="2000" required></textarea>
  </div>

  <label>
    <input type="checkbox" name="consent" value="yes" required>
    我确认以上信息可用于处理本次反馈
  </label>

  <button type="submit">提交反馈</button>
</form>

示例中的 required 和长度限制只提供浏览器端的输入提示。服务端需要检查字段是否存在、类型是否正确、长度是否在业务允许范围内、分类值是否有效，以及用户是否有权执行该操作。若页面采用会话登录并接受有状态的敏感操作，还要按照应用架构考虑 CSRF 防护；仅仅使用 POST 不会自动防止 CSRF。

七、表单数据怎样提交

浏览器主要提交成功控件的名称和值。通常只有带有 name、处于有效提交范围内且没有被禁用的控件会参与提交。未选中的复选框、没有选项的单选组，以及没有名称的控件通常不会提供对应字段。处理服务端参数时，应区分“字段没有提交”和“字段提交了空字符串”，不要把两者随意当作同一种情况。

GET 的查询字符串适合可分享的读取条件，但 URL 长度受浏览器、服务器和中间设备等实现限制，不应拿它传大段文本或文件。文件上传通常使用 POST 与多部分编码。若使用 JavaScript 和 FormData 发起文件请求，通常不应手动把请求的 Content-Type 设成固定的 multipart/form-data，因为浏览器需要自行添加包含边界值的请求头。

八、容易出现的错误

1. 只有 id，没有 name。控件可以显示和被脚本找到，但可能不会作为表单字段提交。需要服务端接收的控件要设置 name。
2. 用占位符代替标签。占位内容不是稳定、清晰的字段名称。为控件提供关联的可见标签。
3. 把前端校验当成安全校验。HTML 属性可被绕过。服务端必须重新验证参数、权限和业务状态。
4. 把 type=”password” 当成加密。它只遮挡页面输入。敏感数据的传输和存储需要对应的安全措施。
5. 用 number 输入账号或电话。这类值是标识符，不是数学数值；数字类型可能改变格式、限制输入或丢失前导零。
6. 以为 accept 能拦住危险文件。它主要影响文件选择提示。服务端仍要检查文件并安全存储。
7. 按钮漏写 type。不打算提交的按钮应明确写 type="button"，避免意外触发表单提交。
8. 把隐藏字段当作可信参数。隐藏字段仍由客户端控制。重要数据应由服务端查验或计算。
9. 认为禁用提交按钮就能防止重复请求。按钮禁用只是交互优化，关键操作需要服务端处理重复请求。

九、上线前检查清单

• 每个要提交的字段都有合适的 name。
• 每个输入项都有清楚的标签，标签与控件正确关联。
• 表单的 action、method 和接口约定一致。
• 上传文件时使用适合的编码方式，并在服务端实施文件校验。
• 必填、长度和格式提示对用户有帮助，但服务端会独立执行校验。
• 不把秘密、权限判断或可信价格放在客户端字段中。
• 键盘可以操作控件，错误提示清楚，分组选项有合适的标题。
• 评估敏感操作的 HTTPS、CSRF 防护、重复提交处理和数据保留策略。

写表单时，先明确每个字段的含义和提交规则，再选择合适的控件类型。HTML 负责表达结构、输入语义和基础交互；真正的数据可信度、权限和安全性，最终要由服务端及完整应用架构保证。