readonly 对 radio 无效是标准行为，因其仅适用于文本类输入控件；radio 属选择类，应使用 disabled 或 JS 阻断事件配合 hidden 字段来实现只读效果。
readonly 属性对 <input type="radio"> 无效，浏览器会直接忽略它 —— 这是标准行为，不是 bug。
为什么 readonly 对 radio 没用
HTML 规范明确限定 readonly 只适用于 text、search、url、tel、email、number、password、date 等可编辑文本类输入控件。而 radio 属于“选择类”控件，其交互逻辑由 checked 状态和 disabled 控制，没有“只读但可聚焦/可提交”的语义支撑。
常见错误现象：
– 写了 readonly 但点击仍能切换选项
– 表单提交时值照常发送，毫无限制效果
用 disabled 替代的注意事项
这是最直接的替代方案，但有副作用：禁用后该控件的值默认不会随表单提交（FormData 和传统 form submit 都跳过 disabled 字段）。
立即学习“前端免费学习笔记（深入）”；
- 若需保留提交值，必须额外加一个
<input type="hidden">同名同值字段 -
disabled元素无法获得焦点，键盘导航会跳过它 - 样式上通常变灰、降低透明度，视觉反馈强 —— 如果你只想“不可点但保持原貌”，这反而成了干扰
示例：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
<input type="radio" name="plan" value="pro" disabled> <input type="hidden" name="plan" value="pro">
模拟只读效果：阻止点击 + 保持提交
目标是：不改变视觉、允许聚焦、值能提交，但用户点不了。核心思路是拦截事件 + 锁定状态。
- 给所有相关 radio 添加
onclick="return false;"或监听click并调用event.preventDefault() - 确保初始
checked状态正确，且 JS 不意外修改它 - 避免同时加
disabled，否则隐藏域可能被误判为冗余
更稳妥的做法（推荐）：
<input type="radio" name="theme" value="dark" checked
onclick="event.preventDefault();"
onkeydown="if(event.key===' ' || event.key==='Enter') event.preventDefault();">
注意：仅靠 onclick 不够，键盘空格/回车也能触发切换，所以补上 onkeydown。
用 CSS 配合实现“视觉只读”
如果只是防止误操作，又想保留原生交互感（比如聚焦轮廓），可以纯 CSS 锁定点击区域：
- 给 radio 的父容器或 label 加
pointer-events: none; - 再给内部
<input>单独设pointer-events: auto;（但实际无效，因为 input 本身不响应 pointer-events） - 真正有效的是：对
input[type="radio"]设置cursor: default;+user-select: none;，再配合 JS 阻断事件
CSS 本身不能阻止 radio 切换，它只是辅助提示。关键逻辑仍在 JS 层。
复杂点在于：多个同名 radio 组中，必须统一控制所有项；动态插入的 radio 容易漏掉绑定；服务端渲染时若 JS 失效，就彻底失去防护 —— 所以最终提交前，服务端仍应校验该字段是否在合法取值范围内。
