textcontent 更适合统计 html 字数，因其自动剥离标签返回可见纯文本，但需清洗不可见字符；应避免 innertext（受 css 影响、触发重排）和 innerhtml（含标签字符），并注意 unicode 字符、兼容性及输入源归一化处理。
为什么 textContent 比 innerHTML 更适合统计 HTML 字数
直接用 innerHTML 取内容再算长度，会把所有标签字符（如 <div>、<code>）全算进去，结果远大于用户实际看到的字数。而 textContent 自动剥离标签，只返回渲染后可见的纯文本内容，这才是“真实字数”的基础。
但要注意：它也会带入不可见字符（如换行、多个空格、 ），所以后续必须清洗。
- 如果页面含富文本编辑器输出（如 TinyMCE、Quill），优先取其提供的纯文本 API，而不是自己扒 DOM
-
textContent不解析 HTML 实体，const temp = document.createElement('div'); temp.innerHTML = str; return temp.textContent; - 服务端渲染（SSR）或 hydrate 前，DOM 可能未就绪，需加
if (el?.textContent)防错
实时计数中如何避免频繁触发重排与卡顿
监听 input 或 keyup 时，每次回调都调 el.textContent.length 看似简单，但若节点层级深、子元素多，反复读取 textContent 会强制浏览器同步计算样式和布局，尤其在低端设备上明显掉帧。
- 用
requestIdleCallback推迟到空闲时段执行统计（兼容性差时降级为setTimeout(..., 0)） - 对富文本容器，不要监听整个
contenteditable区域的input，改用MutationObserver监听characterData和childList变化，粒度更准、触发更少 - 加防抖不是万能的——用户快速输入时可能漏统计，建议用「最小延迟 + 最大间隔」双控：比如
Math.min(100, Math.max(10, timeSinceLast))
innerText 能不能替代 textContent？
不能。虽然 innerText 也返回可视文本，但它受 CSS 影响（如 display: none、visibility: hidden 的内容不计入），且会自动折叠空白符、换行符，导致字数不稳定。更严重的是，它在某些浏览器中会触发重排（尤其是首次读取时）。
典型错误现象：innerText 在 Chrome 中返回长度忽大忽小，Vue/React 组件更新后突然少几十字——大概率是隐藏区块被动态切出又切回，innerText 忽略了它们。
- 始终用
textContent作为基准源 - 如需模拟用户“所见即所得”效果（比如忽略广告位文字），应显式用
getComputedStyle(el).display !== 'none'过滤，而非依赖innerText - IE8- 无
textContent？用innerText降级，但必须加 UA 判断，不能无差别 fallback
中文标点、emoji、全角空格怎么算一个字？
浏览器的 .length 对 emoji（如 ?）或中文标点（，。！？）都是按 UTF-16 码元计，一个 emoji 占 2 个长度，但用户感知就是一个字。若业务要求“所见字符数”，必须用 Array.from(str).length 或正则匹配 Unicode 字符。
- 简单场景用
Array.from(textContent).length，兼容性好（IE 不支持，需 Babel 转译） - 严格场景（如合同字数限制）建议用
Intl.Segmenter（Chrome 94+）：const seg = new Intl.Segmenter('zh', { granularity: 'grapheme' }); Array.from(seg.segment(text)).length - 全角空格（\u3000）、不间断空格（\u00a0）需提前替换为普通空格再统计，否则会被算作有效字符
真正难的不是取字数，而是定义“哪个字数”——编辑器里删掉一个 <img> 标签，用户没输任何字，但 textContent 长度可能变；粘贴一段带样式的 Word 内容，textContent 会丢掉格式却保留所有换行和缩进。这些边界情况，得结合具体输入源做归一化处理。
