line-height-step 不是合法 css 属性，浏览器完全不识别且无效；它从未进入正式草案，未被任何主流浏览器实现，mdn、caniuse 和 css 规范均无记录。
line-height-step 目前不是合法的 CSS 属性，浏览器完全不识别，写了也无效。
为什么 line-height-step 不起作用
这是最常被误传的“CSS 新特性”之一——它从未进入任何正式草案，更未被 Chrome、Firefox 或 Safari 实现。搜索到的所谓用法，基本源于对早期 CSSWG 讨论稿（如 2018 年一份未采纳的 line-height-step 提案）的误读或搬运错误。
- 当前所有主流浏览器中，
line-height-step都是无效声明，开发者工具里会直接标为 strike-through（删除线） - MDN、CanIUse、CSS Spec 官网均无该属性记录
- 混淆来源常是把
line-clamp、text-spacing或排版引擎内部术语（如 HarfBuzz 的 step）当成了 CSS 接口
真正能控制换行后行高一致性的方法
想让多行文本在换行后保持视觉节奏稳定（比如中文段落、代码注释、卡片标题），靠的是组合使用已有属性，而非幻想中的“一步到位”方案。
-
line-height是基础：设为无单位数值（如1.5），它基于当前字体大小计算，比px或em更可靠 -
box-sizing: border-box+ 固定height或max-height可约束容器，避免因内容溢出破坏行高感知 - 对齐敏感场景（如多列标题），加
vertical-align: top防止 inline 元素基线错位影响行高渲染 - 避免混用
margin/padding在行内元素上——它们不参与行高计算，但会撑开容器造成“假行高”错觉
容易被忽略的行高继承陷阱
很多人以为设了父元素 line-height: 1.4，子元素就一定按此渲染，其实不然。
立即学习“前端免费学习笔记（深入）”；
-
line-height的计算值会继承，但若子元素显式设置了font-size，其实际行高 = 继承来的计算值 × 自身font-size - 用无单位值（
1.4）可避免级联污染；用px（如20px）则会固化，子元素改字号后行高不再缩放 - Flex/Grid 容器中，
align-items: baseline会让多行文本的基线对齐失效，表面看像“行高不一致”，实则是对齐策略问题
真要精细控制每行文字的垂直位置，目前只有 line-height + 字体度量（ascent/descent）+ transform: translateY() 手动微调这一条路——没有银弹，也没有 line-height-step。
