原生 <progress> 标签需配合 JS 同步数值、显示百分比文本，并兼容多浏览器伪元素样式；禁用 <meter>，因其语义不符课程进度场景。
怎么用 <progress> 标签做课程进度条
直接用原生 <progress> 最省事，但得注意它默认不带数值文本、不自动更新、也不响应课程实际完成状态。它只是个“视觉容器”，值得靠 JS 手动同步。
常见错误是写成 <progress value="60" max="100"></progress> 就以为完事了——用户看不到“60%”，屏幕阅读器也读不出进度含义，更别说和课程模块联动了。
-
value和max必须是数字，不能是字符串（"60"会失效） - 想显示百分比文字，得额外加一个
<span>并用 JS 更新，比如document.querySelector('.progress-text').textContent = Math.round(progress.value / progress.max * 100) + '%'; - 如果课程数据来自 API 或本地存储，别在 HTML 里硬编码
value，留空或设为0，等 JS 拿到真实进度后再赋值
CSS 怎么改 <progress> 样式才不翻车
浏览器对 <progress> 的样式支持很分裂：Chrome/Edge 用 ::-webkit-progress-bar 和 ::-webkit-progress-value，Firefox 用 ::progress-bar 和 ::progress-value，Safari 则部分支持 WebKit 伪元素但行为不稳定。
最容易踩的坑是只写 WebKit 规则，结果 Firefox 里进度条变灰色块、没颜色、甚至不随 value 变化。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 必须同时写两套规则，哪怕只是基础色（比如都设
background: #e0e0e0和background: #4CAF50） - 不要依赖
transform或filter做动画，某些浏览器会跳帧或卡死 - 如果需要圆角进度条，
border-radius要加在::-webkit-progress-bar和::progress-bar上，而不是<progress>标签本身
JavaScript 怎么安全更新进度值
进度不是静态值，课程可能跨设备同步、中途退出、或跳着学。直接用 element.value = 75 很危险——万一用户刚点完“上一课”，JS 还没来得及减，后端又返回了旧进度，就会错乱。
关键是要把进度更新变成“可撤销+幂等”的操作，而不是简单覆盖。
- 每次更新前先校验新值是否在
0到max范围内，超限就截断（Math.min(Math.max(newVal, 0), max)） - 存进度时优先用
localStorage.setItem('course-progress', JSON.stringify({ moduleId: 'm3', completed: true }))，而不是只存一个数字，方便后续支持多章节独立追踪 - 监听
beforeunload事件保存当前进度，但别在该事件里发网络请求（浏览器可能中断）
为什么不用 <meter> 替代 <progress>
<meter> 看起来更“语义化”，但它描述的是“当前值在已知范围内的相对位置”（比如磁盘使用率、体温），不是“任务完成度”。W3C 明确说：<progress> 表示“任务进展”，<meter> 表示“标量测量”。
用错标签最直接的问题是辅助技术（如读屏软件）会把课程进度读成“磁盘已用 60%”，用户完全无法理解上下文。
- 如果课程总模块数会动态变化（比如新增一章），
<progress>的max可随时重设；<meter>的min/max是静态描述，改了反而破坏语义 -
<meter>不支持indeterminate状态，而加载中、未开始、未知进度这些场景，<progress>都能自然表达 - 所有主流框架（React/Vue）的 UI 库底层进度组件，无一例外都基于
<progress>，不是<meter>
进度条真正的复杂点不在视觉，而在它和课程状态机的耦合程度——什么时候算“完成”？跳过小节算不算？测试没过但视频看完了怎么记？这些逻辑一旦写死在 DOM 更新里，后面改起来比重写还疼。
