在表格中性能差源于DOM爆炸、样式计算失控和事件监听泛滥；应禁用自动高度、延迟渲染、事件委托并收敛监听。
表格里塞 <textarea></textarea> 不是慢在文本域本身，而是它触发的三重连锁反应：DOM 节点爆炸、样式计算失控、JS 事件监听泛滥。尤其当每行都带一个可编辑 <textarea></textarea>，200 行起步就卡得明显。
为什么 <textarea></textarea> 在表格里特别拖累首屏
常见错误现象：滚动卡顿、输入延迟、点击聚焦后页面抖动、Chrome 控制台频繁报 Layout Thrashing。根本不是 <textarea></textarea> 渲染慢，而是你让浏览器反复做三件事：
- 每新增一个
<textarea></textarea>，浏览器就得重新计算其scrollHeight、clientWidth等布局属性（尤其当没设rows或用了style.height: auto） - 表格用了
table-layout: auto（默认值），浏览器必须逐行扫描所有<textarea></textarea>内容长度来算列宽——500 行 × 1 个<textarea></textarea>就能卡主线程 100ms+ - 给每个
<textarea></textarea>绑oninput或onChange，没防抖/节流，输入时触发高频重排+状态更新
必须关闭自动高度，显式控制 <textarea></textarea> 尺寸
<textarea></textarea> 默认会随内容撑高，但在表格里这是性能毒药。它让浏览器无法预估行高，进而破坏 table-layout: fixed 的加速效果，也导致虚拟滚动无法精准占位。
- 一律写死
rows="3"，禁用style.height: auto或style.min-height - 配合 CSS 锁定尺寸：
textarea { resize: none; overflow-y: auto; height: calc(1.2em * 3); } - 若需“展开”交互，用 JS 切换 class 控制
height和overflow，而不是靠内容撑开
别让每个 <textarea></textarea> 都立即渲染
真实场景中，95% 的 <textarea></textarea> 首屏根本不需要可编辑——它们只是待填写字段。直接全量渲染等于主动制造 DOM 压力。
立即学习“前端免费学习笔记（深入）”；
- 初始只渲染
<div contenteditable="false">xxx</div>或纯文本<span></span>，点击单元格再动态替换成<textarea></textarea> - 用
DocumentFragment批量替换，避免单个replaceChild触发多次回流 - 若用虚拟滚动（如
virtuoso），确保<textarea></textarea>只在聚焦态才挂载，失焦立刻卸载或退化为只读
事件监听必须收敛，不能每个实例绑一份
200 行表格绑 200 个 oninput，不是内存问题，是事件调度开销：每次输入都要走完整事件冒泡路径，再触发 200 次回调判断逻辑。
- 用事件委托：监听
tbody，通过event.target.matches('textarea')分发 -
oninput回调里加requestIdleCallback或简单节流（setTimeout(..., 300)），避免实时响应 - 禁用
spellcheck="false"和autocomplete="off"，这两项在大量<textarea></textarea>下会额外触发词典匹配和表单历史查询
最易被忽略的一点：表格里 <textarea></textarea> 的 name 属性若带动态索引（如 name="item[123].desc"），序列化时会触发全量 DOM 遍历——别用 form.querySelectorAll('textarea') 收集，改用维护好的数据数组映射。
