标签需确保value和max为数字类型，用requestAnimationFrame节流更新，IE需降级为div+CSS；自定义样式须兼容WebKit/Firefox伪元素；手写进度条必须添加role="progressbar"及aria属性；上传进度需校验event.lengthComputable并确认后端返回Content-Length。
HTML 原生 <progress></progress> 标签怎么用才不卡顿
直接上结论：<progress></progress> 是语义正确、开箱即用的原生进度条，但默认样式丑、IE 不支持、动态更新时容易卡在 0% 或跳变——关键不是“能不能用”，而是“怎么让它响应真实进度”。
常见错误现象：value 设为变量但没触发重绘；max 和 value 都是字符串导致计算出错；在 JS 循环里高频设 value 却没节流，页面卡死。
- 必须确保
value和max都是数字类型（parseInt()或Number()转一下） - 批量更新时别在 for 循环里直接改
value，用requestAnimationFrame()或setTimeout(..., 0)让浏览器有机会渲染 - IE11 及以下完全不支持
<progress></progress>，需降级为<div> + CSS 宽度模拟（别用 <code>filter: progid:DXImageTransform.Microsoft.Alpha，已失效）示例（安全更新）：
<progress id="bar" max="100" value="0"></progress>
const bar = document.getElementById('bar'); let progress = 0; function update() { if (progress >= 100) return; progress += 1; bar.value = Number(progress); // 强制转数字 requestAnimationFrame(update); // 避免阻塞主线程 } update();CSS 自定义
<progress></progress>样式时为什么伪元素不起作用因为不同浏览器对
::-webkit-progress-bar、::-moz-progress-bar、::progress-value的支持差异极大，且伪元素层级和继承规则反直觉。立即学习“前端免费学习笔记（深入）”；
使用场景：想改成圆角、渐变色、去掉默认边框、加文字标签。
- Chrome/Edge 必须用
::-webkit-progress-bar和::-webkit-progress-value，且value伪元素不能设display: block，否则宽度计算失效 - Firefox 仅支持
appearance: none+background整体覆盖，无法单独控制“已加载部分” - 所有浏览器下，
<progress></progress>默认是 inline 元素，若要居中或设宽高，得先display: block
最小可行自定义（Chrome + Firefox 兼容）：
progress { height: 8px; border-radius: 4px; overflow: hidden; background: #e0e0e0; } progress::-webkit-progress-bar { background: transparent; } progress::-webkit-progress-value { background: #4CAF50; border-radius: 4px; } progress::-moz-progress-bar { background: #4CAF50; }不用
<progress></progress>时，纯 CSS +aria-valuenow怎么做可访问进度条当需要兼容 IE 或精确控制动画曲线（比如缓动函数），就得手写
<div> 进度条，但很多人漏掉无障碍支持，导致屏幕阅读器读不出当前进度。<p>性能影响：用 <code>transform: scaleX()比直接改width更高效（避免 layout）；但必须配will-change: transform防止低端机掉帧。- 必须加
role="progressbar"、aria-valuenow、aria-valuemin、aria-valuemax四个属性，缺一不可 -
aria-valuenow要随 JS 实时更新，不能只靠初始值 - 视觉进度条容器需设
overflow: hidden，内部条用transform: scaleX()动画，避免重排
简短结构示例：
<div role="progressbar" aria-valuenow="35" aria-valuemin="0" aria-valuemax="100"> <div class="progress-inner"></div> </div>
.progress-inner { height: 100%; width: 100%; background: #2196F3; transform-origin: left center; transform: scaleX(0.35); will-change: transform; }上传文件时用
XMLHttpRequest.upload.onprogress更新进度，为什么经常到 99% 就停住这不是 UI 问题，是 HTTP 协议层行为：浏览器上报的
loaded值包含请求头，而服务端返回的响应体还没开始接收，所以前端认为“上传完成”，实际后端还在处理。容易踩的坑：
event.lengthComputable为false时硬算百分比会出 NaN；服务端没设Content-Length响应头，导致前端无法判断总大小；跨域请求没配Access-Control-Allow-Headers: Content-Length。- 务必先判断
event.lengthComputable === true再算百分比 - 后端接口必须返回明确的
Content-Length（哪怕只是预估），否则前端只能显示“上传中…”而非具体进度 - 如果用
fetch，它原生不支持上传进度，得用XMLHttpRequest或封装ReadableStream+pipeTo（仅现代浏览器）
关键判断代码：
xhr.upload.onprogress = function(event) { if (!event.lengthComputable) return; // 别硬算 const percent = Math.round((event.loaded / event.total) * 100); progressBar.value = percent; };事情说清了就结束。最常被忽略的是：进度条是否反映真实瓶颈——上传卡在 99%，可能不是前端问题，而是后端鉴权或压缩耗时；UI 更新再顺滑，也掩盖不了服务端延迟。
- Chrome/Edge 必须用
