HTML 原生 disabled 属性是禁用单选按钮的语义正确、无障碍友好、无需 JS 的首选方案，它使选项置灰不可交互且提交时自动忽略；错误做法包括 disabled="false"、readonly 或禁用父容器。
直接用 disabled 属性禁用特定单选按钮
HTML 原生就支持对单个 <input type="radio"> 设置 disabled，它会让该选项置灰、不可点击、不响应空格/回车切换，且提交时完全忽略其值——这才是语义正确、无障碍友好、无需 JS 的首选方案。
常见错误包括：disabled="false"（无效）、readonly（<input type="radio"> 不支持）、或误把 disabled 加在父容器上。
正确写法示例：
<input type="radio" name="action" value="edit" disabled> 编辑（无权限）<br> <input type="radio" name="action" value="view"> 查看<br> <input type="radio" name="action" value="delete" disabled> 删除（无权限）
注意：所有同 name 的 radio 仍属同一组，互斥逻辑不受影响；被禁用项只是“不能选”，不是“不存在”。
立即学习“前端免费学习笔记（深入）”；
JavaScript 动态控制权限相关的禁用状态
权限常来自后端返回的数组（如 ["view", "export"]），前端需比对并禁用不在列表中的选项。关键不是“怎么设 disabled”，而是“什么时候设、设完是否清理状态”。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 必须等 DOM 就绪后再操作，否则
document.querySelectorAll('input[name="action"]')可能为空 - 不要只改
el.disabled = true，还要检查当前已选中的项是否恰好是刚被禁用的那个——如果是，得主动清除或 fallback 到一个有效项，否则表单提交会带出非法值 - 遍历 radio 列表时，推荐用
Array.from(radios)转成数组，避免 HTMLCollection 实时性导致漏处理 - 禁用后建议显式设
el.checked = false，因为某些浏览器在 disabled 后不会自动清掉 checked 状态
简短示例：
const perms = ["view", "export"]; // 来自 sessionStorage 或 API
const radios = document.querySelectorAll('input[name="action"]');
Array.from(radios).forEach(radio => {
const isAllowed = perms.includes(radio.value);
radio.disabled = !isAllowed;
if (!isAllowed && radio.checked) {
radio.checked = false;
}
});
禁用后按钮仍可提交？检查表单提交逻辑
disabled 的 radio 确实不参与提交，但容易踩坑的是：后端没做校验，或前端用了非标准方式取值（比如手动拼接 name 找所有 input 并忽略 disabled 状态）。
务必确认以下两点：
- 服务端必须校验提交的
action值是否在白名单内，不能信任前端禁用逻辑 - 如果用 JS 获取选中值，别写
document.querySelector('input[name="action"]:checked').value—— 这会在全部被禁用时返回null，应加空值判断或 fallback - 若使用 FormData 提交，
disabled项天然被排除，无需额外过滤
为什么用 disabled 而不是隐藏或移除 DOM？
隐藏（display: none）或移除节点看似更“彻底”，但会破坏表单结构完整性，导致：
- label 关联失效（
<label for="xxx"></label>指向的 ID 不存在） - 屏幕阅读器无法感知原选项存在，降低可访问性
- 用户刷新页面后，原本“禁用但可见”的提示信息丢失，造成困惑
- 权限恢复时需重新插入 DOM，逻辑更重
disabled 是唯一同时满足：语义清晰、提交安全、可访问、易维护 的方案。真正要警惕的，是把它和“视觉隐藏”混为一谈——禁用项必须保持可见、可读、有明确灰度样式，这是权限告知的一部分。
