表格中稳定显示进度条需用双div嵌套：外层设display:block、固定高度、overflow:hidden；内层设height:100%、动态width百分比及transition:width 0.3s。
表格单元格里怎么塞进度条？用两个嵌套，别碰表格里直接放<progress></progress>基本等于放弃 IE 和部分老版本 Safari；更麻烦的是，<progress></progress>在<td>里默认撑不满、样式错位、动画卡顿。真正在表格里跑得稳的，还是双 <code>div 嵌套方案。
关键不是“能不能放”，而是“怎么放才不破布局”：外层 div 必须设 display: block + 固定高度（比如 height: 16px），同时加 overflow: hidden；内层 div 高度拉满（height: 100%），宽度靠 JS 或模板引擎动态写死为 width: 72% 这种形式。
- 别让外层
div 宽度由内容撑开——显式设 width: 100% 或继承 td 的宽度
- 如果表格用了
table-layout: fixed，确保 td 有明确 width，否则百分比宽度会算不准
- 移动端小屏下，
font-size 缩小可能挤压进度条高度，建议用 min-height: 16px 保底
为什么 width 百分比必须写在内层 div 上？
因为浏览器只对“尺寸可计算”的元素做重排动画。外层 div 是容器，它的 width 通常由表格列宽决定，属于“受控尺寸”；而内层 div 的 width 是你手动设的百分比值，浏览器能明确知道起点和终点，transition: width 0.3s 才会生效。
常见错误是把 transition 写在外层，或者给内层设 max-width——后者根本不会触发动画，只会突然跳变。
- 内层必须有明确初始值，比如
width: 0%，不能留空或写 auto
- 过渡属性只写
width，别用 all 0.3s，否则边框、padding 变化也会触发重绘，卡顿明显
- 百分比单位（
%）比像素（px）更安全，避免因父容器尚未渲染完成导致宽度计算为 0
JS 更新表格进度条时最容易漏掉的三件事
表格里每行一个进度条，意味着你要批量操作多个 DOM 节点。这时候不处理边界，很容易出现 101%、负数、DOM 未挂载就赋值等问题。
- 更新前校验数值：
value = Math.max(0, Math.min(100, Math.round(rawValue)))，浮点误差必须四舍五入再截断
- 确保目标元素存在：用
el && el.style 判空，尤其表格用 v-for 或 ng-repeat 渲染时，可能某行还没 render 完
- 避免重复绑定：如果进度来自轮询 API，每次响应都要
clearInterval(oldTimer)，不然旧定时器还在往 DOM 写 width
要不要用 transform: scaleX() 替代 width？
可以，但只推荐在 iOS/Safari 主力场景下考虑。Safari 对 width 动画的重绘帧率偶尔不稳定，而 transform: scaleX(0.83) 是硬件加速，更顺滑。
代价也很实在：scaleX 会让内层文字缩放，必须额外加 transform: scaleX(1.2) 反向抵消；iOS 15 之前对 scaleX(0) 有渲染残留 bug，得从 scaleX(0.001) 启动。
所以除非你明确遇到 width 动画卡顿且已排除其他干扰（如过多 box-shadow、filter），否则 stick with width——它更直白、兼容性更好、调试更简单。
真正容易被忽略的，是表格中多行进度条同步更新时的 DOM 批量重排压力。哪怕只改 10 个 style.width，也建议用 requestAnimationFrame 包一层，别在循环里直接连写。
表格里直接放<progress></progress>基本等于放弃 IE 和部分老版本 Safari；更麻烦的是，<progress></progress>在<td>里默认撑不满、样式错位、动画卡顿。真正在表格里跑得稳的，还是双 <code>div 嵌套方案。
关键不是“能不能放”，而是“怎么放才不破布局”：外层 div 必须设 display: block + 固定高度（比如 height: 16px），同时加 overflow: hidden；内层 div 高度拉满（height: 100%），宽度靠 JS 或模板引擎动态写死为 width: 72% 这种形式。
- 别让外层
div宽度由内容撑开——显式设width: 100%或继承td的宽度 - 如果表格用了
table-layout: fixed，确保td有明确width，否则百分比宽度会算不准 - 移动端小屏下，
font-size缩小可能挤压进度条高度，建议用min-height: 16px保底
为什么 width 百分比必须写在内层 div 上？
因为浏览器只对“尺寸可计算”的元素做重排动画。外层 div 是容器，它的 width 通常由表格列宽决定，属于“受控尺寸”；而内层 div 的 width 是你手动设的百分比值，浏览器能明确知道起点和终点，transition: width 0.3s 才会生效。
常见错误是把 transition 写在外层，或者给内层设 max-width——后者根本不会触发动画，只会突然跳变。
- 内层必须有明确初始值，比如
width: 0%，不能留空或写auto - 过渡属性只写
width，别用all 0.3s，否则边框、padding 变化也会触发重绘，卡顿明显 - 百分比单位（
%）比像素（px）更安全，避免因父容器尚未渲染完成导致宽度计算为 0
JS 更新表格进度条时最容易漏掉的三件事
表格里每行一个进度条，意味着你要批量操作多个 DOM 节点。这时候不处理边界，很容易出现 101%、负数、DOM 未挂载就赋值等问题。
- 更新前校验数值：
value = Math.max(0, Math.min(100, Math.round(rawValue)))，浮点误差必须四舍五入再截断 - 确保目标元素存在：用
el && el.style判空，尤其表格用v-for或ng-repeat渲染时，可能某行还没 render 完 - 避免重复绑定：如果进度来自轮询 API，每次响应都要
clearInterval(oldTimer)，不然旧定时器还在往 DOM 写 width
要不要用 transform: scaleX() 替代 width？
可以，但只推荐在 iOS/Safari 主力场景下考虑。Safari 对 width 动画的重绘帧率偶尔不稳定，而 transform: scaleX(0.83) 是硬件加速，更顺滑。
代价也很实在：scaleX 会让内层文字缩放，必须额外加 transform: scaleX(1.2) 反向抵消；iOS 15 之前对 scaleX(0) 有渲染残留 bug，得从 scaleX(0.001) 启动。
所以除非你明确遇到 width 动画卡顿且已排除其他干扰（如过多 box-shadow、filter），否则 stick with width——它更直白、兼容性更好、调试更简单。
真正容易被忽略的，是表格中多行进度条同步更新时的 DOM 批量重排压力。哪怕只改 10 个 style.width，也建议用 requestAnimationFrame 包一层，别在循环里直接连写。
