根本原因是html根元素font-size被重设后，与高清屏dpr>1的缩放逻辑叠加导致rem计算失准；tailwind字体类基于1rem=16px，根字号变更（如62.5%）使1rem在retina屏上物理渲染偏小发虚，prose等插件不自动补偿，需用prose-lg或重定义fontsize配置。
根本原因不是 Tailwind 本身出错，而是 html 根元素的 font-size 被全局重设后，与高清屏（dpr > 1）下浏览器的缩放逻辑叠加，导致 rem 计算失准。
为什么 1rem 在 Retina 屏上变小了？
Tailwind 的字体工具类（如 text-base、text-lg）默认基于 1rem = 16px。但很多项目为适配移动端或统一缩放，会在 html 上写类似 font-size: 62.5%（即 10px）或 font-size: clamp(14px, 1rem, 18px)。当设备像素比（dpr）为 2 时，浏览器会把 10px 渲染成「物理 20px」，但文本内容区域的逻辑尺寸仍按 10px 计算，结果就是文字看起来发虚、偏小、行高塌陷。
- 检查 DevTools → Elements →
html元素的 computedfont-size，若显示为10px或非16px，基本可确认是根字号干扰 - 高清屏下
devicePixelRatio≥ 2 时，这种偏差会被放大，尤其在text-sm或text-xs类上更明显 - 不要依赖「系统缩放设置」来判断——即使用户没调系统缩放，CSS 中的相对单位 + dpr 就足以触发渲染偏移
prose 类文字过小？别硬调 font-size，改用尺寸修饰符
prose 插件的 prose-base 默认以 1rem = 16px 为基准设定行高、段距和字体。如果你改了根字号，prose 不会自动补偿，直接导致整块文章文字挤在一起、阅读吃力。
- 优先用
prose-lg或prose-xl替代prose—— 它们内部已按比例放大所有rem值，不破坏垂直节奏 - 避免同时写
prose prose-lg：后者会覆盖前者的基线设定，且prose自身不含尺寸语义，叠加无意义 - 如果必须保留
html { font-size: 62.5% }，请在tailwind.config.js中显式重定义fontSize，例如：base: ['1rem', { lineHeight: '1.75' }]改为base: ['1.6rem', { lineHeight: '1.75' }]
响应式字体在 dpr 变化时失效？用 clamp() + 视口单位更稳
Tailwind 的 text-sm/text-lg 是静态断点类，不感知设备像素比。当你在 iPad Pro（dpr=2）和普通笔记本（dpr=1）上打开同一页面，text-base 渲染出的实际物理尺寸可能差一倍。
- 对关键标题或正文，放弃纯
rem，改用text-[clamp(1rem,4vw,1.5rem)]（需开启 arbitrary value） -
clamp()中间值用vw可随视口宽度自适应，两端用rem锚定最小/最大逻辑尺寸，dpr 变化时物理像素仍可控 - 注意：Safari 15.4+ 才完整支持
clamp()中混用rem和vw，旧版需降级为text-[clamp(16px,4vw,24px)]
真正难的不是调大字号，而是意识到 Tailwind 的字体系统本质是「基于标准浏览器默认行为的快捷映射」；一旦你主动打破这个前提（比如改根字号、用动态缩放、混用 dpr 敏感单位），就必须同步接管所有依赖它的模块（prose、line-clamp、spacing），否则失衡会从字体蔓延到整个排版节奏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
