text-rendering: optimizeLegibility 是最实用的值，它在 Chrome、Firefox、Safari（macOS）上稳定生效，启用字距调整和连字，对小字号中英文标题、代码注释等提升清晰度；但依赖高质量 OpenType 字体，需避免全局滥用和小数像素混用。
text-rendering: optimizeLegibility 是最实用的值
绝大多数需要提升文字清晰度的场景，直接用 text-rendering: optimizeLegibility; 就行。它在 Chrome、Firefox、Safari（macOS）上都稳定生效，会启用字距调整（kerning）和连字（ligatures），对小字号中文、英文标题、代码注释等特别有用——比如 14px 的 .gr-textbox 或 .markdown-body 里，文字边缘更锐利，字符间距更自然。
但注意：这个值对字体有依赖。像 'Microsoft YaHei'、'Source Han Sans CN'、'Noto Sans CJK SC' 这类带完整 OpenType 特性的中文字体效果明显；而系统 fallback 的 sans-serif 可能毫无变化。
- 别在全局
body上无差别加，优先作用于关键文本容器（如输入框、标题、Markdown 渲染区） - 避免和
font-size小数像素混用（如13.5px），否则连字可能被浏览器跳过 - Mac 上若发现字体“发胖”，需配合
-webkit-font-smoothing: antialiased;
optimizeSpeed 基本可以忽略
text-rendering: optimizeSpeed; 在现代 HTML 页面中几乎无效。Chrome 和 Edge 完全无视它，等同于 auto；Firefox 仅在 SVG 文本中部分响应；Safari 直接回退到 auto。它本意是禁用连字和字距来提速，但实际不触发任何优化逻辑。
真要优化性能，该动的是字体加载环节：font-display: swap 能防止 FOIT（空白闪动），让系统字体先顶上；而 @font-face 中配 font-display: optional 反而容易白屏——这比硬塞一个失效的 optimizeSpeed 危险得多。
立即学习“前端免费学习笔记（深入）”；
兼容性与渲染链路比单个属性更重要
文字模糊从来不是 text-rendering 没设对的问题，而是整条链路断了：Linux 服务器没装中文字体 → 浏览器 fallback 到无中文支持的拉丁字体 → 显示方块；高分屏 DPI 缩放未校准 → 字形被非整数缩放拉伸；GPU 加速异常 → 抗锯齿策略错乱。
所以必须同步检查：
- 是否显式声明中文字体栈，例如
font-family: 'Noto Sans CJK SC', 'PingFang SC', sans-serif; - 是否关闭编辑器或 IDE 的自动 DPI 缩放（尤其 VS Code、JetBrains 系列）
- 是否在系统级调优字体渲染：Windows 启用 ClearType，macOS 关闭“字体平滑”选项，Linux 配置
fonts.conf - 是否误启用了
transform: translateZ(0)类 GPU 强制加速——它可能干扰亚像素渲染，反而让文字变虚
中文场景下容易被忽略的关键点
中文不像英文有明确连字需求，optimizeLegibility 的主要价值其实是激活高质量字体的 hinting 和字偶距数据。但很多开发者卡在第一步：没确认最终渲染的到底是哪个字体。
打开浏览器 DevTools → Elements → 计算样式 → 找 font-family 实际值，常会看到 fallback 成 "DejaVu Sans" 或 "Liberation Sans" ——这些字体根本不含中文 glyph，自然糊成一片。此时加十遍 text-rendering 都没用。
真正要做的，是在部署环境预装中文字体包（如 Ubuntu 的 fonts-wqy-zenhei），或通过 @font-face 内联 WOFF2 字体，并确保 font-display: swap + unicode-range 分段加载。
