rem配合根元素字体大小是目前最可控、最适配多端的响应式文字方案，核心是动态调整html的font-size作为基准，再用rem定义其他元素字号，避免在body设font-size或滥用em导致嵌套失控。
用 rem 配合根元素字体大小做响应式文字缩放
这是目前最可控、最适配多端的方案。核心是把 html 元素的 font-size 当作基准单位，其他元素用 rem 表示字号，再通过 JS 或媒体查询动态改 html 的 font-size。
常见错误是直接在 body 上设 font-size，结果子元素用 rem 时没反应——rem 只认 html 根节点，不是 body。
- 移动端常用 JS 动态计算：
document.documentElement.style.fontSize = window.innerWidth / 375 * 16 + 'px'（以 375px 宽为基准，16px 为 1rem） - 也可纯 CSS 做断点：
@media (max-width: 768px) { html { font-size: 14px; } } - 注意：iOS Safari 在横屏/竖屏切换时可能不触发
resize，建议监听orientationchange或用vh/vw辅助兜底
避免滥用 em 导致字号嵌套失控
em 是相对于父元素字体大小的单位，一旦多层嵌套（比如 div > p > span > strong），字号会指数级放大或缩小，调试极其困难。
典型现象：明明只给最外层设了 font-size: 1.2em，但内层文字小到看不见，或者突然撑爆容器。
立即学习“前端免费学习笔记（深入）”；
- 仅在明确需要“继承缩放”的局部场景用
em，比如按钮图标和文字等比缩放 - 全局字号控制坚决不用
em，尤其不要在html或body上设font-size再让子元素用em - 如果已用
em且层级深，可用font-size: 1em显式重置继承链
viewport 缩放失效时，vw 是更稳的备选
某些安卓 WebView 或老版本浏览器对 rem 动态调整支持差，或用户手动缩放页面后 rem 基准错乱，此时 vw（视口宽度百分比）更可靠。
比如 font-size: 4vw 表示文字始终占视口宽度的 4%，无需 JS 干预，兼容性也比 rem + JS 更广。
- 缺点是纯靠宽度缩放，高度窄的设备（如折叠屏竖屏）文字可能过大；可配合
clamp()限制范围：font-size: clamp(14px, 4vw, 20px) - 注意：IE 不支持
vw和clamp()，如需兼容 IE，必须降级回rem+ 媒体查询 - 慎用
vh控制字号，滚动时视口高度变化会导致文字跳动
内联样式和 !important 会破坏响应式文字体系
一旦某个元素用了 style="font-size: 18px !important"，它就彻底脱离了你精心设计的 rem 或 vw 体系，后续所有媒体查询、JS 调整都无效。
高频出问题的地方：第三方 UI 组件库的默认样式、CMS 输出的富文本、运营后台插入的广告代码。
- 审查元素时重点看 computed 样式里
font-size是否被内联样式覆盖 - 用 CSS 层叠权重化解：提高选择器特异性，比如
.article-content p比p更高，但别滥用!important - 富文本内容建议统一加容器包裹，并用
all: revert或font-size: inherit强制继承
实际项目里，rem + JS 动态基准最灵活，但得处理好横竖屏和缩放异常；vw + clamp() 更省心，适合新项目；而任何硬编码的像素字号或 !important，都是后期维护的定时炸弹。
