一、三条互相矛盾的线索#

Bug 报告只有一句话：邀请好友页底部卡片的小字「显示过大」。但细节处处矛盾：

• 出问题的只有两个机型：华为 Mate 60 和 vivo Y33s——而且只在打包网页应用里出问题。应用为了省包体积没有打包自己的内核，网页直接用系统 WebView 渲染。其中 Mate 60 是鸿蒙 6 系统，应用通过卓易通安卓兼容环境运行，WebView 是兼容环境内置的安卓 12 内核；
• 同一台 Mate 60 上装 Firefox 打开，显示完全正常——排除了「系统字体调大了」的可能；
• 其他手机和所有桌面浏览器也都正常。

三条线索指向同一个结论：不是页面代码的问题，是这两个安卓 12 内核的系统 WebView（Mate 60 上由卓易通兼容环境提供）对「过小字号」的处理与标准浏览器不同。剩下的问题只有一个：它们到底在什么时候、怎样放大了字号，以及怎么绕过去。

二、第一回合：以为是 font boosting#

Chromium 有个著名机制叫 font boosting：当一大段文字字号偏小、容器又宽时，内核会自动放大字号避免「蚂蚁字」。社区的标准解法是给文本容器设置一个哨兵值——设置了 max-height 的块会被跳过放大逻辑。

1
/* Chromium 对设置了 max-height 的块跳过 font boosting */
2
.panel, .card, .rank-list, .region-list {
3
  max-height: 999999px; /* 仅作哨兵，不影响布局 */
4
}

❌ 无效：这个解法只能抑制部分内核的经典 font boosting，对系统 WebView 的「最小字号」机制不起作用。上线后问题依旧。

三、第二回合：JS 探测 + zoom#

第二版加了运行时探测：在屏幕外渲染一个 5px 的探测字，测量 getBoundingClientRect().height。被放大的内核测出 12px 左右，正常内核测出 5px 左右。命中后把字号抬到 12px 安全线，再用 zoom 属性按比例缩回视觉尺寸。

1
// 探测：5px 字实测高度超过 8px 说明被内核强制放大
2
const probe = document.createElement('span');
3
probe.style.cssText = 'position:absolute;left:-9999px;font-size:5px;line-height:1;';
4
probe.textContent = '字号探测';
5
document.body.appendChild(probe);
6
const boosted = probe.getBoundingClientRect().height > 8;
7
probe.remove();

❌ 无效：两个环节都不可靠——探测依赖布局层测量，渲染层放大时测不到；zoom 是长期非标准属性，在部分定制内核上行为未知。真机上问题依旧。

但这次失败暴露了真正的敌人：这些内核的机制是布局层的最小字号强制——只要 font-size 低于阈值（通常是 12px），无论什么 CSS 技巧都拦不住它。

四、终局：放大渲染，再整体缩回#

既然「布局层的字号不能小于 12px」是一条绕不开的规则，那就干脆尊重它：

1. 把整张画布按 2.8 倍放大渲染——所有字号都超过安全线；
2. 再用每个内核都百分百支持的标准属性 transform: scale 整体缩回设计尺寸。

视觉尺寸完全不变，但布局层的 font-size 永远不小于 12px——内核的放大机制被从源头架空。

1
/* 页面根节点：JS 按容器宽写入 --page-u（宽/360） */
2
--page-u: 1px;
3

4
/* 画布：内部单位放大 2.8 倍，字号全部越过最小字号安全线 */
5
.canvas {
6
  width: calc(100% * 2.8);          /* 宽度同样放大，缩回后视觉宽不变 */
7
  height: calc(640 * var(--u));
8
  --u: calc(var(--page-u) * 2.8);
9
  --text-micro: calc(5 * var(--u)); /* 320px 宽设备上也达到 12.4px */
10
  transform: scale(calc(1 / 2.8));  /* 标准属性，所有内核都支持 */
11
  transform-origin: top left;
12
  margin-bottom: calc(-1152 * var(--page-u)); /* 负外边距回收布局占位 */
13
}
14

15
/* 固定像素资源（如 SVG 图标）也要同步放大 */
16
.canvas .icon svg {
17
  width: calc(14 * var(--u)) !important;
18
  height: calc(14 * var(--u)) !important;
19
}

实测数据对比（无头 Chromium 测量同一段 5px 卡片文字）：

五、踩坑：页面变扁了#

第一版只补偿了高度，上线后页面「直接变扁了」。用无头浏览器实测才发现：

transform: scale(0.357) 把宽度也一起缩小了——画布布局宽 360px，缩回后视觉只剩 128px，整页变成左侧一条窄带。

⚠️ 教训：transform 缩放是等比的，宽高补偿一个都不能少。

修复后实测：

六、系数怎么定#

放大系数 K 的约束：最窄设备（320px，页面最小宽度）上，最小的目标字号放大后也必须 ≥ 12px。

本项目最小字号 5px、页面按 360px 设计稿等比缩放：320px 设备上目标 4.44px，K 取 2.8 时渲染 12.44px，刚好越线。

七、怎么验证#

肉眼在真机上迭代太慢，无头浏览器可以精确验证补偿是否成立——布局盒尺寸（offsetHeight）与视觉尺寸（getBoundingClientRect().height）应该相差恰好 K 倍：

1
const canvas = document.querySelector('.canvas');
2
const layoutH = canvas.offsetHeight;                  // 1792 = 640 × 2.8
3
const visualH = canvas.getBoundingClientRect().height; // 640  ← 缩回后的视觉值
4
const visualW = canvas.getBoundingClientRect().width;  // 360  ← 宽度同样要缩回
5
// 布局 ≈ 视觉 × K，且后续元素的 top 恰好等于画布视觉高度，补偿才算对

八、适用边界#

这套方案适合设计稿必须出现 12px 以下字号的移动端活动页。几个前提：

• 画布是自包含的等比布局（百分比定位 + 缩放单位）；
• 页面宽度有下限约束（用来推算 K）；
• 如果页面以流式排版为主，更省事的做法是把小字号干脆提到 12px 以上。

附带一个红利：2.8 倍精度渲染后再缩小，文字在视网膜屏上更清晰——相当于免费做了 2.8x 的矢量清晰度。

✒️ 三次试错，一个最终方案，已在生产环境验证上线。