应使用数值写法（如900）替代bold，因数值更精准可控，可突破字体仅支持400/700的限制，实现更强加粗；但前提是字体文件必须包含对应字重，否则浏览器将降级显示。
font-weight 数值写法比 bold 更可靠
直接写 font-weight: bold 看似简单，但实际效果受限于字体本身是否提供真正的 bold 字重。很多系统字体（如 Windows 的微软雅黑、macOS 的 -apple-system）只内置 400 和 700 两级，bold 就是 700，再没更粗的选项。而用数值能明确表达意图，也方便后续扩展——比如想比 bold 还粗一点，font-weight: 800 或 900 就是唯一出路。
常见误区：
-
font-weight: "bold"加了引号 → 语法错误，浏览器忽略该声明 -
font-weight: bolder嵌套多层后不可控 → 它不固定，依赖父元素当前值，父是 400 时它变 700，父是 700 时它可能卡在 700 不动（因字体无 800） -
font-weight: 650→ 非整百数，所有浏览器都当无效值处理，静默 fallback 到 600 或 700
字体支持决定 font-weight 实际效果
font-weight: 900 写得再对，如果当前字体文件没打包 900 字重，浏览器就自动降级到最近可用值（比如 700），且不报错、不提示。你在 DevTools 的 Computed 面板里看到的解析值才是真实生效的字重。
验证和应对方式：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用 Google Fonts 时，必须显式加载对应字重链接，例如
https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;700;900，漏掉900就用不上 - 自定义字体用
@font-face时，font-weight声明必须与实际 .woff2 文件的元数据一致，否则浏览器无法匹配 - 可调用
document.fonts.check('900 Roboto')在运行时判断是否加载成功（注意：需等字体加载完成后再查）
font-weight 在 a 标签或内联元素上容易失效
超链接 <a> 默认没有加粗，但设了 font-weight: 700 却没反应？大概率是被用户代理样式或更高优先级规则覆盖了。Chrome/Firefox 对 <a> 的默认 font-weight 是 400，但某些 UI 框架（如 Bootstrap）会全局重置为 normal，导致你的声明被压制。
排查要点：
- 打开 DevTools → Elements → 右侧 Styles 面板，看
font-weight是否被划掉（strikethrough），被划掉说明有更高优先级规则在起作用 - 检查是否用了
!important—— 它能强制生效，但掩盖了真正的问题来源 - 确认选择器权重足够：比如
a.bold-link比a更高，.nav a又比单独a高
Windows 下 font-weight 渲染发虚的根本原因
文字加粗后边缘模糊、有毛边，尤其在 Chrome + Windows 组合下高频出现。这不是 CSS 写错了，而是浏览器在找不到对应字重时，用算法“fake bold”强行加粗：横向拉伸笔画，破坏字体 hinting 信息，导致抗锯齿失真。
真正有效的解法只有两个：
- 确保字体文件包含你要的字重（如 Roboto 900、Inter 800），并用
@font-face或 Google Fonts 正确加载 - 启用可变字体（variable fonts）：用
font-weight: 100 900范围声明，配合支持的字体（如font-family: 'Inter', sans-serif），就能平滑调节，避免 fake bold
别用 text-shadow 或 -webkit-font-smoothing 补救——前者加重模糊，后者影响整块文本清晰度，治标不治本。
