原生标签需手动更新value才能显示进度，正确写法是el.value=30而非setAttribute；必须设max="100"并用Math.round()处理精度；推荐PerformanceObserver按资源耗时占比计算，Fallback方案可用关键资源数量比例，并加超时兜底。
原生 <progress></progress> 标签不能自动显示页面加载进度，它只是个空壳；真要让百分比动起来，必须自己跟踪资源、计数、更新 value —— 否则你看到的永远是静止的 0%。
为什么 <progress value="0"></progress> 什么也不发生
浏览器不把 HTML 解析、CSS 下载、JS 执行、图片加载这些过程映射到 <progress></progress> 的 value 上。它只认两个数字属性：value 和 max，且必须手动赋值才生效。setAttribute("value", "30") 是无效的——那只是改 HTML attribute，不会触发 DOM 属性更新和渲染；正确写法是 el.value = 30。
常见翻车点：
- 没设
max="100"，依赖默认值，结果后端返回小数（如0.73）时直接赋值导致进度条溢出或卡死 - 在
img.onload回调里直接写progress.value = count / total * 100，但没做Math.round()，导致小数精度问题（如99.99999999999999卡在 99%） - 用
document.readyState判断，但它只有"loading"/"interactive"/"complete"三态，没法线性映射到 0–100%
用 PerformanceObserver 捕获真实资源加载占比
这是目前最接近“真实进度”的方案，尤其适合 Chrome 80+ 及现代 Edge。它能拿到每个资源的 startTime 和 duration，结合 navigationStart 可估算相对耗时占比。
立即学习“前端免费学习笔记（深入）”；
关键实操点：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 必须在
最早位置初始化，否则会错过首屏 CSS、字体等关键资源 - 过滤掉
initiatorType === "xmlhttprequest"的条目——那是 API 请求，不属于页面初始加载资源 - 只统计
entry.initiatorType === "navigation" || "link" || "script"的资源（即 HTML、CSS、同步 JS、内联脚本） - 动态插入的资源（如懒加载
img、import()）需单独监听load事件并计入总完成数
示例片段（简化）：
const observer = new PerformanceObserver((list) => {
const entries = list.getEntries().filter(e =>
e.entryType === "resource" &&
["navigation", "link", "script"].includes(e.initiatorType)
);
const totalDuration = entries.reduce((sum, e) => sum + e.duration, 0);
const loadedDuration = entries.filter(e => e.duration > 0).reduce((sum, e) => sum + e.duration, 0);
const percent = Math.round((loadedDuration / Math.max(totalDuration, 1)) * 100);
progress.value = Math.min(percent, 100);
});
observer.observe({ entryTypes: ["resource"] });用资源数量比例做轻量 fallback 方案
当目标环境不支持 PerformanceObserver（如旧版 Safari），或页面资源结构简单（比如以图片为主），可用数量计数法：预列关键资源，监听 load/error 事件。
注意边界条件：
- 只统计
document.querySelectorAll('img, link[rel="stylesheet"], script:not([async]):not([defer])')，忽略async/defer脚本（它们不阻塞解析，不应算进“页面加载”主路径） -
link[rel="preload"]需单独加入队列，否则进度会提前结束 - 图片
srcset或picture中的多个源，按实际加载的那个算 1 个，别重复计数 - 务必加超时兜底（如 8s 后强制设为 100%），防止某个资源挂起导致进度条卡死
transform: scaleX() 比 width 更稳的动画写法
用 JS 频繁改 width 会触发重排，尤其在低端安卓机上容易掉帧；transform: scaleX(n) 是合成层操作，性能更好。
但要注意兼容细节：
- iOS 15 之前对
scaleX(0)有渲染 bug，起始值建议设为scaleX(0.001) - 别在
load回调里直接改样式，先缓存当前百分比，再用requestAnimationFrame统一提交 - 如果用
<progress></progress>，它的内部 track 渲染由浏览器控制，无需手动加 transform；但自定义<div class="bar"> 时，必须走 transform 路线<p>真正难的不是让进度条动起来，而是定义清楚「什么才算加载完成」——是 HTML 解析完？首屏 CSS 生效？还是所有 <code>img和字体都到位？不同业务目标，监控粒度和兜底策略完全不同。漏掉一个异步资源，或者误判一个defer脚本，百分比就失真了。
