必须配才生效，仅设table-layout: fixed无效；浏览器仍扫描所有推导列宽，textarea输入触发强制同步布局导致卡顿。

表格里 <textarea></textarea> 输入卡顿，不是 textarea 本身慢，而是它被套在大量 <tr> 和 <code><td> 里，每次输入都触发强制同步布局（layout thrashing）——尤其当表格已启用 <code>table-layout: fixed 却没配 <col>，或父容器有动态计算高度逻辑时。

为什么 <textarea></textarea> 在表格里一输就卡

常见错误现象：光标闪烁延迟、回车换行后页面微顿、Chrome 控制台频繁报 “Layout Thrashing” 警告。根本原因不是 textarea 性能差，而是浏览器在每次输入后，试图重新测量整个表格的列宽、行高、滚动偏移，甚至触发 getBoundingClientRect() 类同步读取 —— 这些操作若发生在事件回调里，就会形成“读-写-再读”的恶性循环。

• 表格用了 table-layout: fixed 但没写 <col>：浏览器仍要扫描所有 <td> 内容推导列宽，<code><textarea></textarea> 的 resize 或 focus 会反复触发该过程
• <textarea></textarea> 父 <td> 设置了 <code>width: auto 或 min-width: fit-content：每次内容变化都强制重排整行
• 监听了 input 事件并同步调用 el.scrollHeight + el.style.height 做自适应：这是最典型的 layout thrashing 场景
• 表格外层容器用了 height: 100% + overflow-y: auto，但没设固定 max-height：textarea 高度变化会间接影响滚动容器尺寸，引发级联重排

<textarea></textarea> 自适应高度别在 input 里同步算

想让 <textarea></textarea> 随内容撑开？别在 input 回调里立刻读写 height。浏览器还没完成本次渲染帧，你又去读 scrollHeight，它只能强行同步重排。

• 把读取和写入拆到不同帧：requestAnimationFrame(() => { const h = el.scrollHeight; el.style.height = h + 'px'; })
• 更稳的做法：用 resize-observer-polyfill 监听 <textarea></textarea> 尺寸变化，而非依赖内容输入事件
• 如果必须响应输入，加简单防抖（200ms），但注意中文输入法场景：需监听 compositionstart/compositionend，只在 compositionend 后执行 resize 逻辑
• 禁用 overflow: auto 和 resize: both —— 它们会让浏览器对 textarea 做额外布局探测

表格结构本身就在拖慢 textarea 响应

即使单个 <textarea></textarea> 没问题，套在超大表格里也会被拖累。关键不是删掉它，而是切断它和表格布局的耦合链。


htmlppt.skill
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
下载

立即学习“前端免费学习笔记（深入）”；

• 确保表格已正确启用 table-layout: fixed + 显式 <col>：例如 <col width="200"> <col width="auto"> <col width="120">；width="auto" 只能出现在一列，否则 fixed 失效
• <textarea></textarea> 所在 <td> 不要设 <code>vertical-align: middle 或 padding 百分比值：这些会触发行高重算
• 避免在 <tbody> 外层再套一层 <code>div 并设 height: 100%：这会让浏览器把整个表格当 flex item 或 grid item 处理，textarea 变化会触发父容器重排
• 如果表格行数 > 200，直接上虚拟滚动（如 virtuoso）：真实 DOM 里只剩视口内 ±20 行，<textarea></textarea> 不再参与全局布局计算

服务端返回带 textarea 的表格时，前端别做错三件事

后端吐出 JSON 后，前端拼接 HTML 渲染表格，这时最容易埋下卡顿隐患。

• 禁用 innerHTML = '<tr>...</tr>' 拼接含 <textarea></textarea> 的行：字符串解析 + DOM 构建 + layout 计算全挤在一次任务里，主线程直接冻结
• 清空 <tbody> 后，用 <code>DocumentFragment 批量插入，而不是循环 appendChild：后者每插一行都可能触发一次重排
• 不要给每个 <textarea></textarea> 绑独立 input 监听器：用事件委托挂到 <tbody> 上，再用 <code>e.target.matches('textarea[data-field="note"]') 精确匹配

  最常被忽略的是：textarea 卡顿往往不是它自己写的逻辑有问题，而是表格的列宽未固化、父容器高度未锁定、或监听器绑在了错误层级——这些问题在 50 行表格里不显，在 2000 行表格里就是秒级卡顿。