<progress> 标签样式不生效是因为浏览器强默认样式，需用 appearance: none 清除，并分别针对 WebKit（::-webkit-progress-bar/value）和 Firefox（::progress-value 或 ::-moz-progress-bar）伪元素定制，IE 需降级为 <div role="progressbar"> + ARIA 属性模拟。
用 <progress> 标签时为什么样式完全不生效
浏览器对 <progress> 的默认样式控制极强，直接写 width、height 或 background 几乎无效，因为内部轨道和填充是伪元素控制的。必须显式覆盖 ::-webkit-progress-bar、::-webkit-progress-value（Chrome/Safari）和 ::progress-value（Firefox）才能生效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 先加
appearance: none清除所有默认渲染逻辑 - Chrome/Safari 下必须同时设置
::-webkit-progress-bar（背景轨道）和::-webkit-progress-value（进度条本身），否则后者不显示 - Firefox 需单独写
progress::-moz-progress-bar，且不支持圆角或渐变动画（仅纯色） - IE 不支持
<progress>，需降级为<div>+ JS 模拟（见下节）
不用 <progress> 怎么手写一个可访问的进度条
手动实现的关键不是“看起来像”，而是保留语义和键盘/屏幕阅读器支持。用 <div role="progressbar"> 替代，配合 aria-valuenow、aria-valuemin、aria-valuemax 属性。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 结构必须是：
<div role="progressbar" aria-valuenow="65" aria-valuemin="0" aria-valuemax="100"><div class="progress-fill"></div></div> -
.progress-fill用width百分比控制，不要用transform: scaleX()——它会破坏无障碍树中的尺寸计算 - 动态更新时，只改
aria-valuenow和width，避免重排整个组件 - 加
tabindex="0"并监听keydown（如方向键）可提升交互性，但非必需
transition 动画卡顿或跳变的原因和修复
进度条动画卡顿通常不是性能问题，而是 CSS 触发条件没对齐。比如用 width 动画时，父容器未设 overflow: hidden，导致子元素撑开布局；或用 transform 却忘了加 will-change: transform。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用
transform: scaleX()替代width，更利于 GPU 加速，但注意：必须确保父容器overflow: hidden且子元素transform-origin: left center - 动画时间统一用
transition: transform 0.3s ease-out，避免混用ease和linear导致节奏混乱 - 如果进度值来自 API 异步更新，别在每次
setState（React）或innerHTML更新时都触发 transition——先判断新旧值差是否 > 2%，再决定是否加类名触发动画
服务端渲染（SSR）或静态生成时进度条初始状态错乱
服务端输出的 HTML 中 aria-valuenow 和 width 是固定值，但客户端 JS 初始化后可能立即覆盖，造成闪动或读数错误。尤其 Next.js、Nuxt 等框架中，hydration 前后状态不一致很常见。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 服务端只输出基础结构和
aria-valuenow，width初始设为0%，由客户端 JS 第一次 update 时同步设置 - 用
useEffect（React）或onMounted（Vue）延迟首次更新，避免 hydration 冲突 - 如果进度依赖 props，确保 SSR 时 props 值与客户端一致，否则加
key={props.value}强制重渲染
最易被忽略的是：当进度条嵌套在折叠面板或 tab 页中时，初始 display: none 会导致 getBoundingClientRect() 返回 0，进而影响基于尺寸的动画逻辑——得等元素真正挂载并可见后再启动进度更新。
