原生 progress 元素无法真正实现平滑填充动画，Chrome 可通过 ::-webkit-progress-value 配合 transition 实现，Firefox 不支持；推荐用语义化 div 模拟进度条，结合 width transition 与 aria 属性保障兼容性、性能和可访问性。
用 progress 元素配合 CSS transition 实现平滑填充
原生 progress 元素本身不支持动画，直接改 value 会瞬跳。必须靠 CSS 的 transition 驱动伪元素（如 ::-webkit-progress-bar）或包裹容器的视觉变化。
关键点是：不能只给 progress 加 transition，要作用在它的内部轨道或进度条上。Chrome/Edge 用 ::-webkit-progress-value，Firefox 用 ::progress-bar，但后者不支持 transition，所以实际得用 JS 控制一个覆盖层或改用 div 模拟。
- 推荐方案：用
div+aria-valuenow替代原生progress，完全可控 - 若坚持用原生，Chrome 下可对
::-webkit-progress-value设置transition: width 0.3s ease - Firefox 不支持伪元素宽度过渡，此时原生
progress无法真正“动画填充”，只能靠 JS 插值+重绘
用 div 模拟进度条并手动控制动画节奏
脱离浏览器兼容限制最稳妥的方式：用两个嵌套 div，外层固定宽高设 overflow: hidden，内层用 width 表示进度，并通过 transition 或 @keyframes 触发动画。
注意：transition 适合从 A 值到 B 值的线性变化；如果需要加载中“流动”效果（比如骨架屏那种），就得用 @keyframes 配合 background-position 移动渐变背景。
立即学习“前端免费学习笔记（深入）”；
- 基础填充动画：
transition: width 0.4s cubic-bezier(0.25, 0.46, 0.45, 0.94)比ease更自然 - 动态更新时，确保每次只改一次
style.width，避免强制同步布局（layout thrashing） - 加上
aria-valuemin、aria-valuemax、aria-valuenow保持可访问性
用 CSS @keyframes 做“加载中”流动效果
当进度值未知（比如上传中、初始化阶段），需要的是视觉反馈而非精确百分比，这时用带位移的线性渐变背景最轻量。
原理是固定背景尺寸，用 background-position 持续偏移，制造“光效扫过”的感觉。不依赖 JS，无重排重绘压力，兼容性也比 progress 伪元素好得多。
- 核心代码：
background: linear-gradient(90deg, transparent, rgba(0,0,0,0.1), transparent); background-size: 200% 100%; animation: shine 2s infinite; @keyframes shine { to { background-position-x: 200%; } }- 该效果不能表示具体数值，仅作 loading 状态使用；若需数值+流动双模式，建议用 JS 切换 class
JS 更新进度时卡顿或跳变的常见原因
即使 CSS 写对了，JS 层更新频率或方式不对，也会导致动画不连贯。典型问题不是样式本身，而是触发时机和粒度。
例如监听 XMLHttpRequest.upload.onprogress 时，原生事件可能每几十 ms 才触发一次，但若每次都直接赋值 element.style.width = xx + '%'，浏览器来不及渲染就会丢帧。
- 用
requestAnimationFrame节流更新，确保每帧最多一次 DOM 写入 - 避免在循环里连续读写
offsetWidth等触发 layout 的属性 - 不要用
setTimeout(..., 0)模拟动画，它不受帧率约束，容易堆叠任务 - 如果后端返回的是离散阶段（如 “连接中→校验中→写入中”），建议用 CSS class 切换 + 过渡，而非硬算百分比
真正难的不是写出第一版动画，而是让不同浏览器下行为一致、在低性能设备上不掉帧、在语义化和可访问性不妥协的前提下保持轻量。很多项目最后回到 div + transition + aria- 属性组合，就是权衡后的结果。
