核心问题是 scrollWidth 计算时机不当和元素渲染未完成，导致进度条数值不准；需在 load 事件或图片加载后读取，避免 DOMContentLoaded 时误取未布局宽度。
scrollWidth 和 clientWidth 差太多，进度条算不准
核心问题不是 JS 写错了，而是你没考虑 scrollWidth 的计算时机和元素渲染状态。常见现象是：页面刚加载时进度条卡在 0%，或者滚动后最大值突然跳变——这是因为 scrollWidth 在 DOM 尚未完全布局（比如图片未加载、字体未就绪）时读取，返回的是不完整内容宽度。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别在
DOMContentLoaded立即读取，改用load事件或requestIdleCallback延后执行 - 对图文混排的正文，监听
img加载完成后再重算一次：document.querySelectorAll('img').forEach(img => img.addEventListener('load', recalc)) - 避免用
getBoundingClientRect()替代scrollWidth—— 它只反映可视区域尺寸，和滚动总长无关
position: sticky 不生效，滚动时进度条消失
粘性定位失效通常不是 CSS 写错了，而是父容器“截断”了粘性行为。最典型的是父级设置了 overflow: hidden 或 transform（哪怕只是 transform: translateZ(0)），都会创建新的层叠上下文并禁用 sticky。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 逐级检查进度条父元素，运行
getComputedStyle(el).overflow和getComputedStyle(el).transform，确认没有隐式触发层叠上下文 - 如果必须用
overflow: hidden（比如轮播图容器），就把进度条提级到下，用position: fixed+ 手动同步滚动偏移 -
top值必须明确设置（如top: 16px），设为0时容易被顶部导航栏遮挡，视觉上像“消失了”
resizeObserver 监听不到宽度变化，进度条不响应窗口缩放
很多人以为 ResizeObserver 能自动捕获所有尺寸变动，但它默认只监听直接子元素的盒模型变化。如果你把进度条塞进一个 flex 容器里，而该容器的宽度由父级 flex-basis 控制，ResizeObserver 就不会触发——因为它的尺寸变化不是由自身 content-box 改变引起的。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听对象必须是进度条的**直接父容器**，且该父容器需有明确 width（不能全靠 flex 自适应）
- 更稳妥的做法是同时监听
window的resize事件，并用throttle控制频率（比如 100ms 一次） - 不要依赖
ResizeObserver来替代滚动计算逻辑——它只管宽高，不管 scrollHeight 变化；图文加载导致内容高度增长时，仍需重新触发进度计算
移动端 touchmove 里更新进度条卡顿
在 iOS Safari 或安卓 Chrome 中，如果在 touchmove 回调里直接读取 scrollTop 并更新 width，会强制触发同步布局（layout thrashing），导致滚动掉帧。用户感知就是“进度条跟不上手指”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把进度更新挪到
requestAnimationFrame里：requestAnimationFrame(() => updateProgress()) - 避免在
touchmove中调用getBoundingClientRect()或任何触发重排的 API - 用
will-change: transform提前声明进度条是动画元素，让浏览器提前升格为合成层（但别滥用，每个页面最多 2–3 个）
真正难的不是写出能动的进度条，而是让它的数值在各种加载时机、缩放行为、触摸节奏下都保持可信——尤其当文章里插了广告位、视频 iframe、动态字体时，scrollHeight 和 scrollTop 的关系随时可能被第三方脚本悄悄改写。
