瀑布流元素入场动画不能只靠统一animation-delay，因各列高度不一导致视觉顺序与DOM顺序错位；必须按实际渲染顺序递增延迟，:nth-child(n)适用于纯CSS多列布局，不适用于JS布局或Grid Masonry。
瀑布流元素入场动画为什么不能只靠 animation-delay 统一设值
因为瀑布流中每个列高度不一致，元素在 DOM 中是线性排列的，但视觉上会错落分布——如果给所有 .item 设置相同的 animation-delay，顶部元素可能延迟太久才动，底部刚进视口的反而早触发，节奏完全错乱。必须让延迟和“它在瀑布流中的实际渲染顺序”挂钩，而 :nth-child(n) 正好能按 DOM 位置提供可预测的序号。
用 :nth-child() 实现递增延迟的关键限制
:nth-child() 只认父容器下的子元素顺序，不管是否被 CSS 浮动、column-count 或 JS（如 Masonry）重排。所以它只适用于纯 CSS 瀑布流（column-count + break-inside: avoid），不适用于 JS 驱动的布局（如 Isotope、Masonry.js）。
- ✅ 适用：
column-count: 3+column-gap的原生多列布局 - ❌ 不适用：绝对定位、
display: grid的 masonry（目前仅 Firefox 支持）、任何 JS 插件生成的布局 - ⚠️ 注意：
:nth-child(2n)这类偶数选择器在瀑布流里会跳列，推荐用:nth-child(n)线性递增
递增延迟的 CSS 写法与常见错误
核心是把 animation-delay 和 n 关联起来，但不能直接写 animation-delay: 0.1s * n（CSS 不支持运算）。得用预设的多个选择器覆盖前 N 个元素：
.grid-item {
opacity: 0;
transform: translateY(20px);
animation: fadeInUp 0.4s cubic-bezier(0.175, 0.885, 0.32, 1.275) forwards;
}
.grid-item:nth-child(1) { animation-delay: 0.05s; }
.grid-item:nth-child(2) { animation-delay: 0.1s; }
.grid-item:nth-child(3) { animation-delay: 0.15s; }
.grid-item:nth-child(4) { animation-delay: 0.2s; }
/* ……依此类推，一般覆盖到 12–24 项足够 */
@keyframes fadeInUp {
to { opacity: 1; transform: translateY(0); }
}- 延迟步长建议 0.05–0.1s，太小看不出递进，太大导致首屏加载过慢
- 别用
:nth-of-type()——如果瀑布流里混有其他标签（如<h3>标题），序号会断层 - 动画时间（
0.4s）要明显短于最大延迟（比如第 20 项是1s），否则后几项看起来像卡住
滚动加载时如何保持延迟逻辑不崩
新插入的元素如果直接 append 到父容器末尾，:nth-child() 序号会自然延续，动画延迟也跟着顺延——这是最省事的情况。但如果用 innerHTML += ... 或框架（如 React）批量更新，可能触发整个列表重渲染，所有 nth-child 重算，导致已显示的元素再次闪动。
立即学习“前端免费学习笔记（深入）”；
- ✅ 安全做法：每次只 append 单个
.grid-item节点（parent.appendChild(item)） - ❌ 危险做法：替换整个
innerHTML，或用React.createElement一次性挂载 20 个新项 - ? 补救方案：给新元素加临时 class（如
is-new），只对它设animation-delay，避免影响旧元素
真正麻烦的是混合了 JS 布局插件的场景——此时 :nth-child() 和视觉顺序彻底脱钩，只能改用 IntersectionObserver + 手动记录索引，或者放弃递增延迟，改用 stagger 动画库（如 GSAP）来控制。
