表格单元格内使用<progress>易错位，因其为行内元素且受vertical-align、padding及浏览器伪元素渲染影响；应重置对齐、避免直接设height、外层加div包裹并设overflow:hidden，同时归一化宽度计算、防layout thrashing，并为IE降级提供fallback及无障碍支持。
表格单元格里放<progress>会错位，别硬塞
<progress> 是行内元素，直接塞进 <td> 里容易因默认 vertical-align 和 line-height 导致上下偏移，尤其在固定高度的表格行中特别明显。
更麻烦的是：表格单元格默认有 padding，而 <progress> 的内部渲染（比如 WebKit 的伪元素）可能被截断或挤压变形。
- 必须显式重置对齐：
td { vertical-align: middle; }+progress { vertical-align: middle; } - 避免用
height直接设在<progress>上，改用transform: scale()或 CSS 自定义高度（通过伪元素控制） - 如果表格设置了
border-collapse: collapse，某些浏览器下<progress>边框会和单元格边框打架，建议外层加<div>包裹并设overflow: hidden
用<div>模拟进度条时，宽度计算必须归一化到百分比
表格里展示「已完成/总数」这类数据（比如「12/48」），不能直接把 12 当成 width 值——得先算出比例再转成 CSS 百分比：
- 错误写法：
style="width: 12px"（单位错）或style="width: 12%"（数值未归一化） - 正确逻辑：假设当前值为
current，总数为total，则宽度 =Math.min(100, Math.max(0, (current / total) * 100)) - 特别注意除零：
total === 0时应 fallback 到0%，否则 JS 报NaN，CSS 解析为无效值
示例（内联 style）：
<td>
<div class="progress-cell">
<div class="progress-fill" style="width: 25%;"></div>
</div>
<span>12/48</span>
</td>表格动态更新进度时，避免重复触发 layout thrashing
表格行数多（比如 >50 行）时，逐行用 JS 改 style.width 容易卡顿——每次赋值都触发重排（reflow），浏览器来不及合并。
- 不要用循环直接改 DOM：
rows[i].querySelector('.progress-fill').style.width = ... - 改用 document fragment 批量操作，或用 CSS 自定义属性 +
:has()（仅现代浏览器）间接驱动 - 更稳妥的做法：把所有进度数据存在数组里，用一次
requestAnimationFrame批量更新，且只更新 visible rows（配合 IntersectionObserver）
另外，别在 onload 或 DOMContentLoaded 后立刻遍历全表——此时表格 DOM 可能还没完全 layout 完，offsetHeight 类属性可能不准。
立即学习“前端免费学习笔记（深入）”；
IE 或旧 Edge 下表格里<progress>完全不显示，降级方案要提前兜底
IE11 及更早版本根本不解析 <progress> 标签，会把它当普通内联元素，既无样式也无语义；旧 Edge（≤18）虽支持但伪元素不可控。
- 检测方式不是靠
typeof progress !== 'undefined'，而是：!!document.createElement('progress').max - 降级后仍要保持表格结构不变：用
<div class="progress-fallback">替代，CSS 里用background-image: linear-gradient(...)模拟填充效果 - 关键细节：fallback 的
width必须用 JS 动态设置（因为 IE 不支持 CSS 自定义属性），且需监听resize防止列宽变化后错位
表格场景下，进度条从来不是孤立组件——它得服从表格的盒模型、滚动行为和可访问性要求。最容易被忽略的，是把进度值当成纯视觉装饰，却忘了给 screen reader 提供 aria-valuenow 和 aria-valuemin/aria-valuemax。没有这些，表格对辅助技术用户就是“一堆绿色条，不知道代表什么”。
