radio必填验证需确保同组name属性完全一致，原生required才生效；JS手动验证应使用:checked伪类并过滤不可见元素，后端必须二次校验。
radio 必填验证不能只靠 required 属性
HTML 原生 required 对 是有效的，但有个关键前提：同一组 radio 必须共享相同的 name 属性。如果漏写或写错 name，required 就完全失效，表单还能提交——这是最常踩的坑。
浏览器原生验证只检查「该 name 组中是否有任一 radio 被选中」，不关心具体值、不触发自定义提示、也不阻止 JS 提交（比如用 form.submit() 绕过）。
-
name值必须完全一致（包括大小写和空格），否则浏览器认为是不同组 - 至少一个
需有required，但加在任意一个上即可，无需每个都加 - 若用 JS 动态插入 radio，要确保插入后
name仍统一，且 DOM 已就绪再调用checkValidity()
用 JavaScript 手动验证 radio 是否已选
原生验证不可靠时，直接读取 document.querySelectorAll('input[name="xxx"]:checked').length 是最稳的方式。它不依赖表单提交时机，可嵌入任何校验逻辑中（比如按钮点击、离开焦点、甚至实时监听）。
注意：不能用 element.value 判断，因为未选中的 radio 的 value 仍有值，只是没被激活；必须查 :checked 状态。
- 推荐封装成函数：
function isRadioSelected(name) { return document.querySelectorAll(`input[name="${name}"]:checked`).length > 0; } - 若 name 含特殊字符（如点号、中括号），需用
document.querySelector+ 属性选择器转义，或改用getElementsByName配合遍历 - 在
submit事件里调用并event.preventDefault()，比依赖原生required更可控
避免 disabled 或 hidden radio 干扰验证结果
disabled 的 radio 不会出现在 :checked 伪类匹配中，也不会被 getElementsByName 返回——这点没问题。但容易忽略的是：如果某个 radio 被设为 display: none 或 visibility: hidden，它依然可能被选中，且会被 :checked 匹配到，导致误判「已选中」。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 验证前先过滤掉不可见元素：
Array.from(document.querySelectorAll(`input[name="${name}"]:checked`)).filter(el => el.offsetParent !== null).length > 0 - 更稳妥的做法是：把隐藏选项的
name改掉（比如加_hidden后缀），彻底隔离出验证范围 - 不要用
disabled来「隐藏」选项，它语义是「禁用」，不是「隐藏」；视觉隐藏请用 CSS，并同步移除其参与验证的资格
后端仍需重复校验 radio 值
前端所有验证都可被绕过，包括 required 和 JS 检查。后端收到请求时，必须再次确认该字段是否存在、是否在预设合法值列表中、且非空字符串。
例如 Node.js/Express 中：if (!req.body.gender || !['male', 'female', 'other'].includes(req.body.gender)) { return res.status(400).send('gender is required and must be valid'); }
特别注意：如果前端没传该字段（即 radio 全未选），req.body.gender 可能是 undefined、null 或空字符串，取决于框架默认行为，不能只判 == ''。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
