设计稿明确要求「行高26px」时，应直接写leading-[26px]，Tailwind v3.3+默认支持，不随字号缩放；v3.2及更早版本需在theme.extend.lineHeight中注册{ '26': '26px' }才生效。
直接写 leading-[26px]，别换算比例
设计稿标了「行高 26px」，就老老实实写 leading-[26px]。Tailwind v3.3+ 默认支持这种任意像素值写法，不依赖当前 font-size 缩放，也不会被根字号干扰。你不需要查 text-base 是不是 16px、再算 26 ÷ 16 = 1.625 去写 leading-[1.625]——那只是徒增出错概率。
常见错误现象：leading-6 看起来太紧或太松，是因为它对应的是 line-height: 1.5rem（即 24px），但你的设计稿要的是 26px，差这 2px 就可能让文字在卡片里压线、或和图标对不齐。
- 版本低于 v3.3？必须在
tailwind.config.js的theme.extend.lineHeight里手动注册：{ '26': '26px' }，否则leading-[26px]不生效 - 别写成
leading-[26]（缺单位）或leading-[26px]在旧版中误加引号（如'26px'），会导致编译失败 -
leading-[26px]中的 26 是纯数字，单位是隐含的 px，不是 rem，也不是 em
leading-tight 和 leading-loose 到底等于多少像素？
它们不是固定像素，而是乘数：比如 text-base 默认是 16px，leading-tight 就是 16 × 1.25 = 20px；换成 text-xl（通常 20px），leading-tight 就变成 25px。你不能拿 Figma 里写的「32px 行高」直接套 leading-loose，除非确认当前字体大小刚好是 16px。
查具体值最靠谱的方式：打开 Tailwind 官网的 lineHeight 文档页，对照你项目里实际使用的 fontSize 查表。很多布局错位，根源就是没意识到这个缩放关系。
-
leading-tight在单行按钮中容易让文字贴顶贴底，尤其搭配h-8这类固定高度时 -
leading-loose用在列表项里，常和space-y-4叠加导致行距翻倍，视觉上“飘”起来 - 如果真要用比例值，优先选无单位小数如
leading-[1.55]，语义比leading-6清晰，也不随根字号变
为什么加了 leading-[26px] 文字还是没垂直居中？
leading- 类只控制 line box 高度，不是容器高度。给一个 h-10（40px）的 div 加 leading-[26px]，文字不会自动居中——line-height 是 26px，但容器高 40px，多出来的 14px 默认分到上下两行框边缘，文字依然靠上。
正确解法只有两个方向：
- 匹配高度：把容器高度改成
h-[26px]或h-6（如果 1rem = 16px，6 × 16 = 96px → 显然不对），所以更推荐直接写h-[26px] - 改布局方式：用
flex items-center+h-10，把行高当辅助，靠 flex 主动居中 - 别用
leading-none或leading-[1]处理中文字体，「龜」「龍」这类字会上下溢出，因为 line-height: 1 压掉了字体固有的 ascender/descender 空间
配置文件里要不要注册自定义行高？
如果你用的是 Tailwind v3.3+，不用注册，leading-[24px]、leading-[30] 这类写法开箱即用。v3.2 及更早版本才需要手动扩展 theme.extend.lineHeight。
但注意：即使注册了，也建议只注册高频值（比如 '22': '22px'、'28': '28px'），别一股脑塞一堆，既增加配置体积，又削弱了 arbitrary value 的灵活性。
最容易被忽略的一点：行高错位问题，80% 不是 leading- 写错了，而是混淆了「字体度量空间」「line box 高度」「容器高度」三者的关系。调试时先用浏览器开发者工具检查 computed line-height 和 height，再决定动哪一层。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
