响应式布局单位需按场景选择：rem适合全局等比缩放，em适合局部相对缩放但嵌套易失控，px用于精准固定值，vw/vh直接绑定视口但易抖动。
响应式布局中单位选不对，再好的设计也容易在不同设备上“变形”。rem、em、px、vw、vh 各有适用场景，关键不是哪个“高级”，而是是否匹配你的缩放逻辑和控制粒度。
rem：适合全局字体与间距的等比缩放
rem 以根元素（html）的 font-size 为基准，天然适配“整体缩放”需求。主流响应式方案（如淘宝 flexible、postcss-pxtorem）都依赖它实现屏幕宽度自适应文字大小。
- 设置 html 的 font-size 用 JS 或媒体查询动态计算（例如：1rem = 屏幕宽 / 10），后续所有 rem 值自动跟随缩放
- 慎用在 border、阴影等不希望随缩放变粗/变模糊的属性上——它们会跟着一起放大，可能破坏视觉精度
- 避免在嵌套组件中混用 rem 和 px 定义边框+内边距，容易导致比例失衡（比如按钮边框用 px，文字用 rem，缩放后边框看起来越来越细）
em：适合局部相对缩放，但嵌套时易失控
em 相对于父元素 font-size 计算，适合组件内部按比例伸缩（如图标尺寸随文字变化），但多层嵌套时值会逐级相乘，调试困难。
- 用在 iconfont 图标、行高 line-height、垂直居中 margin-top 等依赖父字号的场景更自然
- 如果父元素 font-size 是 rem 或百分比，em 就变成“复合缩放”，一次修改可能引发连锁反应，建议在深度嵌套结构中统一用 rem 替代
- 不要用 em 设置容器宽度——它受字体影响，而宽度本应由布局决定，非文字决定
px：精准控制不可少，但别滥用在可缩放元素上
px 是绝对单位，在 retina 屏下可通过 devicePixelRatio 配合 @media(-webkit-min-device-pixel-ratio) 做 1px 边框优化；但它无法响应缩放，所以不能用于需要随视口变化的字体或容器。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 适合固定像素的图标、分割线、border、box-shadow、圆角 radius（小数值如 1px、2px）
- 在 CSS-in-JS 或组件库中，用 px 写死基础间距（如 spacing-xs: 4px）反而利于一致性，只要不把它当成“响应式单位”来用
- 警惕 Chrome 开发者工具里显示的“computed px”——它只是当前渲染结果，不代表你写的 px 不会被缩放（比如用户手动放大网页时）
vw/vh：直接绑定视口，小心溢出与断点错位
1vw = 视口宽度的 1%，1vh = 视口高度的 1%。它们无视任何 font-size 设置，天生响应，但极易因滚动条、地址栏隐藏/显示、iOS Safari 的 viewport 动态变化而抖动。
- 适合全屏轮播图高度、背景图覆盖、标题字号（如 font-size: 5.6vw）等强视口依赖场景
- 避免用 vw 设置 padding/margin——滚动条出现时视口宽度突变，会导致布局跳动；可用 calc(100vw - 17px) 临时规避（17px 是滚动条宽，但不通用）
- iOS Safari 中，地址栏收起时 vh 会突然变大，导致内容被顶出视口，稳妥做法是结合 JS 监听 resize + orientationchange，并用 document.documentElement.clientHeight 动态更新 --vh 变量
单位选择本质是控制权的分配：rem 把缩放权交给根字体，em 交给父字体，vw/vh 交给视口，px 则彻底放弃缩放。没有银弹，只有匹配上下文的合理组合。
