用html根元素配合rem最可控，通过动态设置html的font-size（如clamp(14px,2.5vw,18px)）实现平滑响应式缩放，需注意clamp兼容性、禁用Safari text-size-adjust及避免body误设font-size。
用 html 根元素配合 rem 是最可控的方式
直接调 html 的 font-size，所有 rem 单位都会跟着变，比逐个改 p、h1 等元素更省事，也更符合响应式逻辑。
常见做法是把 html 的 font-size 设为一个动态值，比如基于视口宽度计算：
html {
font-size: clamp(14px, 2.5vw, 18px);
}这个写法在小屏（如手机）下保底 14px，大屏（如桌面）上限 18px，中间按视口宽度线性缩放。注意 clamp() 在 Safari 13.1+ 和 Chrome 85+ 才稳定支持，老版本需降级 fallback。
- 别用
%或em设html font-size，它们会继承父级，而html没有父级，行为不可靠 - 避免用 JavaScript 动态改
document.documentElement.style.fontSize，重排开销大，且和服务端渲染不友好 - 如果项目用了 PostCSS，可配合
postcss-pxtorem把px自动转rem，但记得关掉对border、height等非字体属性的转换
媒体查询里改 html font-size 要防断层和重复覆盖
很多人在多个 @media 里分别设 html font-size，结果在临界宽度来回拖拽时文字跳变——这是因为浏览器不会插值，只做离散切换。
立即学习“前端免费学习笔记（深入）”；
推荐用连续函数（如上面的 clamp()）替代多段媒体查询；如果必须用媒体查询，建议：
- 只设 2–3 个关键断点，例如
max-width: 480px、min-width: 768px、min-width: 1200px，别堆七八条 - 所有媒体查询写在全局样式末尾，避免被其他
html { font-size: ... }覆盖 - 测试时用设备模拟器拖动宽度，观察是否出现“突然放大/缩小”，有就说明断点间距太密或单位换算出错
body 上设 font-size 不解决根本问题
有人习惯在 body 上设 font-size: 100% 或 16px，但这只是重置继承起点，不影响 rem 基准——rem 永远相对于 html，不是 body。
典型误用场景：
html { font-size: 16px; }
body { font-size: 1.2rem; } /* 这会让 body 内所有 em/rem 都再乘 1.2，容易套娃失控 */除非你明确需要局部缩放（比如弹窗内文字统一放大 10%），否则 body 上不要碰 font-size。
-
1rem始终 = 当前html font-size计算值，和用户系统字号设置无关（想适配系统字号得用medium关键字或prefers-reduced-motion等媒体查询） - 用开发者工具选中
html元素，在 Computed 面板看font-size实际值，比猜更准
移动端 Safari 的 text-size-adjust 会偷偷干扰
iOS Safari 默认开启文字自动缩放，哪怕你设了 html font-size: 16px，它也可能把小段文字（比如 里少于 4 行的文本）放大到 18–20px，破坏设计一致性。
加这一行能关掉：
html {
-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;
}注意：设成 none 会禁用用户双指放大的能力，影响可访问性，100% 是更平衡的选择。
- 这个 CSS 必须写在
html或body上才生效，写在div里无效 - 部分安卓 WebView 对
text-size-adjust支持不全，可配合viewport的user-scalable=no临时兜底（但不推荐，损害可访问性）
实际调的时候，最常被忽略的是 clamp() 的兼容性补丁和 Safari 的 text-size-adjust 干扰——这两处不动，光调媒体查询数量没用。
