:nth-child(n+4)未生效的根本原因是它匹配父元素下所有同级子元素的位置，而非仅li标签；若存在div、p或文本节点等干扰项，序号即错乱。
nth-child(n+4) 为什么没生效？
常见现象是写了 li:nth-child(n+4) { display: none; }，但第4个以后的 li 还是显示——根本原因：:nth-child 看的是父元素下「所有同级子元素」的位置，不是只数 li。如果父容器里混着 div、p 或注释节点，位置序号就乱了。
实操建议：
- 先用浏览器开发者工具检查父元素的实际子节点结构，确认第4个
li真的是第4个子节点（比如它前面有没有空格文本节点、隐藏的span） - 若存在干扰节点，改用
:nth-of-type（只按标签类型计数），例如li:nth-of-type(n+4) - 更稳妥的做法是给目标列表加统一 class（如
class="option-list"），再用子选择器限定范围：.option-list > li:nth-child(n+4)
想限制最多显示3项，但数据动态增减怎么办？
纯 CSS 的 :nth-child(n+4) 是静态位置匹配，不感知内容是否真实存在。如果后端返回只有2条数据，它不会报错，也不会“自动跳过”；如果返回10条，它照常隐藏第4条起的所有项——这点很可靠，但也容易被误以为“失效”。
使用场景注意点：
立即学习“前端免费学习笔记（深入）”；
- 适合固定结构的菜单、标签云、评分星星等「视觉上限明确」的场景
- 不适合需要响应式折叠（比如“展开更多”按钮联动）的交互逻辑，那得靠 JS 控制类名或内联样式
- 若用在 Vue/React 中，确保 key 和渲染顺序稳定，避免因条件渲染打乱 DOM 位置导致隐藏错位
和 :nth-last-child 搭配做“倒序截断”有啥坑？
有人想“留最后3个，隐藏前面的”，会写 :nth-last-child(-n+3)，这本身没问题；但和 :nth-child(n+4) 同时用在一个选择器里，就可能冲突——比如同时命中第4项，一个要显示、一个要隐藏，CSS 层叠规则会让后者胜出，结果不符合预期。
参数差异提醒：
-
:nth-child(n+4)→ 从第4个开始（含）向后全部匹配 -
:nth-last-child(n+4)→ 从倒数第4个开始（含）向前全部匹配 - 想“只留中间3个”，不能靠简单组合，得用
:nth-child(n+2):nth-child(-n+4)这类交集写法，但可读性差，建议拆成两个独立规则或换 JS
兼容性和性能影响小到可以忽略
:nth-child() 是 CSS3 标准特性，IE9+ 全支持，现代项目基本无门槛。性能上它属于“位置伪类”，浏览器在构建渲染树时就能完成匹配，比 :not() 嵌套或属性选择器更轻量。
但要注意一个隐蔽点：
- 如果父容器频繁添加/删除子元素（比如实时聊天列表滚动加载），重排开销来自 DOM 变动本身，不是这个选择器——别怪错对象
- 用在
table里要小心：某些老浏览器对tr下的:nth-child解析不一致，优先用tbody > tr:nth-child(n+4)显式限定
真正容易被忽略的是：当用 display: none 隐藏后，那些元素仍存在于 DOM 中，aria 属性、焦点流、屏幕阅读器行为不会自动同步——如果涉及可访问性，得额外处理 aria-hidden 或用 hidden 属性配合 JS 控制。
