进度条高亮动画由 .progress-bar 类控制，其 transition 属性（默认 width 0.6s ease）驱动 width 变化时的过渡效果，覆盖该属性可自定义时长、缓动或禁用动画。
进度条高亮动画由哪个 css 类控制
Bootstrap 的进度条填充部分（即高亮色块）默认使用 .progress-bar 类，其动画效果由 transition 属性驱动，目标属性是 width。原始定义在 Bootstrap 的 CSS 中类似这样：
.progress-bar {
transition: width 0.6s ease;
}
这意味着：只要 width 变化（比如 JS 更新 style.width 或通过 aria-valuenow 触发的动态更新），就会触发过渡动画。你无法靠覆盖 transition 属性来“禁用”它——除非显式重写。
常见错误现象包括：动画卡顿、多次更新时叠加延迟、从 0% 突然跳到某值后才开始动。根本原因往往是 JS 批量修改了 width，但浏览器没及时重绘，或你误改了父容器 .progress 的 overflow 导致裁剪异常。
如何自定义过渡时长和缓动函数
直接覆盖 .progress-bar 的 transition 即可，无需 JS 干预：
- 在自定义 CSS 文件中（确保加载顺序在 Bootstrap 之后）写：
.progress-bar {
transition: width 0.2s cubic-bezier(0.34, 1.56, 0.64, 1);
}
-
cubic-bezier(...)比ease更灵活，上面这个值模拟“快出慢入”，适合强调完成感 - 若想完全禁用动画，设为
transition: none或transition: width 0s - 注意：不要只写
transition: 0.2s—— 缺少属性名会导致整个过渡失效
兼容性上，cubic-bezier() 在所有现代浏览器（含 IE10+）都支持，但旧版 Android WebView 可能对高阶贝塞尔支持不稳，建议用在线工具生成兼容 fallback。
为什么 JS 更新进度后动画不触发
最常见原因是：你用 JS 直接修改了 element.style.width，但该元素此前没有内联 width，导致首次设置时浏览器认为“从空字符串到 '50%'”不是有效过渡起点。
- 确保初始状态有明确宽度（哪怕为
0%）：<div class="progress-bar" style="width: 0%;"></div> - 避免用
setAttribute('style', ...)覆盖全部样式；改用element.style.width = '75%' - 如果用 jQuery：
$el.css('width', '75%')安全，但$el.attr('style', 'width:75%')会清掉其他内联样式 - 极端情况（如快速连续更新），加个
setTimeout(() => { /* 更新 width */ }, 0)让浏览器先 flush layout
另一个隐藏坑：某些 UI 库（如 BootstrapVue）会封装进度条并劫持 width 更新逻辑，此时覆盖 .progress-bar 的 transition 仍有效，但需确认最终渲染的 DOM 确实带有该 class。
动画与语义化属性是否冲突
不冲突，但要注意：Bootstrap 官方推荐用 aria-valuenow 配合 JS 动态更新，而视觉动画仍由 width 控制。两者可以并存。
- 例如：
<div class="progress-bar" role="progressbar" aria-valuenow="45" aria-valuemin="0" aria-valuemax="100" style="width: 45%;"></div> -
aria-valuenow不影响动画，纯用于无障碍；动画只响应style.width或 CSSwidth - 如果你用 CSS 自定义属性（
--progress-width）配合width: var(--progress-width)，记得同时给transition加上width，CSS 变量本身不会触发过渡
真正容易被忽略的是：当进度条嵌套在 display: flex 或 transform 容器中时，某些浏览器会关闭硬件加速，导致动画掉帧。此时加 will-change: width 可能有帮助，但别滥用——它会提前分配图层内存。
