直接修改 .progress 容器的 background-color 即可改变进度条底色，推荐使用自定义类名（如 .progress-custom-bg）避免全局污染和优先级冲突，注意 bootstrap 5 默认底色为 #e9ecef 且不透明。
直接改 .progress 容器的背景色就行
bootstrap 进度条的底色不是写死在组件里，而是由外层容器 .progress 的 background-color 决定的。只要覆盖它，底色就变了——不需要动任何 js 或重写整个结构。
常见错误是只改 .progress-bar，结果进度条“飘”在默认浅灰底上，视觉割裂；或者用 !important 硬怼子元素，反而干扰颜色逻辑。
- 推荐用自定义类名（比如
.progress-custom-bg）加到.progress上，再在 CSS 里写.progress-custom-bg { background-color: #f0f4f8; } - 避免直接修改 Bootstrap 源码或全局覆盖
.progress，否则所有进度条底色统一变，失去语义区分 - 如果用了 Bootstrap 5+，注意默认
.progress已带background-color: #e9ecef（浅灰），不是透明——这点常被忽略，导致以为“没生效”
想让底色随进度动态变化？得靠 JS 控制类名
纯 CSS 无法根据 aria-valuenow 值自动切换底色，必须用 JS 监听或计算后手动加类。比如：数值 ≤30% 时底色偏红，70% 以上偏绿。
这时候别试图用 CSS 变量绑定属性值——style="width: 65%" 是内联样式，没法触发 CSS 计算；而且 aria 属性不参与样式计算。
- 获取进度条元素：
const bar = document.querySelector('.progress-bar') - 读取当前值：
const now = parseInt(bar.getAttribute('aria-valuenow')) - 根据范围切换容器类：
bar.closest('.progress').className = 'progress progress-low'（再配 CSS 定义.progress-low { background-color: #fee }） - 注意：如果进度是异步更新（如轮询接口），记得每次更新后都重新执行判断逻辑
和 Bootstrap 内置颜色类混用时的优先级陷阱
.progress-bar-success、.bg-success 这些类只影响进度条本体（.progress-bar），完全不影响底色。但如果你同时给 .progress 加了 .bg-light，又写了自定义背景色，就容易冲突。
Bootstrap 5 的 .bg-* 工具类有较高的 CSS 特异性（带 !important），一旦加在 .progress 上，会盖掉你写的普通规则。
- 查 DOM：右键检查
.progress元素，看 computed 样式里background-color被哪条规则覆盖 - 稳妥做法：不用
.bg-*类控制底色，全部走自定义类 + 普通 CSS 规则 - 如果非要复用
.bg-*，确保它加在.progress上，且你的自定义样式用更高特异性（比如.progress.my-bg { background-color: ... }）
移动端缩放或高对比模式下底色异常怎么办
某些系统级设置（如 Windows 高对比主题、iOS 缩放字体）会强制重置表单控件背景，而 .progress 在部分浏览器里被识别为“表单相关容器”，导致自定义底色失效，退回系统默认灰。
这不是 Bug，是可访问性策略主动干预的结果。强行绕过可能损害残障用户阅读体验。
- 测试方式：在 Chrome 开启“高对比模式”（设置 → 外观 → 高对比主题），或 iOS 设置 → 辅助功能 → 显示与文字大小 → 更大字体 + 缩放
- 安全方案：保留浅灰底色（
#e9ecef或更淡的#f8f9fa），仅通过进度条本体颜色（.progress-bar）传递状态信息 - 绝对不要用
appearance: none或-webkit-appearance: none强制剥离原生样式——这会让屏幕阅读器丢失语义
底色看着简单，但真要兼顾语义、可访问性和多端一致性，关键不在“怎么换”，而在“换在哪一层”和“谁有权决定它”。
