HTML单位混用会破坏渲染上下文：px为绝对单位，rem依赖根字号，混用导致盒模型错位；vw/vh在PDF导出时因引擎不支持动态视口而裁切；em嵌套累积放大，rem线性可控；单位本质是渲染契约，需关注其生命周期。
HTML单位换算本身不“影响”格式转换，但单位混用、缩放逻辑错位或视口配置不当，会直接导致布局错乱、字体失真、响应失效——这不是换算精度问题，而是渲染上下文被破坏。
px 和 rem 混用时为什么 layout 崩了
浏览器渲染时，px 是绝对像素单位（1px = 1设备物理像素 × 缩放比），而 rem 基于根元素 font-size 动态计算。一旦你在同一组件里既写 width: 200px 又写 padding: 1rem，且根字号被 JS 动态修改（比如适配不同屏幕），padding 就会随根字号缩放，width 却纹丝不动，造成盒模型错位。
- 常见错误现象：
input宽度固定px，但内边距用rem，缩放后文字被截断或留白异常 - 推荐做法：全局统一基准单位；如用
rem，则所有尺寸（包括border-width、line-height）都基于根字号推导 - 注意
font-size: 0.875rem在html { font-size: 16px }下是 14px，但若用户系统设了“更大文本”，1rem可能变成 20px，此时未做媒体查询兜底的px值就暴露刚性缺陷
vw/vh 在移动端转 PDF 时为何内容被裁切
PDF 渲染引擎（如 Puppeteer、wkhtmltopdf）通常不支持动态视口单位，或仅按初始视口宽高静态计算 1vw = 1% × 初始 viewport width。而移动端页面常依赖 JS 动态设置 viewport 或监听 resize 调整布局，PDF 导出时这些逻辑不执行，100vw 就可能远超 A4 实际宽度（约 595px）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 典型错误：
div { width: 100vw; height: 100vh; }→ PDF 中变成超宽长条，右侧被裁 - 导出前必须替换：用媒体查询 + 固定 px 值兜底，例如
@media print { div { width: 595px; height: 842px; } } - 避免在
@page规则中使用vw/vh，该规则只接受绝对单位（mm、in、px）
em 和 rem 在嵌套字体缩放场景下怎么选
em 相对于父元素 font-size，rem 相对于根元素 font-size。当页面存在多层字体缩放（如可访问性设置 + 组件级 font-size 覆盖），em 会逐层累积放大，rem 则保持线性可控。
立即学习“前端免费学习笔记（深入）”；
- 错误用法：
button { font-size: 0.875em; padding: 0.5em; }→ 若按钮父容器font-size是 20px，则0.5em= 10px；但若再嵌一层div { font-size: 1.2em }，padding 就变成 12px，不可预测 - 安全做法：组件内间距统一用
rem，字体大小用em仅限语义化缩放（如h2 { font-size: 1.5em }表示“比父标题大 50%”） - 性能提示：
rem不触发重排，em在父font-size变更时可能引发整棵子树重绘
单位不是数学题，是渲染契约。最危险的不是算错，而是以为“换算完就结束了”，却忽略了单位背后绑定的上下文生命周期——比如 vh 依赖视口初始化时机，rem 依赖根字号是否被 JS 干扰，px 依赖设备像素比是否被忽略。这些细节不显式处理，格式转换时崩得毫无征兆。
