如何用CSS transition实现进度条平滑增长

直接用 transition: width 0.3s ease 可行，但需确保父容器有明确宽度、进度条内部元素设 height: 100% 和 transition: width 0.3s ease、JS 更新 style.width 而非 class，并避免盒模型与兼容性陷阱。

直接用 transition: width 0.3s ease 是可行的，但必须配合正确的 DOM 结构和 CSS 约束，否则动画会失效或跳变——尤其在 flex 容器里改 width 百分比时，90% 的失败都源于父级没设宽度参照。

为什么 progress 元素加 transition 常常不生效

浏览器原生 <progress> 的 value 属性变更不会触发 CSS width 变化，它靠内部伪元素渲染填充区，而不同内核处理方式不一致：

1. <progress> 本身不能直接设 width 动画，它的尺寸由 HTML 属性控制，CSS 对它的 width 仅影响外框
2. ::-webkit-progress-value 和 ::-moz-progress-bar 才是真正要加 transition 的目标，但 IE/Edge（非 Chromium）完全不支持这些伪元素
3. 即使写了 transition，如果 JS 直接赋值 el.value = 80，浏览器仍可能跳帧——因为 value 更新是离散的，不是连续的 width 变化

用 div + width 实现可靠平滑增长

绕过 <progress> 的兼容性陷阱，用语义化但可控的结构更稳妥。关键不是“能不能动”，而是“动得稳不稳”：

1. 容器必须有明确宽度（max-width: 100% 或固定值），不能依赖 flex 自撑开再设子元素 width: 60%
2. 进度条内部元素设 height: 100% 和 background-color，避免高度塌陷
3. transition 写在进度条内部元素上，且只限定属性：transition: width 0.3s ease，别用 all
4. 初始状态强制 width: 0%，否则首次渲染可能从 100% 突然缩回
5. 更新时用 JS 改 element.style.width = '75%'，而不是 class 切换（后者需预定义多个 class，维护成本高）

响应式下百分比宽度为啥“看起来短了一截”

不是百分比错了，是盒模型和父级边距干扰了视觉比例：

1. 父容器用了 padding 但没设 box-sizing: border-box，导致实际内容宽度 = 100% - padding，进度条按 100% 算就溢出了
2. 移动端混用 vw 和 rem 做容器尺寸，而进度条内部用纯百分比，缩放不同步
3. 媒体查询里只调圆角、阴影等装饰属性即可，width 百分比逻辑无需重写——只要父容器宽度响应式，它自然跟着缩
4. 防溢出：给容器加 overflow: hidden，比靠 width 截断更可靠

IE11 或低版本 Safari 的兼容写法

不是加前缀就能跑，而是要避开它们根本不认的特性：

1. 必须加 -ms-transition: width 0.3s ease（IE11），但同时禁用 vw、flex-basis 等属性作为容器宽度依据
2. 避免用 calc() 在 width 里算百分比（如 width: calc(100% - 20px)），IE11 解析不稳定
3. 如果必须支持 IE11，建议 fallback 到 JS 驱动的 requestAnimationFrame 逐帧更新 width，比依赖 CSS transition 更可控

真正难的不是写那行 transition，而是确保整个链路——HTML 结构、父容器约束、盒模型、JS 更新方式——全部对齐。漏掉任意一环，动画就卡在 0% 或直接跳到终点。