标签必须同时显式设置min、max、value三个数字属性，缺一不可，否则浏览器降级为空白或普通文本；low/high/optimum仅在范围合法且满足low
meter标签必须写全min、max、value三个属性
漏掉任意一个，浏览器就当没这回事——多数情况下渲染为空白或退化为普通内联文本，根本看不出条形。这不是样式问题，是语义缺失导致的降级。
-
min和max不能靠浏览器默认值凑合：虽然min默认为0、max默认为1，但<meter value="85"></meter>实际被解析成value="85"/max="1"，视觉长度≈8500%，必然溢出或截断 -
value必须是纯数字，value="85%"或value="85px"直接失效，整个标签不渲染 - 服务端模板里常见错误：
<meter value="{{item.percent}}%"></meter>→ 应改为<meter value="{{item.percent}}"></meter> - 边界允许负值（比如温度-15°C），就必须显式写
min="-20"，否则语义错乱
别把meter当progress用
两者语义完全不同：meter表达“当前静态值落在哪个区间”，progress表达“任务完成多少”。混用会导致屏幕阅读器读错、无障碍工具误判，且样式逻辑也不兼容。
- 要显示“文件上传已完成65%”，必须用
<progress value="65" max="100"></progress> - 要显示“CPU使用率65%，高于警告阈值60%”，才该用
<meter min="0" max="100" value="65" low="30" high="60"></meter> -
<meter value="65" max="100"></meter>看着像进度条，但会被读作“65 分之 100”，不是“已完成 65%” - 动态倒计时（如活动剩余3天）可用
meter，但前提是它代表“当前快照值”，而不是随时间自动变化的过程
low、high、optimum不是样式开关，而是脆弱语义线索
它们不控制颜色本身，只提供参考点，由浏览器自行决定如何着色——而这个“自行决定”在各浏览器中差异极大，甚至部分版本完全忽略。
-
low和high必须落在[min, max]范围内，且low ，否则Chrome/Firefox会静默跳过颜色逻辑 -
optimum可以等于min或max（例如噪音分贝越低越好，设optimum="min"），但超出范围就失效 - Firefox目前完全不响应
low/high；Safari对optimum着色支持有限；Chrome虽有颜色变化，但无法监听、无法通过CSS精确控制 - 状态判断不能依赖颜色——必须用JS手动计算：
value 、<code>value > high、Math.abs(value - optimum)等
无障碍和兼容性绕不开的硬约束
meter在IE和Edge 18及更早版本中完全不渲染；现代浏览器虽支持，但原生样式不可控，且可访问性依赖严格属性组合。
- 内部文本（如
<meter ...>85%</meter>）仅作降级提示，现代浏览器不显示，但对屏幕阅读器有意义 - 必须配合
aria-valuenow、aria-valuetext补充说明，例如aria-valuetext="磁盘使用率：85%，偏高" - 若需统一视觉或响应交互，实际项目中普遍用
div模拟——牺牲一点语义，换来可控性和兼容性 - 真正要用
meter，就得接受它是个“语义优先、样式次要”的原生组件，别指望它像progress那样容易定制
真实场景里，meter最常踩的坑不是不会写，而是误判了它能干什么——它不是进度条，不是滑块，也不是可交互控件。它的存在意义，是让机器（尤其是辅助技术）准确理解“这个数字代表什么状态”，而不是帮你省几行CSS。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
