chrome/firefox中text-shadow描边发虚是因多层阴影逐层光栅化导致亚像素渲染不一致；应仅用4个整数像素方向阴影（上/下/左/右），模糊值为0，避免斜向和小数偏移。
text-shadow描边在Chrome/Firefox中发虚怎么办
直接用 text-shadow 做描边，常在Chrome里看着模糊、边缘毛糙，Firefox反而更清晰——这不是你显示器问题，是浏览器对多层 text-shadow 的亚像素渲染策略不同导致的。核心矛盾在于：描边本质是“用阴影模拟轮廓”，但浏览器不会把多个 text-shadow 当作一个矢量路径来抗锯齿，而是逐层叠加光栅化结果。
实操上最稳的解法是控制层数和偏移量：
- 只用 4个方向 的
text-shadow（上、下、左、右），别加斜角（如1px 1px 0 #000），斜向阴影会加剧错位和半透明重叠 - 所有偏移必须是整数像素，例如
1px 0 0 #000, 0 1px 0 #000, -1px 0 0 #000, 0 -1px 0 #000；小数（如0.5px）在缩放或高DPI屏下必然糊 - 模糊值（第三个参数）必须为
0，哪怕只是0.1px也会触发高斯模糊，彻底破坏边缘锐度
描边颜色比预期浅，尤其是浅色文字配深色背景
这是叠加顺序和透明度叠加的副作用。4个 text-shadow 在交角处（比如字符右上角）会叠加两次，导致颜色变深；而正上方/正左方只叠加一次，看起来就浅。人眼会把这种不均匀感知为“描边断开”或“颜色不一致”。
解决不是靠调 opacity，而是重构描边逻辑：
- 改用
text-shadow: 0 0 0 #000配合-webkit-text-stroke（仅WebKit内核生效），但注意它不支持渐变描边，且IE/Edge全不支持 - 更通用的做法：用两层文字叠在一起，底层放大1px并填描边色，顶层正常大小填主色，用
z-index或position: relative控制层级 —— 这样描边是完整闭合的矢量轮廓，天然抗锯齿 - 如果必须用
text-shadow，就把4个方向的描边色稍微调深一点（比如主色是#333，描边用#111），靠视觉补偿不均匀叠加
移动端iOS Safari描边突然消失或错位
iOS 15+ 的 Safari 对 text-shadow 的硬件加速策略变了，当文字有 transform、scale 或页面启用了 will-change 时，多层阴影可能被合并或裁剪。现象是描边只剩两条边，或者整体偏移几个像素。
排查和修复要点：
- 检查是否对文字容器设置了
transform: translateZ(0)或will-change: transform，临时去掉就能验证是不是这个原因 - 避免在
@media查询里动态切换text-shadow值，iOS Safari 对媒体查询内的阴影重绘有延迟，容易闪一下再消失 - 真机调试时，打开 Web Inspector → Elements → Styles，手动删掉其他 CSS 规则，只留
text-shadow，看是否恢复——常发现是其他规则（比如line-height微调）间接影响了基线对齐，让阴影“掉出可视区”
需要描边响应字号缩放，但em/rem单位在text-shadow里不生效
text-shadow 的偏移和模糊值不支持 em、rem、% 或 vh 单位，只能是 px、pt、cm 等绝对单位，或者 calc() 中混用（但 calc 内也不能用相对单位做偏移计算）。
这意味着：如果你用 font-size: 1.2rem，想让描边始终是字号的 1/12，不能写 text-shadow: 0.0833rem 0 0 #000 —— 浏览器直接忽略。
可行方案只有两个：
- 用 JS 监听
font-size变化，动态计算像素值并写入style.textShadow，适合关键标题等少量元素 - 放弃纯 CSS，改用 SVG
<text></text>+stroke属性，它原生支持stroke-width: 0.1em，且完美继承父级字号缩放，兼容性到 IE9+
描边这事，表面是加一圈颜色，背后全是渲染管线的妥协。最稳的永远是少依赖、少叠加、盯死像素值——毕竟抗锯齿不是CSS能开关的开关，而是浏览器在有限信息下做的最优猜测。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
