rem单位计算始终基于html元素的font-size值，浏览器默认为16px；修改html的font-size才能同步缩放所有rem尺寸，body等其他元素设置无效。
html选择器设置font-size影响rem计算基准
rem单位的计算始终基于 html 元素的 font-size 值，不是 body 或其他祖先元素。改了 html 的 font-size，所有用 rem 的尺寸才会同步缩放。
- 浏览器默认
html字体大小是 16px，所以1rem === 16px—— 这个默认值在所有现代浏览器里一致 - 直接写
html { font-size: 20px; }，那1rem就变成 20px；写html { font-size: 62.5%; }（即 16 × 0.625 = 10px），就能让1.4rem === 14px，方便换算 - 别在
body上设font-size试图“统一字体”，它对rem完全无效
用vw或JavaScript动态调整html font-size实现响应式rem
纯CSS的 html { font-size: ... } 是静态的，真要适配不同屏幕，得靠动态方案。主流做法是用 vw 简单映射，或用 JS 精确控制根字号。
-
html { font-size: calc(16px + 0.25vw); }可以让字号随视口缓慢增长，但注意：IE 不支持calc()里混用单位，且小屏下可能低于 12px（iOS Safari 最小字号限制） - JS 方案常见于移动端适配库（如 lib-flexible），核心就是监听
resize或orientationchange，然后重设document.documentElement.style.fontSize - 别在
DOMContentLoaded之后才计算——用户旋转手机时，innerWidth变了但没触发重算，字体就卡住
font-size设为em或%时rem行为容易误判
html 元素的 font-size 如果用了相对单位（比如 em、%），它的最终值会依赖父元素（即 documentElement 的父级，也就是根上下文），而这个上下文在 CSS 中没有显式父级，实际回退到初始值 —— 但行为在某些旧浏览器里不一致。
- 写
html { font-size: 1em; }等价于16px，没问题；但写html { font-size: 1.2em; }就危险：它参考的是“根元素的父级字号”，而这个值在不同浏览器初始化逻辑中可能有微小差异 - 更稳妥的做法是只用绝对单位（
px）、百分比（%）或vw，避免嵌套相对计算 - Chrome DevTools 的 computed 样式里看
font-size，如果显示为16px，说明计算落地了；如果还显示1.2em，说明没被解析，rem 会按未定义基准处理（通常 fallback 到 16px，但不可依赖）
媒体查询中修改html font-size需注意层叠顺序和触发时机
在 @media 里改 html 的 font-size 是可行的，但容易因样式表加载顺序、CSSOM 构建时机或 JS 干预导致失效。
立即学习“前端免费学习笔记（深入）”；
- 把媒体查询规则放在样式表末尾，避免被前面同选择器的规则覆盖；不要用
!important，它会让后续 JS 修改变得不可预测 - 如果页面用
link rel="stylesheet" media="print"加载了带媒体查询的 CSS，那些规则在屏幕设备上不会生效，html font-size就不会变 - 服务端渲染（SSR）场景下，若首屏 HTML 已内联了
html的style属性（如<html style="font-size:18px">），它会比外部 CSS 里的html规则优先级更高，媒体查询就压不住它
html font-size 的动态逻辑和第三方 UI 库的字体初始化时机搞混 —— 比如 Element Plus 在 mounted 时读取 getComputedStyle(document.documentElement).fontSize 缓存一次，之后你再改 html 字号，它也不重新计算。这种耦合点不翻源码根本意识不到。 
