原生<progress>标签语义正确但样式控制跨浏览器不一致，Web Component方案更可控；因其天然样式隔离、可复用、能封装状态逻辑，且避免伪元素兼容性差、无法响应更新等问题。
原生 <progress> 标签语义正确、开箱即用，但真要跨浏览器一致控制样式和行为，Web Component 方案反而更可控——它天然隔离样式、可复用、能封装状态逻辑，比一堆全局 CSS 伪元素靠谱得多。
为什么不用纯 CSS 伪元素定制 <progress>
因为各浏览器对 ::-webkit-progress-value、::-moz-progress-bar、::progress-value 的支持差异太大，且 Firefox 对渐变、动画、圆角等支持基本不可靠。你写十行兼容 CSS，可能只在 Chrome 里生效；加个 background-image 或 clip-path，Firefox 直接忽略。更麻烦的是：这些伪元素无法响应属性变化做细粒度更新，也不能绑定事件或暴露方法。
- Chrome/Safari 只认
::-webkit-progress-value，且必须设background-color，background-image大概率失效 - Firefox 的
::progress-value是实验性支持，很多版本压根不渲染 - 所有浏览器下，
<progress>默认是display: inline，不显式设block或flex，宽度控制会出错 - IE11 及以下完全不支持，降级方案还得额外写一套
<div>逻辑
用 class + <div> 手写 Web Component 的最小结构
核心不是“重造轮子”，而是把进度逻辑和 DOM 更新收束到一个自定义元素里，避免污染全局样式和 JS 状态。结构上只需容器 + 进度条两个 <div>，再用 customElements.define() 注册即可。
- 容器设
overflow: hidden防止进度条溢出 - 进度条用
height: 100%+background，别依赖border或box-shadow做主视觉 - 动画统一用
transition: width 0.3s ease，transform: scaleX()在旧安卓 WebView 中有渲染撕裂风险 - 需要圆角时，容器和进度条都设相同
border-radius，否则边缘露白
<div class="progress-container"> <div class="progress-bar" style="width: 60%;"></div> </div>
customElements.define() 封装的关键点
Web Component 不是炫技，重点是把易错逻辑收口：数值校验、节流更新、无障碍属性注入、以及 IE 兜底（虽然现在基本不用了，但留个 isLegacy 判断很轻量）。
立即学习“前端免费学习笔记（深入）”；
- 接收
value和max属性，内部强制转为数字：Number(this.getAttribute('value') || 0) - 用
requestAnimationFrame节流更新，避免高频 setAttribute 卡死主线程 - 自动添加
role="progressbar"、aria-valuenow、aria-valuemax，满足基础可访问性 - 支持
color、height、rounded等 HTML 属性直接控制外观，不依赖外部 CSS 类
示例用法：
<custom-progress value="45" max="100" color="#4a6fa5" height="8" rounded></custom-progress>
动态更新时最常踩的坑
进度条 UI 和真实任务脱节，90% 出在 JS 层逻辑没对齐。不是组件写得不对，而是调用方式错了。
- fetch 上传时没检查
event.lengthComputable，导致event.loaded / event.total算出 NaN 或 Infinity - 多个异步任务共用同一个进度条，后返回的结果覆盖了先返回的更准确值（race condition）
- 把
value设成字符串（如"75"），浏览器不会报错，但计算百分比时出错 - 在 Vue/React 里直接改 DOM 的
style.width，绕过了响应式系统，下次 re-render 会被重置
真正可靠的更新方式，是让组件暴露 setValue() 方法，由外部传入数字，并由组件内部做防抖和边界判断——而不是裸露 style 或属性任人乱改。
