leading-normal 实际像素值不固定，通常约为字号×1.5（如16px时约24px），但受字体度量和浏览器计算影响，需用开发者工具实测；设计稿明确像素值时应直接使用 leading-[28px] 等精确值。
leading-normal 实际对应多少像素？
leading-normal 不是固定值，它依赖于当前字体族、字号和浏览器默认行高计算逻辑。多数情况下，它约等于 font-size * 1.5（即 150%），但不是绝对——比如在 font-size: 16px 时可能渲染为 24px 行高，而 font-size: 18px 时可能是 27px（某些字体下会略低）。这源于浏览器对 normal 的解释会参考字体的 line-gap 和 ascender/descender 度量。
实操建议：
- 别靠记忆或文档“估算”
leading-normal的像素值，用浏览器开发者工具直接检查line-height计算后样式 - 若设计稿明确要求「行高 = 28px」，就别用
leading-normal，改用leading-[28px]或leading-[1.555]（28 ÷ 字号） - 注意：Tailwind 默认配置中
leading-normal映射的是1.5，但如果你自定义了theme.extend.lineHeight，它的实际值可能已变
用 leading-[数值] 时单位怎么选？
Tailwind 支持三种写法：leading-4（比例）、leading-[1.4]（无单位小数）、leading-[22px]（带单位）。它们渲染结果不同，且影响可维护性。
实操建议：
-
leading-4是比例值（对应line-height: 1rem），受父级font-size影响，适合响应式缩放场景，但难精确控制像素高度 -
leading-[1.4]是纯比例，不随font-size变化而变化，语义清晰，推荐用于需要保持视觉节奏一致的文本（如正文段落） -
leading-[22px]是绝对像素值，最可控，但响应式断点里需配合md:leading-[24px]等手动调整，否则小屏文字挤在一起 - 避免混用：比如
text-lg leading-6（text-lg默认 18px，leading-6是 1.5rem = 24px），实际行高是 24px，但你可能以为是 18×1.5=27px —— 这种隐式换算容易出错
line-height 设为 1 为什么文字被截断？
设 leading-none 或 leading-[1] 后，上标、下标、重音符号、甚至某些中文字形（如「龜」「龍」）会溢出，因为 line-height: 1 把行框高度压缩到仅等于 font-size，没给字体度量留空间。
实操建议：
- 永远不要对正文、标题或含复杂字形的文本用
leading-[1] - 仅限图标内联文本、按钮中单行简短标签、或已确认字体（如
system-ui+ 英文）且严格测试过渲染效果的场景 - 替代方案：用
leading-[1.1]或leading-tight（默认 1.25），既紧凑又安全 - 检查方式：在 Chrome 中打开「Rendering」面板 → 勾选「Paint flashing」，看文字是否频繁触发重绘（溢出常导致重绘）
响应式行高怎么写才不漏断点？
Tailwind 默认只提供 sm、md、lg、xl 四个断点，但行高对小屏更敏感——比如手机端 16px 字号配 24px 行高刚好，平板上同样字号可能需要 26px 才不显空。
实操建议：
- 别只写
leading-6 md:leading-7，要补全关键断点：leading-6 sm:leading-6 md:leading-7 lg:leading-8 - 如果项目用了自定义断点（如
tablet），记得在tailwind.config.js的theme.extend.screens里加了，否则tablet:leading-[26px]不生效 - 避免“覆盖式写法”：
leading-[24px] md:leading-[26px] md:leading-[28px]—— 最后一个会覆盖前一个，CSS 层叠规则不会合并 - 真正省事的做法：用插件如
@headlessui/tailwindcss或自定义lineHeight配置，把常用响应式组合抽成 class，比如leading-responsive
行高不是调个数字就完事的事——它牵扯字体度量、设备渲染差异、响应式缩放和可访问性。最常被忽略的，是设计师给的「行高 32px」没说明基准字号，而你在 text-sm 下硬套 leading-[32px]，结果行框炸开两倍高。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
