必填项需同时满足语义、视觉、交互三要素：用required属性触发原生校验，配合::after星号提示和aria-required增强可访问性，服务端必须同步校验。
HTML表单元素怎么标必填项才真正生效
只加 required 属性，浏览器会校验提交，但用户未必看得懂哪里必须填——视觉上没提示，焦点也不自动跳转，错误信息还可能被CSS盖住。真正的“必选”得同时满足语义正确、视觉可识别、交互有反馈。
-
required是唯一被所有现代浏览器原生支持的必填声明方式，不依赖JS；漏写它，aria-required="true"或 CSS伪类都只是装饰 - 用
::before或::after在label后加星号（如content: " *"; color: #d32f2f;），但必须确保该样式在高对比度模式下仍可见 - 别把
required加在div或span上——它只对表单控件有效，比如input、select、textarea - 如果用了自定义组件（如封装的
MyInput），required不会自动透传到内部input，得手动绑定
aria-required 和 required 一起用是不是多余
不是多余，是互补。屏幕阅读器对 required 的支持已很成熟，但某些老版本 NVDA 或 JAWS 配合特定浏览器时，仍可能忽略纯 required，此时 aria-required="true" 是保险绳；不过它不能触发原生表单校验，只负责播报。
- 两者都写最稳妥：
<input required aria-required="true"> -
aria-required="false"明确声明“非必填”有时比不写更有用，尤其在动态表单中避免歧义 - 别在已有
required的元素上写aria-required="false"——逻辑冲突，部分读屏会报错 -
aria-required对type="hidden"无效，隐藏域本身就不参与校验，加了也白加
用 CSS 伪类 :required 匹配样式为什么有时不生效
因为 :required 只匹配带 required 属性的元素，且该属性必须是 HTML 属性（attribute），不是 JS 动态设置的 property。DOM 中 el.required = true 不会触发 :required 伪类匹配。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 写法必须是
<input required>或<input required="">，不能靠 JS 设置el.setAttribute('required', '')后再指望样式立刻生效（多数浏览器会，但 Safari 旧版有延迟） - 如果用 Web Components 或框架（如 React），JSX 里写
required会被编译为 property，需显式写成required={true}并确认最终渲染出的是 HTML attribute -
:required不支持嵌套选择器穿透 Shadow DOM，自定义元素内需在 shadow root 里单独写样式 - 和
:invalid混用时注意：空值的required输入框初始即为:invalid，但用户未聚焦前，部分浏览器默认不显示红框
服务端验证还用管前端的 required 吗
必须管。所有前端标记都是提示和辅助，不是安全边界。required 可被禁用、绕过、或在 curl / Postman 中直接丢弃，后端不校验等于裸奔。
立即学习“前端免费学习笔记（深入）”；
- 前后端必填逻辑必须完全一致，比如前端
required了邮箱，后端就得校验非空 + 格式 + 可送达性（至少发个验证邮件） - API 返回的错误字段名要和前端
name属性对齐，否则fetch报错后没法精准定位到哪个输入框 - 别用
required替代业务规则，比如“手机号必填”和“手机号需为11位大陆号码”是两层事，后者只能靠后端+正则双重卡 - SSR 渲染时若服务端没同步输出
required，首屏可能闪动——前后端模板要保持属性一致
最容易被忽略的是：当表单被 JS 动态增删字段时，required 的增删必须同步操作 DOM attribute，而不是只改 JS 状态；否则校验、样式、读屏都会脱节。
