:first-child不生效是因为它要求目标元素必须是父容器的第一个子节点，且对前置注释、空白文本节点或异构元素零容忍；而:first-of-type仅按类型匹配首个元素，更鲁棒。
为什么 :first-child 有时不生效？
因为 :first-child 要求目标元素**必须是父容器的第一个子节点**，且类型不限——但一旦前面有其他 HTML 元素（比如注释、文本节点、<div>、<code><span></span>），哪怕只是换行空格产生的文本节点，它就立刻失效。
常见现象：<ul></ul> 里第一个 <li> 没被选中，检查 DOM 发现开头有注释或空格；或者父元素里混写了 <p></p> 和 <li>，<li> 不在最前。
-
:first-child看的是“位置”，不是“类型” - HTML 中的空白符（换行、缩进）会生成文本节点，可能占据第 1 个位置
- 用浏览器开发者工具的「Elements」面板看实际子节点顺序，比看源码更可靠
为什么 :first-of-type 更“宽容”？
:first-of-type 只关心“同类型元素中的第一个”，忽略中间夹杂的其他标签或文本节点。只要它是该标签（比如 <li>）在父元素中第一次出现，就匹配成功。
典型场景：新闻列表里穿插了广告 <div class="ad">，你只想给第一个真实 <code><li> 加顶部边框，用 :first-of-type 就不会被广告打断逻辑。
立即学习“前端免费学习笔记（深入）”；
- 匹配条件宽松：不要求连续，不要求靠前，只要同类中排第一
- 对语义化 HTML 更友好，比如
<article></article>内混合<header></header>、<p></p>、<footer></footer>，header:first-of-type仍能稳稳命中 - 注意：它不区分是否“可见”，
display: none的元素仍参与类型计数
两个伪类在嵌套列表里的行为差异
多层 <ul><li><ul></ul></li></ul> 结构下，容易误以为外层和内层会互相干扰。其实它们各自作用于直接父容器，但选择器写法稍有不慎就会跨层误匹配。
例如想给每个子菜单的第一项加图标：
ul li ul li:first-child { /* ❌ 错误：匹配的是子 ul 下第一个 li，但它可能不是子 ul 的第一个子元素（比如前面有注释） */ }ul li ul li:first-of-type { /* ✅ 更稳：只要它是子 ul 里第一个 <li> 标签就生效 */ }- 嵌套时，
:first-child容易因子 ul 内部结构（如换行、空格）失效 -
:first-of-type在这种场景下容错率更高，尤其当子列表由模板引擎动态生成时 - 若需严格限定“仅第一个且无前置内容”，可配合
:not()过滤，比如li:first-child:not(:empty)
兼容性和性能要注意什么？
两者都支持 IE9+，现代浏览器无差异。但性能上，:first-of-type 需要遍历所有同名兄弟节点才能确认“是否第一”，而 :first-child 只需检查父节点的第一个子节点，理论上略快——不过日常项目中几乎感知不到差别。
- 真正影响性能的是复杂选择器组合，比如
div#main ul.menu > li:first-of-type a span.icon，而非伪类本身 - SSR 或静态站点生成时，若 HTML 压缩工具去除了换行，
:first-child可能从失效变有效，造成样式不一致 - 服务端渲染 + 客户端 hydration 后，DOM 结构微小变化（如插入注释）可能导致
:first-child表现突变，:first-of-type更稳定
实际项目里，除非明确需要“绝对首位”的语义（比如首屏卡片强制置顶），否则优先用 :first-of-type。它不挑 HTML 格式，不怕模板生成的空格，也不怕后续维护者随手加个 <!-- comment -->。
