font-family值必须用引号包裹的情况包括：字体名含空格（如”times new roman”）、含连字符（如”segoe ui”）、中文系统字体（如”microsoft yahei”）及@font-face自定义名；sans-serif作为通用族关键字须置于链尾且不加引号，中间不可有空项。
font-family 值必须用引号包裹的几种情况
不加引号时，font-family 只会识别第一个单词，比如写 font-family: Times New Roman;，浏览器实际只读取了 Times，后面被忽略——这是最常被漏掉的坑。
以下情况必须加引号：
- 字体名含空格（如
"Times New Roman"、"Courier New"） - 字体名含连字符（如
"Segoe UI"、"Source Code Pro"） - 使用中文系统字体（如
"Microsoft YaHei"、"PingFang SC"、"Noto Sans CJK SC"） - 自定义
@font-face中声明的font-family名（哪怕没空格，也建议统一加引号避免歧义）
为什么“sans-serif”前面不能写逗号，但后面要跟它
备用字体策略的核心是「降级链」：从具体到泛化。写成 font-family: "Helvetica Neue", Arial, sans-serif; 是对的；写成 font-family: "Helvetica Neue", Arial, , sans-serif;（中间多一个逗号）会导致整个声明失效——浏览器遇到空项直接丢弃整条 font-family 声明。
关键点：
立即学习“前端免费学习笔记（深入）”；
-
sans-serif是通用字体族关键字，不是真实字体文件，它由系统决定最终渲染什么（比如 macos 用San Francisco，windows 用Segoe UI） - 它必须放在链尾，且前面**不能有空格或空项**，否则解析中断
- 不要写
"sans-serif"（带引号），那会被当成一个叫 “sans-serif” 的具体字体名去查，找不到就跳过
中文字体 fallback 链里，Windows 和 macOS 的典型顺序差异
中英文混排时，单靠一个 "PingFang SC" 在 Windows 上根本不会生效，反过来 "Microsoft YaHei" 在 macOS 上也不存在——所以 fallback 必须按平台分层写，而不是堆一堆名字指望浏览器自己挑。
常用安全链（按优先级从左到右）：
- macOS 优先：
"PingFang SC", "Hiragino Sans GB", "Heiti SC", "Noto Sans CJK SC", sans-serif - Windows 优先：
"Microsoft YaHei", "SimHei", "NSimSun", "Noto Sans CJK SC", sans-serif - 跨平台保守写法（兼顾两者）：
"PingFang SC", "Microsoft YaHei", "Hiragino Sans GB", "Noto Sans CJK SC", sans-serif
注意："SimSun"（宋体）在现代 UI 中慎用，它没有粗体变体、字重支持差，容易触发浏览器模拟加粗，导致模糊；"Noto Sans CJK SC" 是 Google 推荐的开源替代，但需自行引入 Web Font 或确认系统已预装。
font-family 设置后字体没变？先检查这三件事
常见现象是写了 font-family: "SF Pro display", sans-serif; 却还是显示默认黑体，问题往往不在声明本身。
- 检查是否被更高优先级规则覆盖（比如父元素设了
font-family: monospace;，子元素没显式重写） - 确认字体名拼写和大小写——
"SF Pro Display"不等于"sf pro display"，macOS 对大小写敏感 - 查看 DevTools 的 Computed 面板，看
font-family最终计算值是什么；如果显示为"-apple-system"，说明你用了系统字体别名，它本身不是真实字体名，而是让系统动态映射（ios/macOS 下指向SF Pro，android/Windows 下可能回退到其他字体）
系统字体别名（如 -apple-system、BlinkMacSystemFont、Segoe UI）虽方便，但它们的行为依赖运行环境，调试时不如直接写真实字体名来得可控。