progress.value必须是数字类型，字符串会导致进度条卡在0%；max缺省值为1而非100，须显式设置；动态更新宜用css类切换替代直接赋值。
progress.value 必须是数字，字符串会失效
浏览器只认 value 属性的数值类型，写成 value="75" 或 JS 里赋值 el.value = "75"（带引号）——看似一样，实则进度条永远卡在 0%。这是跨端不一致的根源之一：部分 WebView（如旧版 Android 系统内置浏览器）甚至不报错，直接静默忽略。
正确做法只有两种：
-
el.value = 75（推荐，走原生表单控件逻辑，重绘更及时） -
el.setAttribute("value", 75)（兼容性略差，某些 Safari 版本可能不触发 UI 更新）
注意：如果后端返回的是字符串（如 API 返回 {"progress": "82"}），必须显式转数字：el.value = parseInt(data.progress, 10) 或 el.value = +data.progress。
max 不设就是 1，不是 100 —— 这点在 iOS Safari 里特别容易翻车
很多开发者默认 max="100" 是“常识”，但规范里 max 缺省值是 1。这意味着：<progress value="80"></progress> 在 iOS Safari 中会满格（因为 80 > 1），而 Chrome 可能显示异常窄条或直接截断为 1。
跨端统一做法：
- 始终显式设置
max，且优先用整数max="100"，语义清晰、调试直观 - 避免小数
max="1"配合value="0.8"，虽然合法，但在低版本 Android WebView 中易出现精度丢失或渲染跳变 - 服务端若返回的是 0–1 小数范围进度，前端应统一乘以 100 再赋值：
el.value = Math.round(progress * 100)
动态更新频繁时，别直接改 value —— 换 class 切换更稳
每 50ms 调一次 el.value = i（比如模拟上传进度），在 Chrome 下 ::-webkit-progress-value 的 width 动画可能掉帧；Firefox 根本不支持 transition 在 ::-moz-progress-bar 上生效，结果就是卡顿或突变。
替代方案是预设 CSS 类，JS 只控制 class：
- CSS 里定义：
.progress-0 { --p: 0; } .progress-30 { --p: 30; } .progress-65 { --p: 65; } - JS 只做：
el.className = 'progress-' + Math.round(value / 10) * 10 - 再用
progress::before或伪元素结合width: calc(var(--p) * 1%)（需配合appearance: none）驱动视觉变化
这个模式绕开了浏览器对 value 属性变更的重绘机制差异，实测在 iOS 14+、Android 8–12 WebView、Edge 90+ 全部平滑。
IE 和老 Edge 需降级，但别用 document.createElement('progress')
<progress></progress> 在 IE10+ 原生支持，但样式完全不可控，且无伪元素；真正要兼容 IE9 及更早，不能靠 polyfill 标签本身，而是用 DOM 替代结构。
错误做法：document.createElement('progress') 加 fallback 标签（如 <ie></ie>）——现代构建工具（Vite/Webpack）会把自定义标签当无效节点处理，导致 SSR 渲染失败或 hydration 错误。
可行路径：
- 检测
'value' in document.createElement('progress')，不支持则插入<div class="fallback-progress"><span style="width: 0%"></span></div> - 用 ARIA 属性同步状态：
aria-valuenow、aria-valuemin、aria-valuemax，保障读屏器可用 - 样式上复用同一套 CSS 变量（如
--progress-width），让两类结构视觉一致
真正难的不是写兼容代码，而是记住：progress 的 value 不是“看起来像数字”就行，它必须是运行时的 number 类型；而跨端一致性，往往毁于一个没转类型的字符串和一个被遗忘的 max。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
