@starting-style 不能解决入场过渡问题，截至2024年底仍处于CSS WG草案阶段，所有主流浏览器均未实现，仅曾存在于Chrome 111–115实验性flag中且已被移除。
什么是 @starting-style，它真能解决入场过渡问题？
不能。截至 2024 年底，@starting-style 仍处于 CSS WG 的草案阶段，**所有主流浏览器（Chrome、Firefox、Safari）均未实现该规则**。你查到的 demo 或教程，大概率是基于早期 Chromium 实验性 flag（如 Chrome 111–115 的 --enable-blink-features=StartingStyle），但该 flag 已被移除。试图在生产环境写 @starting-style 不会生效，也不会报错——它只是被完全忽略。
为什么开发者会误以为它“可用”？
常见混淆来源有三个：
- 把
@starting-style和已落地的view-transitionAPI 混为一谈（后者靠document.startViewTransition()触发，与样式规则无关） - 看到 Can I Use 上标记为 “No support”，却误读成 “部分支持”
- 在 CodePen 或本地开启过时 flag 后看到效果，误判为稳定特性
现在想做可靠入场过渡，该用什么？
用 animation + opacity/transform 组合，配合 JS 控制触发时机，仍是唯一跨浏览器方案。关键点不是“等新语法”，而是避免常见陷阱：
- 别在元素初始 HTML 中就设
opacity: 0，否则 SSR 渲染时内容不可见；应由 JS 动态添加 class 触发动画 - 用
will-change: opacity, transform提前提示合成层，避免动画卡顿 - 动画时长建议 ≥ 200ms，短于 100ms 的入场人眼难以感知，还可能因渲染延迟显得突兀
- 对服务端渲染（SSR）/静态站点，需在
DOMContentLoaded后再添加动画 class，防止 FOUC
/* 示例：安全的入场动画 */
.fade-in {
opacity: 0;
transform: translateY(10px);
animation: fadeIn 0.3s ease forwards;
}
@keyframes fadeIn {
to {
opacity: 1;
transform: translateY(0);
}
}要不要现在学 @starting-style？
可以看草案了解设计意图（比如它想解决“初始状态不可样式化”的根本限制），但别写进项目代码。真正要关注的是：如何用现有工具链（CSS 动画 + IntersectionObserver + 适当的 JS 触发逻辑）把入场过渡做得更自然、更可访问、更少闪跳——这些细节，比等待一个尚未落地的语法重要得多。
立即学习“前端免费学习笔记（深入）”；
