作为前端开发，我们习惯了用 textContent 来获取纯文本。毕竟它性能好、不触发重排（Reflow），是 W3C 标准的亲儿子。

但今天，我在处理一个自动换行的多行文本时，被 Safari 给上了一课。

起因：消失的换行符

需求很简单：用户在一个高度自适应的 <div> 中输入或展示一段文字，我需要抓取这段文字存入数据库。

​为了追求性能，我习惯性地写下了：

const content = document.querySelector('.text-box').textContent;

在 Chrome 和 Firefox 下，一切完美。由于 CSS 设置了 white-space: pre-wrap;，我拿到的字符串里自带优雅的 \n。

然而，测试同学拿着 Safari 跑过来：“为什么存进去的数据全挤成一团了？”

破案：textContent 并不“所见即所得”

经过一番排查，我发现了这个隐藏极深的坑点：

1. textContent 的“冷酷”

textContent 获取的是 DOM 树中所有文本节点的原始数据。它根本不在乎你的 CSS 长什么样。

• 如果你的 HTML 源码里是一行，即便 CSS 用 word-break 或 white-space 让它在视觉上换了行，textContent 拿到的依然是硬邦邦的一行。

  
  

2. Safari 的“严格”

在某些特定版本的 Safari 渲染引擎中，它对 textContent 的实现非常遵循“源码原始性”。如果文本是因为容器宽度挤压产生的软换行（Soft Wrap），Safari 的 textContent 绝对不会帮你补上那个 \n。

解决方案：innerText 才是救星

这时候，那个曾经被嫌弃“性能略差”的 innerText 站了出来。

为什么这次要用 innerText？

• 感知 CSS 样式：innerText 是受 CSS 影响的。它会触发一次布局计算，获取用户肉眼看到的文本形态。

• 自动转换换行：如果你的元素里有 <br>，或者因为 white-space: pre-wrap 产生了视觉换行，innerText 会非常贴心地在对应位置插入 \n。

代码修正：

// ❌ 坑点代码（Safari 下可能丢失换行）

// const text = el.textContent;


// ✅ 避坑代码（所见即所得，保留视觉换行）
const text = el.innerText;

总结：避坑指南

这次折腾让我记住了两点：

1. 如果你要的是“源码里的字”：选 textContent，它快且稳，不理会 CSS。

2. 如果你要的是“屏幕上的字”：特别是涉及**换行、空格、大小写转换（text-transform）**时，请务必果断使用 innerText。

   
   

前端无小事，永远不要低估 Safari 的“独特性”。 以后看到文本抓取需求，还是先老老实实测一下兼容性吧！

📝 避坑速查表

 

参考文章：原文链接