HTML 表单里的 required：别以为加了就万事大吉

写表单的时候，你是不是也习惯随手给输入框加上 required 属性？毕竟这能省去大半的 JavaScript 校验代码。浏览器会自动弹出提示框，告诉用户“这里不能为空”，听起来挺美。但真正落地的项目里，原生校验带来的麻烦往往比它解决的问题还多。

最直观的感受就是“丑”。浏览器的默认弹窗样式固定，既没法调整位置，也没法控制文案风格。在移动端，这个弹窗还可能遮挡住提交按钮，导致用户想关闭都找不到地方。更尴尬的是，当表单包含复杂逻辑时——比如“如果选择了公司，就必须填工号，否则留空”——单靠一个 required 属性根本搞不定。这时候你会发现，依赖原生校验反而成了后续维护的负担。

既然要改，不如把控制权拿回来。利用 CSS 伪类 :invalid 和 :valid，我们可以轻松自定义错误状态下的边框颜色和图标。记得同时配合 :required 伪类，给必填项加上醒目的星号标记。但要注意，这里的视觉反馈只是第一步，真正的关键在于如何替换掉那个难看的原生提示框。

这就得用到 JavaScript 的 setCustomValidity() 方法了。它的逻辑并不复杂：当你在提交前检测到字段不合法时，调用这个方法传入一段自定义的错误信息；而一旦数据通过验证，记得再次调用该方法并传入空字符串，否则浏览器会一直认为该字段无效，导致表单无法提交。很多新手在这里踩坑，加了校验却永远点不动提交按钮，就是因为漏掉了“清空错误状态”这一步。

还有一个隐蔽的陷阱是隐藏字段。有些业务场景下，我们会用 CSS display: none 把某些 input 藏起来。如果你不小心在这些隐藏字段上加了 required，表单就会直接失效，无论用户怎么填都无法提交。因为即使看不见，它们在 DOM 树里依然是活跃的必填项。处理这类情况时，要么去掉 required 改为后端强校验，要么使用 JavaScript 动态移除属性，确保视觉隐藏的逻辑与表单提交互不冲突。

别忘了无障碍访问（Accessibility）。虽然 required 能让屏幕阅读器知道这是必填项，但为了更好的兼容性，建议显式地加上 aria-required="true" 属性。这不仅是为了合规，更是为了确保那些依赖辅助技术的用户也能获得同等的提示信息。当字段出错时，配合 aria-invalid="true" 和 aria-describedby 关联具体的错误描述区域，体验会比单纯的红色边框友好得多。

归根结底，required 是一个很好的快捷工具，适合那些简单、通用的必填场景。但在追求精致交互的 C 端产品里，它更像是个基础底座，而非最终方案。将原生校验作为兜底策略，前端逻辑作为主要交互手段，既能保证基本的可用性，又不会牺牲用户体验。技术没有绝对的优劣，只有适不适合当下的场景。下次再加 required 之前，不妨先想想，用户真的需要那个突然弹出的对话框吗？