纯CSS用@keyframes控制width仅能模拟视觉进度，无法反映真实加载状态；必须由JS触发开始、中断与完成，否则易出现“假跑”或“卡死”，且需JS兜底设width:100%并重置动画。
纯 CSS 用 @keyframes 控制 width 实现加载进度条，只能模拟“视觉进度”，不能反映真实资源加载状态；真要对齐页面加载时机，必须靠 JS 触发开始、中断和完成——否则动画跑完但页面还没 ready，用户会觉得假。
为什么width动画在加载场景下容易失准
硬写 animation: progress 2s linear forwards 看似简单，但实际加载时间波动大：首屏 JS/CSS 可能 300ms 加载完，图片却要 1.8s 解码。动画一跑到底，就会出现“进度条早到 100%，但按钮还点不了”或“动画卡在 80% 不动”的情况。
-
width动画依赖父容器有明确宽度（比如100%或固定值），若父级是flex或grid且未设min-width，动画可能跳变或不触发 - 初始状态没显式写
width: 0，浏览器会从默认auto计算，导致重排+闪动 - 动画结束时仅靠
forwards不够稳：JS 错误或执行延迟会导致width残留旧值，必须手动兜底el.style.width = '100%'
如何让@keyframes + width真正可用
核心是把 CSS 当“渲染层”，JS 当“控制层”。CSS 只负责定义动画节奏和终态样式，JS 负责决定何时启动、何时收尾。
- 关键帧必须显式定义起点和终点：
@keyframes progress { 0% { width: 0%; } 100% { width: 100%; } } - 进度条元素初始要设
width: 0，并禁用过渡（避免与动画冲突）：.progress-bar { width: 0; transition: none; } - 启动动画用类名切换：
el.classList.add('loading')，对应 CSS 中.loading { animation: progress 800ms linear forwards; } - 收尾不用等动画自然结束，监听
window.addEventListener('load', ...)后立刻移除类、设宽、清动画：el.classList.remove('loading'); el.style.width = '100%'; el.style.animation = 'none';
移动端和高分屏下的常见坑
在 iOS Safari 或 Windows 高 DPI 屏上，width 动画容易卡顿或跳帧，尤其配合 border-radius 或 box-shadow 时。
立即学习“前端免费学习笔记（深入）”；
- 别给进度条加
border-radius再做width动画——圆角会触发重绘，iOS 上明显掉帧 - 高度慎用
1px：高分屏下可能渲染为 0.5px，视觉断开；建议用height: 2px或transform: scaleY(0.5) - 避免在
transform父容器里嵌套进度条，width动画在will-change: transform下可能被降级为 CPU 渲染 - 如果父容器用了
overflow: hidden，确保其height固定，否则width动画过程中可能触发 layout 波动
真正难的不是写对那几行 @keyframes，而是让 JS 的加载钩子足够健壮：比如资源加载失败时怎么回退、SPA 路由跳转时怎么复位、服务端渲染（SSR）首屏怎么避免闪动——这些都得绕开 CSS 动画的局限性去设计。
