直接写 vw 或 rem 在 CSS-in-JS 中易出错，因库默认为数字值自动添加 px 单位；须显式传字符串（如 "16vw"）或使用 clamp() 等原生方案确保单位生效。
为什么直接写 vw 或 rem 在 CSS-in-JS 里容易出错
因为多数 CSS-in-JS 库（比如 styled-components、@emotion/react）默认把数字值自动加 px，你写 fontSize: 16，它真就输出 font-size: 16px。想用 vw 或 rem，得主动“打断”这个默认行为，否则单位被覆盖或忽略。
常见错误现象：fontSize: 16vw 看似合理，但若你误写成 fontSize: 16 * 0.1 这类计算式，结果是 1.6 —— 它又会被补上 px，变成 1.6px，完全不是预期效果。
- 使用场景：适配不同屏幕宽度的标题字号、根据根字体缩放的间距系统
- 关键点：CSS-in-JS 不解析单位字符串里的数学，只认最终字符串或带单位的数值（如
"16vw"） - 性能影响：字符串拼接无负担；但频繁用
calc(100vw / 375 * 16)这类表达式，可能拖慢 SSR 渲染（尤其服务端没缓存时）
styled-components 里怎么安全写 vw 和 rem
必须显式传字符串，不能依赖数字自动转换。函数组件内可结合 useEffect + document.documentElement.style.fontSize 动态改根字号，但 rem 值本身在样式中仍是静态字符串。
- 正确写法：
fontSize: "4.266667vw"（对应 320px 设计稿的 16px）、padding: "1rem" - 错误写法：
fontSize: 4.266667 + "vw"（看似一样，但模板字符串更安全，避免空格/类型隐式转换） - 兼容性注意：
vw在 iOS Safari 8+ 支持良好，但旧 Android WebView 可能有缩放 bug；rem需确保html根元素font-size已设（通常靠 JS 或媒体查询） - 示例：
const Title = styled.h1`<br> font-size: ${props => props.level === 'h1' ? '5.333vw' : '4.266vw'};<br> line-height: 1.2;<br>`;
用 clamp() 替代手动换算 px → vw 更靠谱吗
是，而且越来越推荐。它不依赖 CSS-in-JS 的字符串拼接逻辑，浏览器原生支持响应式范围控制，还能 fallback 到 px。
立即学习“前端免费学习笔记（深入）”；
- 典型写法：
fontSize: "clamp(16px, 4.266vw, 24px)"—— 小屏用 16px，大屏用 24px，中间线性过渡 - 为什么比纯
vw稳定：避免超小屏下字号缩到不可读（比如1vw在 320px 屏就是 3.2px），也省去手动算断点 - 兼容性：Chrome 88+、Firefox 79+、Safari 14.1+ 支持；不支持时会降级为第一个值（
16px），所以务必把最小值写实 - 注意点：
clamp()三个参数必须同单位或都无单位（不能混用px和em），且中间值建议用vw或%，别用rem
用工具函数自动转 px 为 vw 时最常漏掉什么
漏掉设计稿基准宽度。所有 vw 换算都基于「100vw = 设计稿宽度」，如果设计稿是 375px，那 16px 就是 (16 / 375) * 100 = 4.266vw；换成 750px 设计稿就得用 16 / 750 * 100 = 2.133vw。
- 易踩坑：团队用 Figma 750px 设计稿，但前端按 375px 写换算，字号直接小一半
- 建议封装函数：
const pxToVw = (px, baseWidth = 375) => `${(px / baseWidth) * 100}vw`;，调用时明确传baseWidth - 更隐蔽的问题：UI 库组件（如 Ant Design）内部用
px，你全局改根字号或注入vw，可能和它们的尺寸逻辑冲突，需单独覆盖
单位转换本身不难，难的是所有人对「基准宽度」「根字号来源」「降级策略」有共识。一个项目里混用 375px 设计稿换算、750px 换算、rem 动态根字号、clamp()，最后响应式表现会彼此打架。
