必填字段应依据用户动作链动态控制而非静态标记。关键在于填写路径自然性、验证可预期性及无障碍连贯性；需结合JavaScript动态设置required属性、用.trim()和正则增强校验，并确保服务端重校验；分组需语义清晰，避免视觉与语义不一致。
必填和选填不是靠加几个 required 属性就能定下来的，关键在于用户填写路径是否自然、验证逻辑是否可预期、无障碍体验是否连贯。
哪些字段该标 required？看用户动作链，不是看业务规则
用户填写表单时有隐含的「动作顺序」：先填身份信息，再选服务类型，最后补充细节。如果「手机号」只在「勾选接收短信通知」后才需要，那它就不该一开始就 required；否则会打断流程，还触发无效校验。
- 真正必须的字段，是用户无法跳过、且后续所有操作都依赖它的——比如注册页的
email和password - 看似必要但实际有条件触发的字段（如「身份证号」仅用于实名认证），应配合 JavaScript 动态控制
required属性，而不是静态写死 - 用
aria-required="true"同步标注，避免屏幕阅读器只读到视觉星号而忽略语义
required 不能替代业务校验逻辑
浏览器原生的 required 只检查是否为空字符串，对空格、纯换行、零宽字符完全不拦截。用户输个空格就绕过校验，后端照样收到脏数据。
- 前端需额外用
.trim()判断有效性，例如：if (input.value.trim() === '') - 涉及格式校验（如邮箱、手机号）必须用
pattern或 JS 正则，required自身不提供格式能力 - 服务器端必须重做全部校验——
required被禁用、JS 被绕过、请求被篡改时，它形同虚设
分组和视觉提示要匹配 required 状态
把五个字段全塞进一个 fieldset，其中两个标了 required，另外三个没标，会导致语义混乱：屏幕阅读器读出“收货信息组”，却无法区分哪些是强制项。
- 按用户意图分组（如「登录凭证」「配送地址」「发票信息」），每组内统一处理必填逻辑
-
legend文字里避免混用「* 必填」这类冗余标记——required已通过属性和 ARIA 暴露，视觉上用 CSS 控制星号或边框色更可控 - 禁用整组时直接给
fieldset加disabled，别单独 disable 每个控件，否则required仍可能被误触发
最常被忽略的是：用户没填的字段，未必是「漏填」，可能是「还没到填的时候」。动态控制 required 的时机、位置和反馈方式，比单纯打勾画叉重要得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
