nth-child未生效主因是元素未被选中或优先级不足，需检查是否为父元素第n个子元素、避免混入其他节点，并优先提升选择器特异性而非用!important。
nth-child(n) 为什么没生效？检查选择器权重和元素层级
最常见的情况是 nth-child 写对了，但颜色就是不出现。根本原因往往不是语法错，而是它匹配的元素压根没被选中——比如父容器里混入了其他类型子元素（<div> 前面有 <code><p></p> 或注释节点），或者 CSS 优先级被更具体的规则覆盖。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具「Elements」面板右键目标元素 → 「Force state」→ 勾选
:nth-child(2)，看是否高亮；不高亮说明没命中 - 确保目标元素是其父元素的第 n 个 子元素（不是第 n 个同类型元素），
div:nth-child(2)要求该div是父元素的第二个子节点，不管前面是不是span - 避免用
!important硬顶，优先提高选择器特异性，例如改用.list > div:nth-child(odd)
odd / even 和 2n+1 / 2n 区别在哪？别在 IE 中混用
odd 和 even 是语义简写，等价于 2n+1 和 2n，但 IE8 及更早版本只认后者。现在虽基本不用兼容 IE8，但团队若维护老项目，或用到某些 CSS 压缩工具（如旧版 cssnano）会把 odd 编译成 2n+1，反而导致调试时看到的和写的不一致。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 新项目直接用
odd/even，可读性高、不易写错 - 涉及构建流程时，检查 postcss 配置：如果启用了
autoprefixer且目标浏览器含 IE9+，它默认保留odd；但若配了cssnano且未关掉reduceIdents，可能做无谓转换 - 需要动态生成 nth 表达式时（比如 JS 拼 CSS 字符串），统一用
2n系列表达式，避免字符串拼接出"odd"这种非变量值
隔行换色遇到表单控件或空格文本节点？用 :nth-of-type 更稳
当父容器里除了目标元素还有 <label></label>、<input> 或换行产生的空白文本节点时，nth-child 的序号会乱。这时 nth-of-type 只按标签名计数，更符合“给所有 div 隔行上色”的直觉。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 纯结构化列表（如
<ul><li></ul>）用nth-child完全没问题；但富内容区块（如文章段落混排）优先试nth-of-type -
nth-of-type无法匹配类名或属性，所以div.red:nth-of-type(odd)是合法的，但div:nth-of-type(odd).red会失效——顺序不能颠倒 - Flex/Grid 布局下，
nth-child仍按 DOM 顺序计算，不受视觉排列影响；这点和nth-of-type一致，不必担心重排后序号错乱
性能敏感场景慎用复杂公式，尤其是移动端长列表
nth-child(3n+5) 这类表达式本身不慢，但浏览器要为每个子元素执行一次索引计算。当父容器有上千个子节点（比如虚拟滚动未启用的表格），配合 CSS 变量或 transition 触发重绘时，nth-child 的计算开销会叠加。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 静态样式（如隔行色）完全放心用；动态变更（如 JS 切换主题导致所有
nth-child规则重算）才需警惕 - 真遇到卡顿，用 class 替代：JS 批量加
row-odd/row-even类，CSS 写.row-odd { background: #f5f5f5; } - 不要为了“炫技”写
nth-child(10n+7)这种难读又难调的表达式——能用nth-child(odd)解决的，就别绕弯
真正容易被忽略的是：伪类匹配发生在渲染树构建阶段，不是样式计算阶段。这意味着哪怕某条 nth-child 规则最终没产生视觉变化（比如背景色被父层遮盖），它依然参与了完整匹配流程。节点越多，这个“隐形成本”越不可忽视。
