用 vw 做响应式文字需搭配 clamp()、vmin 或媒体查询，否则小屏字太小、大屏字爆炸；clamp(16px, 4vmin, 24px) 最稳，兼顾可读性与平滑过渡。
直接说结论：用 vw 做响应式文字可以，但单靠它会出问题；必须搭配 clamp()、vmin 或媒体查询，否则在小屏上字太小、大屏上字爆炸。
为什么 font-size: 5vw 在手机横屏时会撑爆页面
因为 5vw 是视口宽度的 5%，iPhone 横屏时视口宽度约 812px → 字体 ≈ 40px；如果再放大到 iPad Pro 横屏（2048px），就是 102px——标题直接顶到屏幕边缘。更糟的是，小屏竖屏（375px）下只有 18.75px，还没考虑系统最小字体限制（Chrome 强制 ≥12px）。这不是“响应”，是失控。
-
vw无下限：视口越窄，字体越小，font-size: 1vw在 320px 屏上只有 3.2px（实际渲染为 12px，但比例已失真） -
vh更危险：用于文字时，用户滚动或 Safari 地址栏收起会导致vh突变，文字跳动 - 纯
vw文字无法保证可读性，尤其长段落——行宽过大会降低阅读效率
font-size: clamp(16px, 4vmin, 24px) 是当前最稳的写法
clamp() 给字体设了硬边界：min 防小屏糊眼，max 防大屏溢出，中间用 vmin 实现平滑过渡。它比单纯 vw 更可靠，因为 vmin 取视口宽高中的较小值，竖屏按宽度算、横屏按高度算，视觉尺寸更一致。
-
vmin比vw更适合正文：比如font-size: 2.5vmin，在 iPhone 竖屏（375×812）取 375→9.375px（升至 12px），横屏（812×375）取 375→同样 9.375px，不会因方向切换突变 -
clamp(16px, 4vmin, 24px)表示：最小 16px，理想值 4% 的短边，最大不超过 24px —— 这个组合覆盖了从手机到桌面的合理范围 - 注意：IE 完全不支持
clamp()和vmin，如需兼容，得加font-size: 16pxfallback
calc(1rem + 1.5vw) 这类混合写法适合标题层级控制
纯流体文字难控节奏，标题需要比正文更大、但又不能随屏幕无限放大。calc() 把固定基准（1rem）和弹性增量（1.5vw）结合起来，既保留设计锚点，又带响应性。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
立即学习“前端免费学习笔记（深入）”；
- 例如：
h1 { font-size: calc(1.5rem + 2vw); }—— 基准 1.5rem（≈24px），每 100px 视口宽度额外 +2px，1366px 屏上 ≈ 37px，比纯5vw（68px）收敛得多 - 慎用
vh混合：比如calc(1rem + 1vh)，在 Safari 中地址栏变化时会抖动，优先选vmin或vw - line-height 别用
vh：行高应基于字体大小（如line-height: 1.4），而非视口，否则小屏行距塌陷、大屏行距撕裂
移动端 Safari 的 vh 动态问题必须用 JS 补救
当你非要用 vh 控制容器高度（比如全屏轮播），Safari 的 100vh 在地址栏展开/收起时不重绘，导致内容被遮挡或留白。CSS 本身无解，得靠 JS 动态注入变量。
- 在
里加：document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`); - CSS 中写：
height: calc(var(--vh, 1vh) * 100);，并监听resize事件更新变量 - 注意：这个方案只解决高度问题，对文字排版没意义——文字别碰
vh，这是坑 - 新单位
dvh（dynamic viewport height）已进入标准，但截至 2026 年 6 月，iOS 17+ 才稳定支持，旧版本仍需 JS
真正难的不是怎么写 vw，而是判断什么时候不该用它——比如按钮文字、表单输入框、代码块，这些需要绝对可读性的场景，rem 或 em 加媒体查询反而更稳。视口单位是刀，不是胶水，削得准才叫适配。
