progress用于有明确起点和终点的任务进度，如api请求或文件上传；meter用于静态度量值的区间评估，如cpu使用率，并需通过low/high/optimum定义业务阈值。
progress 用于“任务正在跑”，不是“当前值在哪”
如果你监控的是一个有明确起点和终点的运行过程——比如 API 请求耗时、批量任务执行进度、WebSocket 连接建立中——progress是唯一语义正确的选择。它告诉浏览器：“这事在动，还没完，value 是已完成量”。
常见误用：<progress value="42"></progress> 单独展示服务器响应延迟（42ms），这没有“任务终点”，屏幕阅读器会读成“进度 42%”，造成严重歧义。此时应换 meter。
动态更新务必用 element.value = 65，而非 setAttribute('value', '65')。后者在旧版 Safari 中可能不触发重绘，进度条卡住不动。
progress 的 min 属性被规范强制忽略，最小值永远是 0；硬设 min="20" 不但无效，还会让 AT 工具误报“已完成 0%”。想实现“从 20% 到 80%”的视觉效果，正确做法是保持 max="100"，再把 value 从 20 更新到 80。
meter 用于“现在这个值算好还是算差”
当你监控的是静态度量值——CPU 使用率、内存占用、磁盘水位、API 调用成功率——meter才能准确传达语义。它的核心不是“完成多少”，而是“落在哪一段”。
low、high、optimum 不是可选装饰，而是辅助技术判断依据：省略它们，AT 工具只读出数字，比如“85”，完全丢失“偏高”“远离理想值”的业务含义。
必须满足约束：min ≤ low ≤ optimum ≤ high ≤ max。违反时，Chrome 静默丢弃越界属性，Firefox 可能报错；例如 optimum="0" 在电池电量场景是合法的（越低越好），但若 low="50" 就直接冲突。
meter 必须显式设置 min 和 max。只写 <meter value="75"></meter> 会让浏览器按默认范围 0–1 解析，导致视觉异常（比如条形极窄或溢出）。
样式自定义时，伪元素支持差异极大
Chrome / Safari 用 ::-webkit-meter-bar、::-webkit-meter-optimum-value 等；Firefox 用 ::-moz-meter-bar，能力弱且不支持复杂着色逻辑；Edge（Chromium 内核）跟随 WebKit 规则。
appearance: none 必须加在基础选择器上（如 meter），否则后续伪元素样式不生效。
浏览器默认颜色不可靠：Chrome 可能让 value > high 变红，Safari 不支持该样式，Firefox 对属性选择器（如 meter[value>high]）支持有限。关键状态反馈必须用 CSS 伪元素强化，不能依赖默认渲染。
value 更新必须手动，且校验不可省
meter 不自动更新，哪怕值来自实时 API 或用户输入，都得靠 JS 主动赋值：meterEl.value = parseFloat(apiResponse.cpu)。
服务端渲染时，若 value 来自用户输入或外部接口，务必校验是否落在 min–max 范围内。超出会导致属性被截断或 UI 失控，HTML 无效。
所有属性值必须是数字类型。传字符串如 "65" 在部分旧环境可能触发隐式转换失败，建议统一用 parseFloat() 或 Number() 显式转换。
真正容易被忽略的是语义与无障碍的耦合：用错标签不会让页面崩，但会让屏幕阅读器说出完全错误的含义——这不是样式问题，是信息传达失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
