::first-line 样式会随缩放、字体加载、DOM 更新等动态重算首行，非 bug 而是设计使然；它绑定当前渲染的第一行，不固定字符范围，无法用 CSS 阻止重算，稳定控制需手动包裹 span。
缩放时::first-line样式会“跳”到不同文字上
它不是 bug，是设计使然。::first-line 永远绑定「当前视口下浏览器实际渲染出的第一行」，不是固定字符范围。窗口缩放、字体加载完成、甚至 font-size 动态变化，都可能让原本在第二行开头的字被挤进首行，样式立刻应用过去。
常见现象：一段文字在 100% 缩放时首行显示 8 个字，放大到 125% 后变成 6 个字，加粗效果就突然“少掉”最后两个字；或者响应式断点切换后，max-width 改变导致整段重排，首行内容完全不一样。
- 这不是样式丢失，而是选择目标动态更新了
- 无法通过 CSS 阻止这种重算——它是 layout 阶段的自然结果
- 若需稳定控制前 N 字，必须放弃 ::first-line，改用手动包裹
<span class="lead"></span>
::first-line 不响应 JS 插入或 Vue/React 更新后的首行重排
DOM 内容变了，但浏览器不会自动重新触发 ::first-line 的布局锚点计算。比如用 innerHTML 替换段落文本，或 React 中 useState 更新 p 的 children，首行样式仍按旧 DOM 快照渲染，直到下一次强制 layout（如 resize、scroll、或修改 font-size）。
- 临时修复：插入内容后，给元素加一个 class 切换（哪怕只是
force-repaint→ 移除），或短暂设font-size: calc(1em + 1px)再还原 - Vue 用户可配合
nextTick+getComputedStyle触发重排，但别在循环中滥用 - 真正稳定的方案是避免依赖 ::first-line 做关键视觉表达——比如首行背景色用于强调，不如用
text-indent+border-left组合更可控
移动端双指缩放或字体加载延迟导致首行错位
移动 Safari 和部分安卓 WebView 在双指 pinch-zoom 时，不触发完整的 layout 重排，::first-line 可能卡在旧位置；而自定义字体（尤其未设 font-display: swap）加载延迟，会让首行先按 fallback 字体折行，等新字体加载完再重排，造成样式“闪动”或错位。
立即学习“前端免费学习笔记（深入）”；
- 强制启用重排：监听
resize和fontface-load（需document.fonts.load配合），然后对目标段落 toggle 一个无样式的 class - 规避字体问题：所有用 ::first-line 的段落，统一加
font-display: optional或至少swap，减少等待时间 - 慎用
background-color：它在字体切换或缩放过程中容易出现半行渲染、边缘断裂，优先用color+font-weight
为什么 text-indent 不会影响 ::first-line 的选取范围
text-indent 是作用于整个块容器的属性，它只控制第一行开头的空白宽度，并不改变「哪些字符属于首行」的计算逻辑。::first-line 依然按实际换行位置截取字符，哪怕首行开头有 2em 空白，它也从第一个可见字符开始选中到换行点。
- 所以写
p::first-line { color: red; }+p { text-indent: 2em; }，缩进空格本身没颜色，但后面的文字会红 - 误判“没生效”，常是因为缩进太大，首行只剩空白或半个标点——检查是否真有可见文本参与首行
- 想让缩进区域也有样式？不行。::first-line 不覆盖不可见内容，也不支持伪元素嵌套
