:first-child与:last-child区别及应用解析

:first-child 和 :last-child 并非如字面所想的“选中第一个或最后一个某类元素”，而是严格要求目标元素必须是父容器的首个或末个子节点（类型和位置双重限定），极易因隐藏的文本节点、注释、动态插入内容或结构变化而失效；真正按元素类型精准定位首尾的应使用 :first-of-type 和 :last-of-type——它们忽略其他类型节点，只在同类元素中计数，更符合开发直觉与实际需求，且兼容性良好（IE9+），但在 DOM 动态更新时仍需注意其静态匹配特性，复杂场景建议辅以 JavaScript 精准控制。

为什么 :first-child 不等于“第一个子元素是某类型”

很多人写 div p:first-child 本意是选中 div 下第一个 p，但实际它只匹配“既是 p 又是其父元素第一个子节点”的元素。如果父元素第一个子节点是 h2，哪怕后面有十个 p，p:first-child 也完全不生效。

常见错误场景：

• 在列表中想高亮首项，但误加了 span 或注释节点导致失效
• 用 Vue/React 动态插入内容后，DOM 结构变化使 :first-child 失去预期效果
• 忽略文本节点（空格、换行）也会被算作子节点，尤其在内联 HTML 中

:last-child 的行为与陷阱和 :first-child 完全对称

它同样要求目标元素必须是父容器的最后一个子节点，而非“最后一个某类型元素”。例如：li:last-child 能匹配到 ul 中最后一个 li；但如果 ul 最后一个子节点是 div，那所有 li 都不满足 :last-child。

典型误用：

• 给导航菜单最后一项加右 margin，结果因尾部有 导致样式丢失
• 表格中用 td:last-child 设置边框，但实际最后一列后面还有 th 单元格
• Flex 容器里混用 div 和 span，导致 span:last-child 永远不命中

真正按类型找首尾：改用 :first-of-type 和 :last-of-type

当你要选“第一个 p”或“最后一个 li”，不管它前面/后面有没有其他标签，就该换这两个伪类。它们按元素类型分组计数，不依赖绝对位置。

对比示例：

  
标题
  
第一段
  
第二段
  说明

其中：

• p:first-child → 不匹配（p 不是第一个子节点）
• p:first-of-type → 匹配第一个

• p:last-child → 不匹配（p 不是最后一个子节点）
• p:last-of-type → 匹配第二个

兼容性与现代替代方案提醒

:first-child / :last-child / :first-of-type / :last-of-type 在 IE9+ 均支持，无需 polyfill。但要注意：

• CSS 选择器优先级相同，不要指望靠顺序覆盖 —— 写错一个层级就全失效
• 若需更灵活控制（如第 n 个某类型），:nth-of-type(n) 比 :nth-child(n) 更可靠
• 复杂逻辑建议退回到 JS 判断（如 el.parentElement.querySelector('p')），避免伪类嵌套失控

最常被忽略的一点：伪类匹配的是静态结构，不响应 DOM 动态增删 —— 添加新元素后，旧元素的 :first-child 状态可能瞬间改变，而开发者常以为它“固定绑定”在某个元素上。

本篇关于《:first-child与:last-child区别及应用解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！