万级列表中使用原生radio/checkbox会卡死，因DOM节点超限、样式计算开销大、事件钩子膨胀；虚拟滚动需手动管理状态；radio同名组引发O(n)广播；应禁用id/aria-labelledby等隐性性能陷阱。
为什么万级列表里放<input type="radio">或<input type="checkbox">会卡死
因为每个单选/复选框都是独立DOM节点，且默认不参与浏览器的批量优化。10000行 × 每行至少2个表单控件 → 2万个以上input节点，直接触发三重压力：
- DOM树体积爆炸：Chrome对单页DOM节点数的安全阈值约8000–10000，超限后解析和挂载时间呈非线性增长
- 样式计算开销翻倍：每个
input都要计算伪类:checked、:disabled状态，而状态变更会强制重排（reflow）整行甚至整表 - 事件监听器隐式膨胀：哪怕你只给
tbody绑一个委托事件，浏览器内部仍需为每个input维护焦点、输入、变更等原生钩子
实测中，未做任何处理的10000行带checkbox表格，首次渲染耗时达3.7秒，滚动时FPS跌破8；Radio组更糟——同一name下所有节点在状态切换时会互相通知，形成O(n)广播行为。
type="checkbox"在虚拟滚动中必须手动管理checked状态
虚拟滚动只渲染视口内约20–50行，但用户勾选可能发生在任意行。若不持久化状态，一滚动就丢失已选结果。
- 不能依赖
input.checked = true写死：滚动后DOM被回收，该属性失效 - 必须用外部数据结构记录，例如
const selectedIds = new Set()或const selectionMap = new Map<string, boolean>() - 每次渲染某行时，要从该数据结构查状态并显式设置
input.checked，否则视觉不同步 - 别用
document.querySelectorAll('input:checked')取当前选中项——它只返回现存DOM里的节点，漏掉已滚出视口但逻辑上仍应选中的项
示例关键逻辑：
function renderRow(rowData) {<br> const input = document.createElement('input');<br> input.type = 'checkbox';<br> input.checked = selectedIds.has(rowData.id); // 从外部状态读，不读DOM<br> input.addEventListener('change', () => {<br> if (input.checked) selectedIds.add(rowData.id);<br> else selectedIds.delete(rowData.id);<br> });<br> return input;<br>}
立即学习“前端免费学习笔记（深入）”；
type="radio"组名相同导致的性能雪崩比想象中严重
同name的radio在浏览器内构成一个互斥组，每次任一控件状态变化，引擎都会遍历全部同名节点执行校验与同步。万级列表里若全用name="row-select"，一次点击就触发10000次遍历。
- 解决方案不是“换名字”，而是彻底放弃原生radio语义：改用
type="checkbox"+ 单选逻辑模拟（如点击时先清空selectedId再赋新值） - 如果必须用原生
radio，务必确保每组只含1–3个选项（如“操作列”里的“编辑/删除/查看”），且name按功能区分，绝不用全局统一name - 禁用
radio的autofocus或required——它们会额外触发验证流程，加剧主线程阻塞
Chrome DevTools 的 **Performance** 面板里，这类问题常表现为长任务中出现大量Update radio group state条目，单次耗时可达40ms以上。
不要给每个input加id或aria-labelledby
看似可访问性友好，实则制造隐性性能陷阱：
-
id属性本身不慢，但一旦搭配label[for="xxx"]，浏览器就必须建立ID索引映射表，10000个id会让该哈希表扩容数十次 -
aria-labelledby强制触发无障碍树重建，每次滚动新增/移除一批input，都会引发完整a11y树重算 - 替代方案更轻量：用
<label><input>文本</label>包裹结构，无需id即可绑定；或用aria-hidden="true"隐藏纯操作型复选框（如“全选”列），仅保留主数据列的语义
真正容易被忽略的是：这些属性在开发期完全无感，上线后用户量上来、低端设备增多，才集中暴露为“点不动”“滚动断帧”——而排查时往往先怀疑网络或后端，没人想到是id="cb-5823"惹的祸。
