display: none 会让 radio 值消失，因浏览器表单序列化时跳过该控件，视其为“不存在”；应改用 position: absolute + left: -9999px 等视觉隐藏方式，确保 DOM 可访问、可提交。
直接给 加 display: none 会导致表单提交时该选项完全丢失——FormData 里没有它，form.elements 查不到，JS 读 checked 也始终为 false。这不是“看不见”，是浏览器认定它“不存在”。
为什么 display: none 会让 radio 值消失
浏览器在序列化表单（如 form.submit()、new FormData(form)）时，会跳过所有 display: none 的表单控件。哪怕 DOM 中存在、用户通过 JS 手动设了 checked = true，提交时仍被忽略。这是规范行为，不是 bug。
-
visibility: hidden不行：元素还在文档流中、占位、可被 Tab 键聚焦，甚至子元素（比如 label 里的图标）可能意外显示 -
aria-hidden="true"不行：只影响读屏软件，对表单提交、焦点、JS 查询毫无作用 -
opacity: 0单独用也不安全：若没同步设pointer-events: none和tabindex="-1"，键盘用户可能卡在不可见按钮上
真正保留功能的三种视觉隐藏方式
必须满足两个条件：元素仍在 DOM 中可访问、能被 JS 读取和序列化；同时视觉上不可见且不干扰布局或焦点流。
-
position: absolute; left: -9999px; width: 1px; height: 1px; overflow: hidden;—— 兼容性最好（IE9+），但需手动加tabindex="-1"防止键盘聚焦 -
clip-path: inset(100%);—— 现代浏览器（Chrome 84+、Firefox 75+、Safari 15.4+）可用，不占空间、不影响 tab 顺序，但 IE 完全不支持 -
opacity: 0; pointer-events: none;—— 仅限你完全控制交互逻辑的场景（比如只靠 JS 触发选中）；它仍占据布局空间，且必须配tabindex="-1"，否则键盘导航会停顿
用隐藏域
仅当「不需要用户选择、也不需要语义化表单交互」时才考虑替换。比如后台预设值、流程状态标记、或纯 JS 控制逻辑。这不是隐藏 radio，而是放弃它。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 删除原
及其 - 插入
，确保name与原 radio 组一致 - 若需动态变更值，用 JS 修改：
document.querySelector('input[name="PersBus"]').value = "2"; - 注意：多个同名
提交时，后端收到的是数组（如 PHP 的$_POST['PersBus']是数组），而单个 radio 提交的是字符串
label 才是交互主体，别藏错对象
用户实际点击的是 ，不是 radio 本身。所以更常见、更安全的做法是：隐藏 radio，但保留并强化 label。
- 给 radio 应用上述任意一种视觉隐藏方式（如
position: absolute） - 确保每个 radio 有唯一
id，且对应或直接包裹结构 - label 本身不要设
pointer-events: none，否则点击失效 - 如果 label 也要隐藏（比如纯后台逻辑），那就该换思路：用
+ JS 控制值，而不是硬藏 radio
复杂点在于：视觉隐藏和功能保留之间没有“一键两全”的方案。是否要兼容 IE？是否允许键盘导航？是否依赖屏幕阅读器？漏掉 tabindex="-1" 或误信 aria-hidden，都可能让隐藏变成可访问性灾难。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
