Electron中font-smooth和-webkit-font-smoothing基本无效：前者已废弃被Chromium忽略；后者仅限macOS WebKit生效，而Electron使用Blink内核且受系统策略压制，Windows/Linux完全不支持。
为什么 Electron 里 font-smooth 和 -webkit-font-smoothing 大概率没用
这两个属性在 Electron 渲染进程里基本属于“写上去就失效”的典型。font-smooth 是 CSS 标准中已废弃的属性，所有现代 Chromium 版本（包括 Electron 当前主流 v28–v32）都忽略它。-webkit-font-smoothing 看似有戏，但它只在 macOS 的 WebKit 渲染路径下生效——而 Electron 用的是 Blink 内核，且从 Chrome v110+ 起，子像素抗锯齿默认被系统策略压制，即使写了 subpixel-antialiased，也可能被静默覆盖。Windows 和 Linux 完全不认这个属性，写了等于白写。
真正可控的跨平台字体渲染控制点
别再盯着 -webkit-font-smoothing 打转，Electron 桌面端能稳定干预的只有三个地方：
-
text-rendering：设为optimizeLegibility（macOS/Chromium 有效，激活连字和字距微调）或geometricPrecision（Windows 下更稳，避免 ClearType 行高错位） -
font-feature-settings：显式启用"liga"、"kern"等 OpenType 特性，前提是字体本身支持（如思源黑体、霞鹜文楷） -
font-display：在@font-face中设为swap，防止 FOIT 导致 fallback 字体闪动，间接维持平滑感连续性
注意：font-display: optional 在 Electron 中风险高，容易因加载时机问题触发二次重排，文字发虚。
鸿蒙 PC / Windows / macOS 三端的字体平滑适配差异
鸿蒙 PC 和 Windows 都依赖系统级光栅化（HarmonyOS 的 ArkUI 渲染器、Windows 的 DirectWrite），它们对 line-height 和 font-size 的微小偏差更敏感；macOS 则更吃 text-rendering 和子像素逻辑。所以不能一套 CSS 打天下：
立即学习“前端免费学习笔记（深入）”；
- 鸿蒙 PC & Windows：优先保障
line-height: 1.4~1.45，避免小字号下文字被 ClearType 压扁；禁用-webkit-font-smoothing - macOS：可加
-webkit-font-smoothing: subpixel-antialiased+text-rendering: optimizeLegibility，但必须放在全局body或html规则里，且不能被后续样式覆盖 - 所有平台：系统字体栈末尾必须保留
sans-serif（不加引号），否则 fallback 链断裂，字体直接变方块
SCSS 混合宏封装时最容易漏掉的关键点
用 SCSS 封装跨平台字体平滑样式时，开发者常以为只要写个 @mixin font-smooth($os) 就完事。实际落地要多想一层：
- SCSS 编译期无法探测运行时 OS，所以
$os必须由构建脚本或环境变量注入，不能硬编码 - 鸿蒙 PC 不是 macOS，
-apple-system在鸿蒙上无效，应改用"HarmonyOS Sans"并确保该字体已本地化部署（不能只靠 CDN） - 所有自定义字体的
@font-face规则，必须放在系统字体栈之后、text-rendering设置之前，否则字体加载完成前的 fallback 阶段会跳过优化设置 - 不要在 JS 中动态改
document.documentElement.style.fontSize来做缩放适配——Electron 主进程广播的 DPI 变更事件比 JS 读取window.devicePixelRatio更可靠
最常被忽略的是：字体平滑不是“开了某个开关就自动变好”，而是系统字体栈、OpenType 特性、加载策略、行高节奏四者咬合的结果。少一环，文字就发虚、发胖或边缘带彩边。
