meter用于展示范围内的状态量，如硬盘使用率；progress表示任务完成进度，如文件上传。前者强调评估，后者关注过程。
meter和
progress标签，说白了，它们都是用来在网页上展示进度或度量值的，但它们的核心语义和适用场景有着本质的区别。简单来说，
meter衡量的是一个已知范围内的“量”，像电量、温度；而
progress则表示一个任务的“进度”，比如文件上传或页面加载。理解这个，就能避免很多混淆。
解决方案
在我看来，区分
meter和
progress最关键的是抓住它们各自的“意图”或者说“语义”。这不仅仅是语法上的差异，更是对内容含义的精确表达。
progress标签，它天生就是为那些“进行中”的任务而设计的。想象一下，你正在下载一个大文件，或者提交一个复杂的表单，页面上那个缓缓前进的条形图，显示的就是任务完成了多少百分比——这就是
progress的用武之地。它有一个
value属性表示当前进度，以及一个
max属性表示总进度。如果
value属性省略，它就进入了一种“不确定”状态，通常表现为一个动画，表示“正在加载中，但不知道具体完成了多少”。它的重点在于“完成度”和“动态变化”。
而
meter标签呢，它更像是一个“仪表盘”或“刻度尺”。它衡量的是一个在特定范围内波动的量。比如，你电脑的硬盘使用率，或者一个商品的库存量，再或者你个人资料的完善度。这些量都有一个明确的最小值（
min）和最大值（
max），并且当前值（
value）会在这个范围内浮动。更有意思的是，
meter还可以通过
low,
high,
optimum这几个属性来标记出不同的“区间”，比如电量低于某个值就显示红色警告，高于某个值就是正常绿色。它强调的是“状态”和“评估”。
所以，当你需要展示一个任务的完成情况时，毫不犹豫地选择
progress；而当你需要展示一个量在预设范围内的状态时，
meter才是你的最佳拍档。这种语义上的精准选择，不仅能让你的代码更具可读性，对屏幕阅读器等辅助技术也更友好，毕竟它们能更好地理解你想要表达的含义。
何时选用
？理解其适用场景与语义边界
我觉得，选择
的核心逻辑在于，你展示的这个“量”是否有一个相对固定的、可衡量的范围，并且你可能还想对这个量进行“评价”。举个例子，假设你正在开发一个个人仪表盘应用，你想显示用户的“成就点数”距离下一等级还有多远，或者你的网站后台需要展示服务器的 CPU 使用率。这些都是
的典型场景。
在我看来，
的语义边界非常清晰：它不是一个任务完成指示器，而是一个“状态量”的显示器。它通常用于那些可以被量化、有上下限，并且其当前值可以被解释为“好”、“坏”、“正常”等状态的场景。比如，一个在线课程的“学习进度”——如果这个进度是基于完成的章节数占总章节数的比例，并且你希望显示一个百分比，那它更偏向于
，因为它代表的是一个“完成度”的“量”，而不是一个“进行中任务”的“完成过程”。当然，这里有点微妙，如果把它看作是“完成一个课程”这个任务的进度，用
progress也未尝不可，但
meter的优势在于可以明确设定“及格线”或“优秀线”。
这里我随手写个例子：
60% 你当前的账户信誉等级：
良好
你看，
low、
high、
optimum这些属性，就是
meter独有的魅力，它们能让浏览器或辅助技术对这个“量”的当前状态给出更丰富的语义解释。比如，当硬盘使用率超过
high值时，你可能希望它在视觉上呈现红色警告，这就是语义带来的好处。
何时选用 ？掌握任务完成度可视化的关键
如果说
关注的是“状态”，那么 关注的绝对是“过程”和“完成度”。想象一下你在上传一个视频，或者一个复杂的计算正在后台进行，你希望用户知道“事情正在发生，并且正在朝完成迈进”。这时候， 就是你的首选。
网钛淘拍CMS(TaoPaiCMS) V1.60
下载
2013年07月06日 V1.60 升级包更新方式：admin文件夹改成你后台目录名，然后补丁包里的所有文件覆盖进去。1.[新增]后台引导页加入非IE浏览器提示，后台部分功能在非IE浏览器下可能没法使用2.[改进]淘客商品管理 首页 列表页 内容页 的下拉项加入颜色来区别不同项3.[改进]后台新增/修改淘客商品，增加淘宝字样的图标和天猫字样图标改成天猫logo图标4.[改进]为统一名称，“分类”改
我觉得，使用
的关键在于，它所代表的这个“任务”是有明确开始和结束的。它不关心这个量是“好”是“坏”，只关心它离“完成”还有多远。最常见的就是文件上传下载，或者一个分步表单的填写进度。它的value属性通常会随着任务的进行而动态更新，直到达到
max值，任务就算完成了。
有个特别值得一提的地方是，
可以不设置value属性。当
value属性缺失时，它会进入一种“不确定”状态，通常表现为一个持续循环的动画，这对于那些你无法精确知道完成百分比，但又想告诉用户“我正在努力工作”的场景非常有用。比如，数据加载中，但你不知道具体有多少条数据需要加载，或者一个后台处理可能需要几秒到几分钟不等，无法给出准确的进度条。
这里也来个小例子：
正在处理您的请求...
这种“不确定”状态的
尤其方便，省去了我们手动用 CSS 或 JavaScript 实现复杂加载动画的麻烦，而且语义上也非常清晰。它直接告诉用户：“请稍候，我正在努力。”技术深挖：
和 的可访问性与样式定制
说到可访问性，这俩标签的表现都挺不错的，这是它们作为语义化 HTML 元素的一个巨大优势。浏览器和辅助技术（比如屏幕阅读器）对它们有很好的内置支持。当你使用
或 时，屏幕阅读器通常能自动识别它们是进度条或度量衡，并能读出它们的当前值、最大值等信息，这比你用
div模拟然后加上一堆
aria-*属性要省心得多，也更可靠。
不过，虽然它们在语义上很强大，但样式定制上，说实话，它们各自都有点小脾气。
标签相对来说要好搞定一些。你可以直接通过 CSS 修改它的背景色、进度条的颜色等。但要深入定制，尤其是要改变进度条内部的样式，你就可能需要用到一些浏览器特定的伪元素。比如，在 WebKit/Blink 浏览器（Chrome, Safari, Edge）中，你会用到::-webkit-progress-bar来样式化背景条，以及
::-webkit-progress-value来样式化实际的进度填充条。Firefox 则有
::-moz-progress-bar。这确实增加了跨浏览器样式统一的难度，有时候你可能需要写好几套代码来适配。
/* 示例：定制 progress 样式 */
progress {
width: 200px;
height: 20px;
/* 默认背景色 */
background-color: #eee;
border: 1px solid #ccc;
border-radius: 5px;
}
/* WebKit/Blink 浏览器 */
progress::-webkit-progress-bar {
background-color: #eee;
border-radius: 5px;
}
progress::-webkit-progress-value {
background-color: #4CAF50; /* 绿色进度条 */
border-radius: 5px;
}
/* Firefox 浏览器 */
progress::-moz-progress-bar {
background-color: #4CAF50;
border-radius: 5px;
}而
标签的样式定制，在我看来，那简直是另一个级别的挑战。它的内部结构更为复杂，同样依赖于各种浏览器私有的伪元素，而且不同浏览器之间的实现差异可能更大。比如，WebKit 浏览器有
::-webkit-meter-bar、
::-webkit-meter-optimum-value、
::-webkit-meter-suboptimum-value、
::-webkit-meter-even-less-good-value等等，用于控制不同区间的颜色。这意味着如果你想让
meter在
low、
high、
optimum区域显示不同的颜色，你需要针对性地去写这些伪元素的样式。
/* 示例：定制 meter 样式 (部分，仅供参考，实际情况复杂) */
meter {
width: 200px;
height: 20px;
/* 默认背景色 */
background-color: #eee;
border: 1px solid #ccc;
border-radius: 5px;
}
/* WebKit/Blink 浏览器 */
meter::-webkit-meter-bar {
background-color: #eee;
border-radius: 5px;
}
/* 最佳值区域 */
meter::-webkit-meter-optimum-value {
background-color: #4CAF50; /* 绿色 */
border-radius: 5px;
}
/* 次佳值区域 (例如高于low，低于optimum) */
meter::-webkit-meter-suboptimum-value {
background-color: #FFC107; /* 橙色 */
border-radius: 5px;
}
/* 最差值区域 (例如低于low) */
meter::-webkit-meter-even-less-good-value {
background-color: #F44336; /* 红色 */
border-radius: 5px;
}
/* Firefox 浏览器对 meter 的样式支持相对有限，通常需要更多 hack 或回退方案 */说实话，由于这些跨浏览器样式定制的复杂性，很多开发者在实际项目中，如果对视觉效果有非常高的要求，并且需要统一所有浏览器的表现，可能会选择用
div和 CSS 甚至 SVG 来完全自定义进度条或仪表盘，然后手动添加
aria-*属性来弥补语义上的缺失。但这无疑增加了开发成本和维护难度。所以，在选择使用这两个标签时，除了考虑语义，也要对它们的样式定制难度有所预期。对我个人而言，如果不是特别复杂的定制，我还是倾向于使用原生的 和
，毕竟语义化和可访问性是它们最大的价值。
