px转rem的base font-size应以html元素实际生效的computed font-size为准，而非浏览器默认16px；需通过DevTools查看或配置postcss-pxtorem的rootValue值。
px 转 rem 时 base font-size 设哪？
rem 的计算基准是根元素（html）的 font-size，不是浏览器默认的 16px，也不是你写在 body 里的值。很多转换器默认按 16px 算，结果一上线就错——因为项目里可能用 html { font-size: 62.5%; }（即 10px），也可能用 html { font-size: clamp(14px, 1.5vw, 18px); } 这种响应式写法。
实操建议：
- 先查当前页面实际生效的
html元素 computedfont-size值（DevTools → Elements → Computed → font-size） - 若用 PostCSS 或构建工具（如 Vite、Webpack），确认是否启用了
postcss-pxtorem，它的rootValue配置才是真实转换依据 - 手写转换公式：
rem = px / rootValue，例如 16px ÷ 10 = 1.6rem（当html font-size: 10px）
em 和 rem 混用时为什么尺寸忽大忽小？
em 是相对父元素字体大小，rem 是相对根元素字体大小。混用时，嵌套层级一深，em 就会指数级放大或缩小——比如父 font-size: 1.2em，子再写 font-size: 1.2em，实际就是 1.2 × 1.2 = 1.44 倍根字号。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 按钮文字在卡片里突然变小，但单独放正常
- 同一
class在不同容器中渲染出不同尺寸 - 用
em写padding或margin后，响应式断点下间距崩塌
建议：组件内部统一用 rem 或 px；仅在需要继承缩放语义的场景（如图标随文字等比缩放）才用 em，且避免超过两层嵌套。
写个轻量 JS 转换器，不依赖框架怎么算？
不用引入 Vue/React，几行原生 JS 就能搞定实时转换。关键不是“算得对”，而是“响应用户输入并防错”。
实操要点：
- 监听
input事件而非change，保证实时反馈 - 用
parseFloat()处理输入，自动忽略单位（如用户输16px或16） - 对空值、负数、非数字输入做兜底（如显示
-或清空输出） - rootValue 必须可配置，最好加个
<input type="number">让用户改
简短示例：
const pxInput = document.getElementById('px');
const remOutput = document.getElementById('rem');
const rootInput = document.getElementById('root');
pxInput.addEventListener('input', () => {
const px = parseFloat(pxInput.value) || 0;
const root = parseFloat(rootInput.value) || 16;
remOutput.value = px ? (px / root).toFixed(3) : '';
});
移动端适配中 rem 工具链容易漏掉什么？
很多人用 rem 做响应式，但只写了 JS 动态设置 html font-size，却忘了三件事：
- viewport meta 缺失或写错：
<meta name="viewport" content="width=device-width, initial-scale=1.0">必须存在，否则1rem在高 DPR 屏上会失真 - 未处理 iOS Safari 的缩放 bug：某些版本下双击放大后，
html font-size计算失效，需监听pageshow事件重设 - CSS 里写了
font-size: 14px这类绝对单位，它不会随 rem 缩放，导致文字和布局错位
真正可靠的 rem 适配，不是靠一个转换工具，而是整条链路对齐：设计稿基准（如 750px）、JS 动态根字号、PostCSS 编译规则、以及所有字体/间距都用 rem 表达——漏掉任意一环，转换器算得再准也没用。
