原生<progress>标签必须同时设置value和max才能正确渲染确定进度，缺max会进入不确定状态；CSS定制需用伪元素且各浏览器规则不同；JS更新value必须赋数字类型并做边界处理。
原生 <progress> 标签必须同时设 value 和 max 才能渲染确定进度
只写 <progress value="75"> 会导致浏览器按 max="1" 解析，value="75" 直接越界，多数浏览器显示为空白或静默截断为满格。这不是 bug，是规范行为——缺 max 就进入“不确定”状态（条纹动画），和你想表达的「已完成 75%」语义完全不符。
正确写法只有两种：
-
<progress value="75" max="100">（推荐，百分比直观，JS 更新时不用换算） -
<progress value="0.75" max="1">（适合后端直接返回小数，但需确保 JS 赋值时用数字类型，不能传字符串）
漏掉 max 是封装组件时最常导致进度条“不显示”的原因，尤其在 React/Vue 中 props 默认值未设、或 API 返回字段缺失时。
CSS 定制必须用伪元素，且 appearance: none 是前提
直接对 <progress> 设置 background-color 或 color 没效果，它内部结构由浏览器私有渲染。想改轨道或填充色，必须用伪元素，且 WebKit 内核（Chrome/Safari/Edge）和 Firefox 规则完全不同：
立即学习“前端免费学习笔记（深入）”；
- Chrome/Safari：先写
progress { appearance: none; }，再用progress::-webkit-progress-bar控轨道，progress::-webkit-progress-value控填充 - Firefox：只认
progress::-moz-progress-bar，不支持分设轨道/填充，只能整体着色 - IE11 及以下：完全不支持
<progress>，连伪元素都无效，必须降级为<div>方案
别指望一套 CSS 全兼容；如果设计要求严格统一（比如品牌色+圆角+阴影），建议放弃原生标签，用 <div class="progress-bar"><div class="progress-fill"></div></div> 手动实现。
JavaScript 更新 value 必须赋数字，不能用字符串
progress.value = "50" 或 progress.setAttribute('value', '50') 都不会触发重绘——前者是无效类型赋值，后者只改 HTML 属性，不更新 DOM 的 value 属性值。
实操要点：
- 从表单控件读值后，务必转数字：
Number(input.value)或一元加号+input.value - 从 fetch/XMLHttpRequest 的
onprogress事件计算时，用Math.round((loaded / total) * 100)，再做边界截断：Math.min(Math.max(0, percent), 100) - 避免高频更新：上传中每毫秒触发一次
bar.value = ...会卡顿，建议用requestAnimationFrame或至少 50ms 间隔节流
动态更新时最容易忽略的是完成态处理——很多逻辑只在 loaded === total 时设 bar.value = 100，但网络波动可能导致 loaded 瞬间跳到 > total，不截断就会触发异常渲染。
需要显示百分比文本或双轨对比时，原生 <progress> 不适用
<progress> 本身不渲染任何文字，<progress value="70">70%</progress> 中的 “70%” 只是 fallback 内容，仅当浏览器完全不支持该标签时才显示，且屏幕阅读器无法识别为进度值。
要显示实时百分比，必须额外加一个 <span> 并用 JS 同步更新其 textContent，同时配 aria-live="polite" 让辅助技术播报变化。
而双轨对比（如「当前值 vs 目标值」「A 组 62% vs B 组 85%」）更没法用单个 <progress> 实现——它只支持单值线性进度。此时必须用两个独立的 <div class="progress-bar"> 容器，各自控制 width，并注意：
- 容器设
overflow: hidden，防止子条溢出 - 用行内
style.width或 JS 动态设置，CSS 类里写死宽度无法响应数据 - 数值归一化后务必校验边界，否则负数或超 100% 会撑破布局
原生标签的高可用，不在于它多灵活，而在于你清楚它的边界——什么时候该用，什么时候必须弃用。真正容易翻车的，从来不是写法本身，而是误判了它的能力范围。
