必须用position: fixed，因其天然锚定视口、不随滚动偏移；absolute会随父容器滚动消失，sticky无法线性映射滚动比例，且fixed兼容所有现代浏览器。
顶部进度条必须用 fixed 定位，transform-origin 只影响缩放/旋转基点，对滚动进度本身无作用——它不参与百分比计算，也不能替代 scrollTop 读取逻辑。
为什么必须用 position: fixed 而不是 absolute 或 sticky
进度条要始终贴着视口顶部，不受文档流和滚动影响：absolute 会随父容器滚动而消失；sticky 只能“粘住”某个临界点，无法线性映射滚动比例。只有 fixed 天然锚定 viewport，且兼容性覆盖所有现代浏览器（包括 iOS Safari 15.4+）。
常见错误是把进度条包在某个 section 或 main 里设 absolute，结果一滚就不见——因为它的定位上下文错了。
-
top: 0; left: 0; right: 0; height: 2px;是最简安全写法 - 别漏掉
z-index: 9999，否则可能被弹窗、广告遮挡 - 移动端需额外加
will-change: transform防止 Safari 渲染抖动
transform-origin 在进度条里起什么作用
它只在你用 transform: scaleX() 实现宽度变化时才有意义。比如设 transform-origin: 0 50%，表示缩放以左边缘为原点、垂直居中对齐——这样 scaleX(0.3) 就是从左往右撑开 30%，视觉上更符合“进度推进”直觉。
立即学习“前端免费学习笔记（深入）”；
但注意：transform-origin 本身不驱动进度，也不影响 scrollHeight 计算。它只是个辅助视觉锚点。
- 若用
style.width = '30%'，transform-origin完全无关 - 若用
transform: scaleX(0.3)，必须配transform-origin: 0 50%，否则默认从中心缩放，进度条会左右同时扩展 - 不要设
transform-origin: 50% 50%—— 这会让进度条“从中间炸开”，不符合阅读习惯
滚动百分比计算的三个关键陷阱
真实滚动距离不是 document.body.scrollTop，也不是 window.scrollY 单一来源，而是：
const scrollTop = Math.max(document.body.scrollTop, document.documentElement.scrollTop);
分母也容易错：document.documentElement.scrollHeight - window.innerHeight 才是可用滚动高度，用 document.body.scrollHeight 在 Chrome/Firefox 标准模式下会偏小。
- iOS Safari 对
scrollHeight有轻微浮点误差，建议兜底：Math.min(progress, 100) - 别在
onscroll里读取offsetHeight或getBoundingClientRect()，会强制同步布局，拖慢帧率 - 直接写
element.style.width = progress + '%'比切换 class 更快，避免样式重计算
Chrome 115+ 的 animation-timeline: scroll() 能否替代 JS
可以，但仅限简单场景：它依赖 CSS 滚动驱动动画（Scroll-Driven Animations），目前只在 Chromium 系（Chrome/Edge）支持，Firefox 和 Safari 仍无计划落地。
写法看似简洁：animation-timeline: scroll(); animation-range: 0% 100%;，但实际调试困难——无法动态响应 resize 或内容增删导致的 scrollHeight 变化，且不支持 iOS。
- 生产环境建议优先用传统 JS 方案，兼容性和可控性更强
- 若用
animation-timeline，必须确保滚动容器是body或documentElement，不能是局部 div - 别指望它自动处理
Math.min(progress, 100)，超 100% 时动画会卡死或回跳
真正难的不是定位或缩放，而是滚动距离与视口高度的差值计算是否稳定——尤其当页面动态插入内容、或使用第三方 UI 库修改 DOM 时，scrollHeight 可能异步更新，需要监听 resize 和 MutationObserver 做补偿。
