meter标签的value、min、max必须同时显式声明为数字，缺一不可；low/high/optimum仅在min/max有效且满足大小关系时触发语义颜色判断，浏览器实现不一致导致渲染差异。
meter 标签的 value、min、max 三者必须同时显式声明，缺一不可；否则浏览器可能渲染空白、回退到默认值（min=0、max=1），或完全忽略 low/high/optimum 的语义判断。
value/min/max 必须一起写，不能依赖默认值
浏览器对缺失属性的 fallback 行为不一致：Chrome 可能按 min="0" max="1" 归一化 value，Firefox 则可能直接不触发颜色变化。实际项目中一旦漏写，就等于没生效。
-
value必须是数字类型，"85%"、"0.85"这类字符串会被忽略——得先转成85或85.0 -
min和max也必须是数字，min="zero"或max="100px"无效 - 若后端返回小数（如
0.72），JS 中应统一处理：Math.round(value * 100)或parseFloat(value) * 100，再约束在[min, max]范围内
low/high/optimum 不是装饰，但受范围强约束
这三个属性只有在 min 和 max 显式存在且满足大小关系时才起作用。它们不控制宽度或位置，只参与浏览器内置的颜色语义判断（比如 Chrome 中 value ≤ low 显示暗红）。
-
low必须 >min，high必须 max，且low ，否则整个区间判断被跳过 -
optimum可以等于min或max，表示“最优状态在边界”，比如电池健康度最低仍算理想区间 - 典型电池场景：
<meter value="72" min="0" max="100" low="20" high="80" optimum="60"></meter>—— 注意这里optimum="60"不是“中间值”，而是业务定义的“最推荐维持的电量”
跨浏览器样式不可靠，别指望纯 HTML 解决视觉一致性
Firefox 目前完全不支持 low/high/optimum 的视觉反馈，所有值都显示同一色块；Chrome 支持但颜色策略和阈值判定逻辑与 Safari 不同。用 CSS 伪元素（如 ::-webkit-meter-bar）只能覆盖 WebKit 内核，无法统一。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 如果需要精确控制颜色、动画或响应式表现，
meter不是合适选择——改用<div role="meter"> + ARIA 属性 + JS 动态 class 更稳妥<li>无障碍方面，<code>meter本身不带可读文本，必须加aria-label或隐藏的<span class="visually-hidden">电量 72%</span> - 动态更新时，不要只改
textContent，必须同步调用element.setAttribute('value', newValue)，否则浏览器不会重绘状态色块 - 渲染为空白 → 检查是否漏了
min或max；或value是null/undefined导致解析失败 - 始终显示绿色 →
low和high值未落在[min, max]内，或low >= high - 数值正确但颜色反直觉（比如 95% 显示绿色）→
optimum设得太高（如optimum="95"），导致高值反而被判定为“接近最优” - 服务端模板里出错 → Nunjucks/Jinja 中避免直接插字符串：
<meter value="{{ battery | float * 100 }}" min="0" max="100"></meter>，而不是value="{{ battery }}%"
常见错误现象和对应检查点
看到 meter 渲染为空白、始终绿色、或颜色和预期不符，大概率不是 CSS 问题，而是属性配置或数据类型出了偏差。
真正难的不是写对那几行 HTML，而是让不同浏览器对同一组数字做出一致的语义解读——meter 把这部分交给了 UA，而 UA 并不总按你的业务逻辑来理解“低”“高”“理想”。
