安卓 font-weight 加粗失效是因系统字体仅含 regular 字重，只能描边模拟；iOS 的 San Francisco 支持全字重真调用。需引入多字重 Web Font 并显式声明 font-weight 才能跨端一致。
安卓上设置 font-weight: bold 无法真实加粗中文字体，iOS 却能正常响应 —— 这不是你 CSS 写错了，是底层字体栈根本没提供对应字重。
为什么 font-weight 在安卓上“失效”
Android 原生系统字体（如思源黑体 Noto Sans CJK）在多数版本中只内置 regular（400）一个字重；当 CSS 指定 font-weight: 700 时，系统只能靠“描边+填充”模拟加粗，导致文字发虚、边缘毛糙、字形膨胀。而 iOS 的 San Francisco 字体从 iOS 9 起就完整支持 100–900 全字重，font-weight 是真调用，不是渲染补丁。
- 现象：同一段
<p style="font-weight: 700">重要提示</p>，iOS 显示锐利紧凑，安卓显示模糊臃肿 - 根源不在 CSS，而在 Android WebView 或系统 WebKit 渲染层缺乏字体文件支撑
- 华为、小米等厂商定制内核（如 X5）可能进一步屏蔽或降级字重解析逻辑
font-weight 的取值在跨端实际效果差异
不要迷信数字值 —— 安卓对 font-weight 的映射极不线性，尤其在非 400/700 整数档位上表现混乱。
-
font-weight: 500：iOS 可能渲染为轻 Bold，安卓大概率回落到 400（无变化） -
font-weight: 600：部分 Android 12+ 设备开始支持，但需搭配@font-face加载含 600 字重的 Web Font 才生效 -
font-weight: 700：最稳妥的 fallback 值，但必须配合真实 Bold 字体文件，否则仍是描边 -
font-weight: bolder/lighter：完全不可控，各平台解析逻辑不一致，生产环境禁用
真正有效的跨端字重控制方案
放弃“仅靠系统字体 + font-weight”的幻想，用可交付的字体资源兜底。
立即学习“前端免费学习笔记（深入）”；
- 优先使用系统字体栈，但明确声明 fallback 字重层级：
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;
注意：这里Roboto是 Android 推荐字体，但它本身也只带 400/500/700 三档，且 500 在旧版 Android 上常被忽略 - 关键文案（如标题、按钮）务必引入带多字重的 Web Font，例如：
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+SC:wght@300;400;500;700&display=swap');
然后显式指定：font-weight: 500;+font-family: 'Noto Sans SC', sans-serif; - 避免依赖
font-weight做视觉层级区分 —— 改用font-size、color、letter-spacing组合更可靠
容易被忽略的细节：字体加载与回退时机
Web Font 加载完成前，浏览器会先用系统字体渲染，此时 font-weight 行为完全由系统决定；加载完成后才切换。这个过程在安卓低端机上可能长达数百毫秒，造成闪动。
- 用
font-display: swap确保文本立即可见，但要注意 fallback 阶段的字重一致性 - 不要在
@font-face中省略font-weight声明，否则浏览器可能将所有 weight 都映射到 400 - 测试时务必在真机上关闭字体缓存（如 Chrome DevTools → Network → Disable cache），否则本地调试看不出问题
最麻烦的点不是写不对，而是你以为写对了 —— 安卓上那个“看起来加粗了”的 font-weight: 700，很可能只是描边糊了一圈，实际字宽、行高、基线都已偏移。真要保一致性，就得把字体文件握在自己手里，别信系统。
