<p>必须用JS计算window.scrollY / (document.documentElement.scrollHeight - window.innerHeight)并节流更新，因<progress>标签无法自动响应滚动，纯CSS方案兼容性差且无法处理动态内容与边界情况。</p>
滚动进度指示不是加个 <progress> 标签就能自动工作的——它必须靠 JS 实时计算当前滚动位置占整个可滚动高度的比例，并用节流方式更新 DOM，否则要么卡顿、要么跳变、要么永远不到 100%。
怎么算出准确的 0～1 进度值
核心公式是：window.scrollY / (document.documentElement.scrollHeight - window.innerHeight)。这个比值才是真实归一化进度。
- 别用
document.body.scrollHeight，它在某些文档模式下不可靠；document.documentElement.scrollHeight才是标准根元素高度 - 分母必须减去
window.innerHeight，否则拉到底部时结果常为 0.97～0.99，永远卡在 97% - macOS 隐藏滚动条但
scrollHeight仍含其占位空间，所以结果可能略超 1；务必套一层Math.min(1, Math.max(0, progress))截断 - IE11 不支持
scrollY，得降级用document.body.scrollTop || document.documentElement.scrollTop
为什么直接绑 scroll 事件会卡顿
原生 scroll 事件在快速滚动时每秒触发上百次，JS 同步读取 scrollY + 更新样式 = 主线程过载，页面掉帧。
- 禁止写
window.addEventListener('scroll', () => { updateProgress() }) - 改用
requestAnimationFrame节流：只在下一帧重绘前读一次值，天然限制在 60fps - 不要在回调里直接改
element.style.width或progress.value，先存变量，再统一提交 - 加最小更新阈值，比如只有新进度与上次渲染值差 ≥ 0.3% 才真正触发 DOM 更新，避免微小抖动
用 transform: scaleX() 替代 width 动画
transform: scaleX() 触发合成层，不触发重排重绘，比改 width 或 left 高效得多；配合 will-change: transform 可进一步提示浏览器提前优化。
立即学习“前端免费学习笔记（深入）”；
- 别对
<progress>直接设transition: width，它的内部填充是伪元素，各浏览器实现不一致 - 推荐结构：
<div class="progress-track"><div class="progress-fill"></div></div>，只动.progress-fill的transform: scaleX(progress) - 禁用
transition控制scaleX，它会在滚动中明显滞后；动画节奏应由 JS +requestAnimationFrame主导 - 如果要用 CSS 动画兜底（如 JS 失效），可设
transition: transform 0.1s linear，但仅作 fallback，不依赖它做主逻辑
scroll-timeline 能替代 JS 计算吗
不能全替代——目前只有 Chrome 115+ / Edge 115+ 原生支持，Firefox 需手动开启 flag 且功能受限，Safari 完全不识别 @scroll-timeline 规则。
- 若你只面向 Chrome 内核用户，可用
animation-timeline: --my-timeline+@scroll-timeline声明时间轴，省去 JS 计算 - 但 Safari 用户看到的只会是静止状态，没有任何动画；没有降级方案就等于放弃半数移动端流量
- 即使支持，
scroll-timeline也只驱动 CSS 动画，无法同步更新数字文本、触发回调或联动其他逻辑 - 真正稳健的方案仍是 JS 计算 +
requestAnimationFrame节流，兼容性覆盖 100%，控制粒度更细
最容易被忽略的是“视口缩放”和“动态内容加载”：页面加载后又通过 AJAX 插入大段内容，scrollHeight 变了，但进度条没重算；或者用户放大字体导致 innerHeight 实际变化，公式却没响应。这些边界情况必须监听 resize 和内容插入事件，重新初始化进度逻辑。
