标签需手动控制value才能实现真实加载进度；浏览器不自动映射解析、下载等过程，常见错误包括字符串赋值、未设max、用setattribute更新、阻塞主线程；应结合readystatechange、load事件、performanceobserver及超时兜底来精准反馈。
progress 标签本身不能自动监听页面加载进度，它只是个被动容器；真要做出“网页加载中”的百分比条，必须手动跟踪资源、预估阶段、控制更新节奏——否则你写的只是个静态数字，不是进度反馈。
为什么直接写 <progress value="0"></progress> 什么也不发生
浏览器不会主动把 HTML 解析、CSS 下载、图片加载这些过程映射到 value 上。value 是纯手动赋值的属性，不监听任何事件。常见翻车点：
-
value和max写成字符串（如value="50"），部分浏览器忽略或转为 0 - 只设
value没设max，max默认为 1，导致value="70"实际显示为 100% - 用
setAttribute("value", "50")更新——这改的是 HTML attribute，不触发 UI 重绘，必须用el.value = 50 - 在
for循环里连续赋值bar.value = i++，主线程被阻塞，页面假死
用 document.readyState 模拟进度时怎么避免硬编码
它只有 "loading" / "interactive" / "complete" 三态，没法直接映射 0–100%。强行写 if (readyState === 'loading') bar.value = 20 会因页面结构差异完全失准。更可行的做法是：
- 起始插入进度条时设
value="10"，给人“已启动”感知 - 监听
readystatechange，在"interactive"阶段设到85左右（DOM 就绪但资源未完） - 等
window.addEventListener('load', ...)触发后，再平滑过渡到100，300ms 后移除元素 - 全程用
requestAnimationFrame更新，别用setTimeout，尤其别设50ms这种固定间隔
想真实反映资源加载，该用 PerformanceObserver 还是手写钩子
PerformanceObserver 是目前最可靠的方案（Chrome 59+、Firefox 73+、Safari 11+），但它不是“开箱即用”的进度源：
- 必须在
最早位置初始化，否则会错过 navigationStart 后前几百毫秒的关键资源记录 - 过滤掉
initiatorType === 'xmlhttprequest'或'fetch'的条目，它们属于 API 请求，不算页面加载资源 - 初始资源数建议用
document.querySelectorAll('script, link[rel="stylesheet"], img:not([data-src])')统计，再配合 observer 计数完成量 - 最后 5–10% 要留白——JS 执行、布局计算、字体渲染等无法被 observer 捕获，硬填会导致进度卡住
自定义样式时伪元素失效的真正原因
不是写法错，是浏览器引擎根本没给你留一致的接口：
- Chrome/Edge 必须用
::-webkit-progress-bar+::-webkit-progress-value，且后者不能设display: block - Firefox 只认
::-moz-progress-bar，::-moz-progress-value基本不可靠，推荐整块覆盖背景色 - Safari 对伪元素支持最保守，
appearance: none是前提，否则自定义会被忽略 - 所有浏览器下，
<progress></progress>默认是inline元素，要设宽高必须先加display: block - 别在伪元素上用
background-image，多数失效；优先用background: linear-gradient()
最易被忽略的点：移动端 iOS Safari 在手指抬起前，scrollTop 不更新，导致滚动进度条卡在 98%；而页面加载进度条若依赖 load 事件，在资源失败时可能永远不收尾——必须配超时兜底，比如 8 秒强制完成动画并移除 DOM。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
