页面加载时让单选按钮默认选中，唯一可靠方式是在HTML中直接添加checked属性；浏览器仅检测该属性是否存在，不关心其值，且同name组中仅首个checked生效。
直接加 checked 属性是唯一可靠方式
页面加载时想让某个单选按钮默认被选中，必须在对应 标签里写上 checked 属性。浏览器只看这个属性是否存在，不关心它的值——哪怕写成 checked="false" 或 checked=""，照样被当成已选中。
常见错误现象：checked="true" 看起来“更合理”，但其实是冗余写法；用 JS 在 DOMContentLoaded 之后才设置 element.checked = true，无法改变初始状态，只能影响后续交互。
-
✅ 正确且最简 -
✅ 合法但没必要 -
❌ 依然被选中，误导性强
同一 name 组里只能有一个 checked
同名单选按钮构成互斥组，HTML 允许多个 checked 并存，但浏览器只认第一个出现的，后面的会被忽略。这容易导致模板渲染或服务端拼接时逻辑出错：比如条件判断没兜底，两个选项都加了 checked，结果用户看到的是第一个，但开发者以为第二个生效了。
使用场景：后端模板（如 Jinja、EJS）里常用 {{ if user.level === 'pro' }}checked{{ end }} 这类写法，务必确保分支互斥；前端框架如 React 中应避免手写 checked，改用 defaultChecked 配合受控逻辑。
- name 值大小写敏感，
name="Color"和name="color"是两组 - 若整个组都没写
checked，页面加载后将无任何选项被选中（表单提交时该字段不会发送） - Vue 中用
v-model时，绑定变量的初始值必须匹配某个value，否则所有项都显示未选中
别指望 CSS 或 JS 替代 checked 属性
:checked 伪类只反映当前选中状态，:default 才能匹配初始默认项，但兼容性有限（IE 不支持）；仅靠 JS 设置 .checked = true 不会触发 change 事件，依赖事件驱动的校验或联动逻辑会失效。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
性能与兼容性影响：纯 HTML 的 checked 属性在所有浏览器中行为一致，无需 polyfill；而用 JS 模拟“默认选中”需等待 DOM 就绪，还可能被服务端渲染（SSR）和客户端 hydration 冲突导致闪烁。
- 要触发事件，得手动
element.dispatchEvent(new Event('change', { bubbles: true })) - 更稳妥的做法是调用
element.click()，它既设状态又发事件，但注意元素必须已挂载到文档中 - 不要混用
defaultChecked和checked：前者只在首次渲染起作用，后者会强制覆盖，容易引发竞态
label 和可访问性不能省
单放一个 不仅难点击，还会让屏幕阅读器无法关联文字说明。必须用 包裹，或通过 for 和 id 显式关联。
容易踩的坑：label 的 for 值和 input 的 id 不一致；input 缺少 id 却写了 for；多个 radio 共用同一个 id（违反 HTML 规范）。
-
✅ 推荐，简洁安全 -
✅ 可行，但需确保id唯一 - 别把
checked加在 label 上——它对 input 无效
实际开发中最容易被忽略的点，是服务端渲染和客户端逻辑对 checked 的处理不一致，尤其是 SSR + hydration 场景下，初始 HTML 里的 checked 必须和服务端数据完全匹配，否则 React/Vue 会降级为客户端接管，造成状态错乱或 UI 闪烁。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
