<meter>标签常不显示或异常，因需同时指定min、max、value三属性，缺一则降级为无样式内联元素；low/high/optimum仅影响颜色且浏览器支持不一，适用场景限于静态标量测量值。
为什么 <meter> 标签经常不显示或显示异常
浏览器对 <meter> 的默认样式极简，且不渲染任何内容（包括文字）——它只画一个进度条状的 UI 元素，但没有刻度、标签、单位，也不自动适配语义范围。很多开发者写完发现“页面没变化”，其实是它画出来了但太淡、太窄、或者被父容器挤没了。
- 必须同时提供
min、max和value三个属性，缺一不可；漏掉任意一个，Chrome/Firefox 会静默降级为普通 inline 元素（无视觉反馈） -
value超出[min, max]区间时，浏览器不会报错，但会按比例截断显示（例如min="0" max="100" value="150"等效于value="100"），容易误判数据逻辑 - 不支持百分比值（如
value="85%"），只能是数字；字符串数字（"85"）会被隐式转换，但建议统一用纯数字避免歧义
<meter> 的 low、high、optimum 怎么用才有效
这三个属性只影响颜色（通过伪类 ::-webkit-meter-optimum-value 等），不改变数值计算，也不触发 ARIA 状态。它们真正起作用的前提是：浏览器启用了原生 meter 样式（即没被 CSS 重置掉），且你写了对应伪类规则。
-
low和high定义“正常区间”边界，比如电量min="0" max="100" low="20" high="80"表示 20–80 是绿色，低于 20 红、高于 80 黄 -
optimum必须落在[min, max]内，且仅用于标定“最理想值”，不影响 low/high 划分；若optimum在 low 左侧，则“最优”反而是红色区，这很反直觉——得靠 CSS 手动覆盖颜色 - Firefox 目前完全忽略
low/high/optimum，只渲染基础 meter；想跨浏览器一致，得用<progress>+ 自定义背景 + JS 计算逻辑替代
什么时候该用 <meter>，而不是 <progress> 或 div + aria-valuenow
<meter> 唯一适合的场景是：表示「静态的、已知范围内的标量测量值」，比如磁盘使用率、CPU 温度、电池电量——它的语义是“当前值在某个固定尺度中的位置”，不是“任务完成进度”。
-
<progress>专用于任务进度（从 0 到目标的动态过程），value 可以是不确定（max缺失），而<meter>必须有确定的上下界 - 如果数值来源是 API 动态加载、或范围可能变化（如搜索结果总数未知），别硬套
<meter>；用<div role="meter">+aria-valuenow/aria-valuemin/aria-valuemax更稳妥 - SSR 场景下，服务端渲染
<meter>时若 value 未就绪，宁可先不渲染，也不要塞个value="0"再 JS 更新——这会导致屏幕阅读器提前播报错误数值
CSS 控制 <meter> 外观的实际限制
不能用常规 CSS 选择器直接改内部轨道或滑块，必须依赖浏览器前缀伪类，而且各引擎支持程度不同。Chrome 支持最全，Firefox 基本不支持伪类定制。
立即学习“前端免费学习笔记（深入）”；
- 关键伪类：
meter::-webkit-meter-bar（整个背景）、meter::-webkit-meter-optimum-value（绿色段）、meter::-webkit-meter-suboptimum-value（黄/红段） - 无法用 CSS 改变刻度线、添加单位文本（如 “°C”）、或响应式缩放高度——所有这些都得靠外层 wrapper + 绝对定位元素模拟
- 设置
height时，Chrome 默认把 meter 当作行内替换元素，vertical-align默认是baseline，常导致上下留白；建议显式设vertical-align: middle
<meter> 的语义价值远大于视觉价值。真要控制外观和行为，多数团队最后都退回到 <div> + ARIA + 自定义 CSS ——不是它不好，是浏览器实现太保守，且设计初衷就不是为了“可配置”。 
