rem未“变大”，而是系统可访问性设置覆盖html font-size导致计算值偏离预期；getcomputedstyle读取的是最终渲染值而非css声明值；媒体查询失效因视觉视口重算与viewport缺失；css变量中rem不动态响应根字号变化。
不是 rem 本身“变大”，而是你写的 html { font-size: 62.5% } 或 html { font-size: 100px } 被系统字体设置覆盖后，计算结果偏离预期——浏览器在尊重用户可访问性设置，不是 bug。
为什么getComputedStyle读出来的fontSize不是你设的值
你设了 html { font-size: 62.5% }，本意是让 1rem ≈ 10px（基于默认 16px），但 iOS/Android 开启「更大字体」后，系统会先将根元素默认字号从 16px 提升到比如 24px 或 28px，再计算 62.5%，结果变成 15px 或 17.5px。用 window.getComputedStyle(document.documentElement).fontSize 查到的就是这个最终渲染值，不是你 CSS 里写的“建议值”。
写死 100px 更危险：某些安卓 WebView 会先按系统字体渲染首帧，JS 后续设置才生效，造成闪动+错位。
为什么@media (min-width: 40rem)在横屏或键盘弹出时失效
rem 媒体查询断点依赖根字号，而 Safari 在横屏切换、软键盘弹出时会临时重设 visualViewport.width，导致根字号重新计算时机错乱。尤其当 <meta name="viewport"> 缺了 initial-scale=1，Safari 会进一步放大基准，让 40rem 对应的物理宽度突然翻倍。
- 必须显式写
<meta name="viewport" content="width=device-width, initial-scale=1"> - 所有媒体查询断点改用
em（相对于浏览器默认 16px）或px，更稳定 - 若坚持用 rem 断点，确保
html的font-size在 CSS 加载早期就确定，不依赖 JS 注入
为什么var(--text-size: 1.2rem)首屏字体错位
CSS 变量是字符串替换，不感知 rem 动态计算时机。你在 :root 里写 --text-size: 1.2rem，浏览器会在样式解析阶段、JS 尚未执行前，按当前根字号（通常是未修改的 16px）算出 19.2px 并固化；后续 JS 把根字号调成 20px，这个变量值也不会自动重算。
调试时用 getComputedStyle(document.documentElement).getPropertyValue('--text-size') 查，大概率看到的是 19.2px，而不是你期望的 24px。
- 别把 rem 值塞进变量，改用比例因子：
--text-ratio: 1.2，再配合font-size: calc(var(--text-ratio) * 1rem) - JS 设置完
document.documentElement.style.fontSize后，立刻同步变量：document.documentElement.style.setProperty('--text-ratio', '1.2') - 避免在
DOMContentLoaded里只设一次——iOS Safari resize 事件可能延迟或漏发，校准逻辑要放在每次setrem()执行末尾
真正稳住 rem 的三个动作
核心不是锁死像素，而是让系统缩放可预测、可收敛：
- 开头就写
html { font-size: 100% }，不覆盖系统默认值 - JS 初始化必须二次校准：先设初值（如 100px），再用
getComputedStyle读真实值，按比例反推修正（例：实测 120px，则设100 * 100 / 120 = 83.333px） - 对像素级敏感的地方（边框、图标、圆角），放弃 rem 改用
1px或0.5px；line-height统一用无单位值（如1.4）
最易被忽略的是测试档位——不能只开「较大字体」，得拉到 iOS 「最大动态类型」或安卓「超大字体」，看 document.documentElement.style.fontSize 是否还在 14px–28px 合理区间。超出这个范围，说明你的校准逻辑没兜住极端场景。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
