直接在父元素加transition对子元素无效，因为css过渡只作用于自身显式声明变化的属性，不继承或代理到子元素；子元素需单独声明transition才能生效。
为什么直接在父元素加 transition 对子元素无效
很多人以为给父容器加 transition: all 0.3s，里面所有子元素的 transform 或 opacity 变化就会自动过渡——实际不会。CSS 过渡只作用于**被显式声明变化的属性所在元素本身**，父元素的过渡规则不会“继承”或“代理”到子元素上。
常见错误现象：div.parent { transition: opacity 0.3s; }，然后 JS 改 div.child.style.transform = 'scale(1.2)'，结果子元素毫无过渡效果。
- 过渡触发的前提是：目标元素的**可动画属性发生了值变化**（且该属性在该元素上有对应
transition声明） - 父元素的
transition只监控它自己的属性（如background-color、height），不监听子元素状态 - 即使父元素重排导致子元素位置/尺寸间接变化，那也属于 layout effect，不是 CSS transition 覆盖范围
真正能“批量控制”的两种可靠方式
想让多个子元素统一响应某类变化（比如 hover 时全部淡入+上移），必须把过渡声明落到每个需要动的子元素上，但可以借助 CSS 机制减少重复书写。
-
用选择器批量绑定：比如
.item, .item:nth-child(2), .item:nth-child(3) { transition: opacity 0.2s, transform 0.2s; }，或更简洁地用.container .item { transition: opacity 0.2s, transform 0.2s; } -
用自定义属性 + calc 驱动延迟差：配合
transition-delay: calc(var(--i) * 0.05s)实现逐个入场，此时仍需在每个子元素上声明transition，但动画节奏可由父级变量统一调控 - 避免用
all：它会过渡所有可动画属性（包括意外触发的box-shadow、font-size等），容易卡顿或行为不可控；明确列出需要过渡的属性更安全
父元素过渡唯一有效的使用场景
只有当你要过渡的是**父元素自身属性，并且该变化会自然带动子元素视觉表现**时，才适用。典型例子：
立即学习“前端免费学习笔记（深入）”；
- 父元素
opacity变化 → 子元素跟着淡入淡出（无需子元素自己写transition） - 父元素
transform: scale()变化 → 子元素等比缩放（注意：这属于 transform 的层叠行为，不是子元素自身的 transition 生效） - 父元素
filter: blur()变化 → 整体模糊效果扩散到子元素
这些情况下，子元素“看起来动了”，但实际是被父级渲染层影响的结果，它们自身的 transition 属性完全没参与。如果同时给子元素也加了 transition，还可能和父级效果冲突（比如父缩放 + 子平移，叠加后轨迹难预测）。
JS 驱动时容易忽略的强制重排问题
用 JS 批量修改多个子元素样式（如循环设 el.style.opacity = 0）时，浏览器可能合并渲染，导致过渡不触发。必须手动“打断”：
- 在批量设值前，先读一次任一元素的布局属性（如
el.offsetHeight），强制触发重排 - 或者用
getComputedStyle(el).opacity触发 - 更稳妥的做法是：统一加 class（如
.is-hidden），用 CSS 控制过渡，JS 只负责切换 class —— 这样天然规避重排时机问题
复杂点在于：过渡节奏一致性依赖 DOM 结构稳定性和 class 命名约束，一旦子元素动态增删，就得同步管理 class 切换逻辑，不能只靠父元素 CSS 偷懒。
