应统一使用无单位line-height（如1.5）以确保与font-size成稳定比例，避免固定像素值、em单位及冗长字体栈导致的行高失衡，中英混排推荐1.5–1.7区间。
字体大小和行高不匹配导致文字挤在一起或太松散
常见现象是段落文字看起来“压着”或“飘着”，比如 p 标签里字小但行高大，上下留白夸张；或者 h2 字大但行高没调，字挨得太近像叠在一起。本质是 font-size 和 line-height 没形成稳定比例关系。
建议统一用无单位的 line-height 值（如 1.5），它会相对于当前元素的 font-size 自动计算。避免写 line-height: 24px 这类固定值——父元素字号一变，子元素行高就失衡。
- 正文段落常用
font-size: 16px; line-height: 1.6; - 标题可按层级递减行高比例：比如
h1 { font-size: 32px; line-height: 1.2; }，h2 { font-size: 24px; line-height: 1.3; } - 小号文字（如
small或注释）别盲目缩放行高，保持至少1.4，否则易读性骤降
中英文混排时行高突然塌陷或撑开
中文字体（如 "PingFang SC"、"Microsoft YaHei"）和英文字体（如 "Helvetica"、"Arial"）默认基线和字高不同，纯靠系统 fallback 容易让同一行里中英文上下错位，视觉上像“断层”。
解决关键不是换字体，而是控制 line-height 足够包容两者。测试发现，line-height: 1.5 到 1.7 是多数中英混排的安全区间；低于 1.4 很可能塌陷，高于 1.8 又显得空洞。
立即学习“前端免费学习笔记（深入）”；
另外，避免在容器上设 height 或 min-height 固定值——它会截断行高计算，尤其遇到 sup、sub 或 emoji 时直接溢出。
Windows 命令行编码与兼容规范。涵盖 GBK/UTF-8 编码、PowerShell/pwsh 互操作、Python/Node.js、Git 配置及代码生成规则。适用于 Windows 10/11 + MSYS2/Git Bash 环境下的所有命令行操作。
使用 rem/em 时行高继承出人意料
rem 基于根字号，em 基于父字号，但 line-height 的行为分两种：
- 写成
line-height: 1.5;（无单位）→ 相对当前元素font-size计算，**不继承**，最可控 - 写成
line-height: 1.5em;→ 相对于父元素font-size计算，且会层层叠加，极易失控
例如：父元素 font-size: 20px; line-height: 1.5em;（即 30px），子元素 font-size: 14px; 却仍用 30px 行高，字就“悬空”了。所以只要用相对单位设字号，line-height 就必须用无单位数值。
body {
font-size: 16px;
}
h1 {
font-size: 2rem; /* = 32px */
line-height: 1.2; /* = 32 × 1.2 = 38.4px，干净 */
}
p {
font-size: 1rem; /* = 16px */
line-height: 1.6; /* = 16 × 1.6 = 25.6px */
}全局字体栈里 fallback 字体拖累行高一致性
定义 font-family 时如果 fallback 列表太长，比如 "Helvetica", "Arial", "PingFang SC", "Microsoft YaHei", sans-serif，不同系统实际加载的字体可能字高差异极大——Mac 上用 PingFang SC 显示正常，Windows 用 Microsoft YaHei 就可能撑高整行。
对策不是删掉 fallback，而是用 @supports 或媒体查询做轻量适配，或更务实一点：在关键模块（如标题、卡片正文）单独声明更收敛的字体栈，并补一句 line-height 锁死。
真正容易被忽略的是：字体加载完成前，浏览器用备用字体渲染，此时行高已按初始字体算好。等自定义字体加载完，字形变了但行高没重算，就会闪动。加 font-display: swap; 能缓解，但无法根治——所以行高预留余量比追求像素级精准更重要。
