根本原因是CSS选择器权重不足或被更具体规则覆盖，而非嵌套违法；p > span是子选择器，p span是后代选择器；vertical-align默认baseline导致对齐异常；all: unset可能误重置display引发兼容问题。
为什么 p 标签里写 span 或 strong 后样式不生效
根本原因不是嵌套本身违法（p 里放 span、strong、em 完全合法），而是 CSS 选择器权重不足，或被更具体的规则覆盖。浏览器默认样式表里 p 的 margin 和 font-size 往往比内联元素的样式“更抢眼”，尤其当开发者只给子元素写了 color 却没重置 line-height 或 vertical-align 时，视觉上就像“没生效”。
p > span 和 p span 的区别直接影响样式是否命中
这是最常踩的坑：用空格是后代选择器，用 > 是子选择器。如果 HTML 是 <p><span><em>text</em></span></p>，那么：
-
p span能匹配到span和em（因为em是p的后代） -
p > span只匹配直接子级span，不会影响里面的em - 若误写成
p.span（没空格），就变成要求p自身有class="span"，完全选错目标
内联元素在 p 中垂直对齐异常的典型表现与修复
常见现象：给 p 设了 line-height: 2，里面 span 加了 background: yellow，结果背景上下留白不均，像“贴顶”或“下沉”。这是因为 span 默认 vertical-align: baseline，而基线对齐会受父级行高和字体度量影响。
实操建议：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 给内联元素加
vertical-align: middle或top，而非依赖默认值 - 避免在
p上设过大的line-height后，又对子元素单独设font-size—— 行高会继承计算值，导致实际行框高度失控 - 真要精细控制，把
span改成display: inline-block，再设line-height: normal和明确的height
使用 all: unset 重置内联元素时的兼容性陷阱
有人想“清空所有默认样式”直接上 span { all: unset; }，结果发现 Firefox 下正常，Chrome 里 span 突然换行或宽度异常。这是因为 all: unset 会把 display 也重置为 inline（看似没变），但某些浏览器对未声明 display 的内联元素在重置后处理逻辑不同。
更稳妥的做法：
- 只重置真正干扰的属性，比如
span { color: inherit; font: inherit; text-decoration: none; } - 如需彻底隔离，显式声明
span { display: inline; }，而不是依赖unset - 注意 Safari 对
all: revert支持较晚（v15.4+），别在老版本 iOS 混用
嵌套本身不难，难的是默认样式、继承链和选择器优先级这三股力拧在一起时，你改的那行 CSS 到底压过了谁、又被谁压了 —— 多开开发者工具，盯着“Computed”面板看真实生效值，比猜快得多。
