表格和文本域的“自适应”需满足硬性前提：table须父容器有明确宽度+width:100%+table-layout:fixed+正确；textarea须每次先设height:auto+requestAnimationFrame+换行符归一化+box-sizing:border-box。

直接说结论：表格和文本域的“自适应”不是靠写个 width="100%" 或 style="height: auto" 就能成的；它们各自有不可绕过的硬性前提，混用时冲突更明显。

Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转

实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。

下载

为什么 table 的 width="100%" 总是不生效

浏览器默认按内容撑开 <table>，<code>width: 100% 不是“继承父宽”，而是“在父宽基础上计算”——但若父容器没设宽度（比如 <div> 没写 <code>width），这个百分比就失去参照，退化为 auto。

• 父容器必须有明确宽度：如 style="width: 100%"、max-width: 768px 或固定像素值
• <table> 必须同时声明 <code>width: 100% 和 table-layout: fixed，缺一不可
• <col> 必须紧接在 <table> 开始标签后、<code><thead> 前，且单位只支持 <code>px、%、em（不支持 fr）
• 漏掉 <col> 或放错位置（比如塞进 <thead> 里），列宽就会 fallback 到第一行单元格的 <code>width，甚至坍缩成最小内容宽

  为什么 textarea 自适应高度总卡住或越撑越高

  常见错误是跳过重置步骤。一旦之前设过固定 height（比如上一次输入留下的 200px），浏览器就会把它当约束条件，导致 scrollHeight 计算偏小——尤其在 iOS Safari 和 IE11 上更明显。

  • 每次触发前必须加 textarea.style.height = 'auto'，让元素回归自然流式计算逻辑
  • iOS Safari 对 scrollHeight 更新有微小延迟，必须用 requestAnimationFrame 包一层，比 setTimeout(, 0) 更稳
  • IE11 把 \r\n 当一个字符算，而现代浏览器统一按 \n 处理，导致空行末尾的 scrollHeight 偏小 1 行；可做换行符归一化：textarea.value = textarea.value.replace(/\r\n/g, '\n')
  • offsetHeight 和 clientHeight 永远不准，它们不含溢出区域，不能替代 scrollHeight

  table 和 textarea 共存时最容易被忽略的样式脱节点

  scrollHeight 的值依赖真实渲染高度，所有影响高度的样式（padding、border、line-height、字体）必须和 JS 计算时完全一致，否则结果偏差肉眼可见。

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

  • CSS 必须显式写 box-sizing: border-box，确保 padding 和 border 不额外增加高度
  • min-height 和 max-height 必须走 CSS 控制：光靠 JS 算高度不行，否则空 textarea 会塌成一条线，或用户狂输时无限制拉伸
  • 别用 height: 100% 或 flex: 1 直接套在 textarea 上——它会和 JS 高度冲突
  • 表格内嵌 textarea 时，td 的 padding 和 vertical-align 会影响其内部定位；不要设 height 在 tr 或 td 上，改用 padding 控制视觉留白

  最常翻车的不是代码怎么写，而是忘了父容器有没有宽度、table-layout 没设、<col> 放错位置，以及 textarea 没重置 height 就读 scrollHeight——这四点，任一缺失都会让“自适应”变成“半吊子自适应”。