单选按钮组需监听change事件触发保存逻辑，避免用click或input；推荐存入localStorage，页面加载时通过DOMContentLoaded读取并设置checked=true还原状态。
单选按钮组如何触发保存逻辑
HTML <input type="radio"> 本身不自带保存能力，必须监听用户选择变化后主动提交。关键不是“切换后自动保存”，而是“监听到 change 事件就立刻执行保存动作”。click 事件在部分浏览器（如 Safari 移动端）中可能触发过早（比如未真正选中前就触发），所以一律用 change。
常见错误现象：
– 页面刷新后选项恢复默认值（根本没存）
– 多个同名 radio 组只监听了第一个元素的事件（漏绑）
– 使用 input 事件——对 radio 无效
- 给整个 radio 组加一个公共容器（如
<fieldset>或带id的<div>），然后委托监听：document.getElementById('theme-group').addEventListener('change', e => { if (e.target.type === 'radio' && e.target.name === 'theme') { savePreference(e.target.value); } }); - 或者直接遍历所有同名 radio 元素并单独绑定：
document.querySelectorAll('input[name="theme"]').forEach(radio => radio.addEventListener('change', () => savePreference(radio.value)) );
保存到哪里：localStorage 是最简可行方案
除非你有后端接口或需要跨设备同步，否则别一上来就发 HTTP 请求。用户只是换了个主题色或语言，localStorage 足够、可靠、无延迟，且页面加载时可立即读取还原。
容易踩的坑：
– 直接存 e.target 对象（会报错，因为不能序列化 DOM 节点）
– 忘记处理 null 或空字符串（比如用户清空了所有 radio 的 checked 状态）
– 键名写死但和其他功能冲突（如都用 'theme'）
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 保存时只存
value字符串：function savePreference(value) { localStorage.setItem('user-theme-preference', value); } - 读取时做存在性判断，避免
getItem返回null导致后续出错：const saved = localStorage.getItem('user-theme-preference'); if (saved) { document.querySelector(`input[name="theme"][value="${saved}"]`).checked = true; }
页面加载时如何还原选中状态
还原不是“设置 checked 属性”，而是设置 checked **属性**（setAttribute('checked', '')）或更稳妥地赋值 checked = true。仅靠 HTML 中写 checked 不行——它会被 JS 运行前的初始渲染覆盖，而 localStorage 是异步读取的，必须等 DOM 就绪后再操作。
使用场景差异：
– 如果 radio 在 <body> 底部，DOMContentLoaded 里操作没问题
– 如果是动态插入的（比如通过模板引擎或框架挂载），得确保 DOM 已真实存在
- 推荐写法（安全、不依赖 jQuery）：
document.addEventListener('DOMContentLoaded', () => { const saved = localStorage.getItem('user-theme-preference'); if (saved) { const target = document.querySelector(`input[name="theme"][value="${saved}"]`); if (target) target.checked = true; } }); - 不要用
document.write()或内联onload——不可控、难调试
为什么不用表单 submit + 后端保存
单选按钮组切换是高频、瞬时操作，submit 会整页刷新或需额外阻止默认行为，体验割裂。HTTP 请求有网络延迟、失败重试、CSRF 防护等开销，对纯前端偏好类数据属于过度设计。
例外情况只有两个：
– 该选择直接影响服务端返回内容（如语言切换需重新拉取文案）
– 产品要求所有用户行为必须落库审计（此时也建议加本地 fallback，避免网络失败导致 UI 脱节）
性能影响很实际：一次 localStorage 读写耗时通常
复杂点往往藏在边界：比如用户禁用了 localStorage、用了无痕模式、或设置了浏览器策略限制第三方脚本存储——这时候得有降级方案（例如只维持内存状态，不持久化），但那是另一层问题了。
