clamp()最稳但只认视口宽度，容器窄于视口时vw失准；安全写法为font-size: clamp(1.125rem, 3.2vw, 2.25rem)，单位统一、三值齐全，容器尺寸变化需resizeobserver监听。
直接用 clamp() 是最稳的方案，但前提是容器宽度 ≈ 视口宽度；如果容器是固定宽、嵌套在复杂布局里，或者需要严格匹配某个 div 的实际宽度，clamp() 就失效了——它只认视口，不认父容器。
为什么 vw 单位在多数多端场景下会“失准”
vw 基于 window.innerWidth，不是你那个 .card-title 的实际宽度。比如一个卡片只占屏幕 1/3 宽，你写 font-size: 6vw，在 375px 手机上算出来是 22.5px，但卡片本身可能只有 120px 宽——文字早撑爆了。
- 常见错误现象：
font-size: 5vw在 iPad 上字大得溢出，在小屏折叠手机上又缩成蚂蚁大小 - 真正影响可读性的不是“缩没缩”，而是缩放基准错位：容器窄 ≠ 视口窄
- 如果你的容器有
max-width: 400px或被flex/grid限制了实际渲染宽度，vw就完全不可靠
clamp() 要怎么写才不出错
clamp() 不是万能的，但它是目前唯一不用 JS 就能守住边界的纯 CSS 方案。关键在三值配比和单位一致性。
- 中间值必须用
vw或rem，别混用px和vw（Safari 会解析失败） - 典型安全写法：
font-size: clamp(1.125rem, 3.2vw, 2.25rem)—— 最小 18px、最大 36px，中间按视口宽度线性缩放 -
line-height和letter-spacing必须同步用相对单位，比如line-height: 1.3、letter-spacing: 0.02em，否则缩放后行距/字距会断裂 - 实测建议：从
2vw–4.5vw区间试起，文字越短、容器越窄，中间值越要往低调
容器宽度 ≠ 视口宽度时，必须用 ResizeObserver
当你要让标题严格填满一个 width: 320px 的弹窗 header，或适配卡片内 max-width: 280px 的标签，就得监听容器本身尺寸变化。
- 别读
offsetWidth或clientWidth——触发强制重排，滚动卡顿明显 - 标准写法用
contentBoxSize[0].inlineSize，但旧版 Safari 需 fallback 到getBoundingClientRect().width - 缩放逻辑里避免反复设置
style.fontSize，建议用requestAnimationFrame节流 - SSR 场景（如 Next.js）首次渲染时 DOM 未挂载，Observer 必须在
useEffect(() => { ro.observe(...) }, [])或DOMContentLoaded后启动
Canvas 里文字自适应怎么搞
Canvas 没有 layout 流，ctx.font 设多少，measureText() 就量多少。自动缩小只能靠自己算。
- 必须先完整设置字体：
ctx.font = 'bold 16px system-ui'，漏掉字重或字体族，测量结果就偏 -
ctx.measureText(text).width是唯一可靠宽度来源，但它不缩放，只给你尺子 - 二分法比线性试探高效得多：在
[8, 48]像素区间内，3–5 次就能收敛到目标宽度内的最大字号 - 中英文混排时 fallback 字体差异大，统一用
system-ui, -apple-system, sans-serif更稳定
真正麻烦的从来不是“怎么缩”，而是缩放边界在哪、谁来定义这个边界——是视口？是父容器？还是 Canvas 坐标系？选错基准，再精细的算法也救不回溢出或过小的文本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
