transition 宽度动画卡顿或不触发，主因是未设初始 width 或未声明 transition 属性；width 必须为具体数值（如 0%、50px），禁用 auto；需在起始状态写 transition，推荐用百分比和 CSS 变量配合 calc()，并注意兼容性与中断处理。
transition 宽度变化为什么卡顿或不触发
直接改 width 但动画不动，多数是因为元素没设初始 width 或没声明 transition 属性。浏览器只对可计算、可插值的 CSS 属性做过渡，width 必须是具体数值（比如 0%、50px），不能是 auto 或未设置。
常见错误现象：width: auto → 改成 width: 0%；漏写 transition: width 0.3s ease；或者父容器没设 overflow: hidden 导致进度条溢出看不见动画。
-
transition必须写在「起始状态」上，不是只在 hover 或 JS 修改时加 - 推荐用百分比（
%）而非像素（px），适配不同容器宽度 - 如果用 JS 动态更新，避免频繁读写
offsetWidth，否则强制同步布局，卡顿
如何用 CSS 变量 + transition 实现可控进度条
硬编码 width 值不灵活，尤其需要 JS 控制多个进度条时。用 --progress 自定义属性配合 width: calc(var(--progress) * 1%); 是更干净的做法，但注意：CSS 里 calc() 不能直接驱动 transition —— 必须把变量映射到真实可过渡属性上。
正确做法是让 JS 设置 style.setProperty('--progress', value)，同时 CSS 中用 width: calc(var(--progress) * 1%) 并保持 transition: width 0.4s cubic-bezier(0.3, 0, 0.2, 1)。
立即学习“前端免费学习笔记（深入）”；
- 必须给元素显式定义
width: 0%初始值，否则第一次 transition 不生效 -
cubic-bezier(0.3, 0, 0.2, 1)比默认ease更顺滑，适合进度类动效 - IE 不支持 CSS 变量，如需兼容，改用 class 切换（如
.progress-30）或 JS 直接写style.width
动画中断或跳变的典型原因
用户拖动、重置、或快速连续调用进度更新时，经常出现「跳到终点再回退」「卡在中间不动」——本质是 transition 正在执行时，新 width 值覆盖了旧动画的中间状态，浏览器直接跳转。
这不是 bug，是 CSS transition 的正常行为。要缓解，得靠 JS 层控制节奏：
- 用
getComputedStyle(el).width读当前宽度，再基于它做增量更新，而不是直接设目标值 - 在设置新
width前，先临时移除transition（el.style.transition = 'none'），设完再恢复，可避免跳变（适合重置场景） - 避免高频触发（如
input实时输入），加requestAnimationFrame节流
移动端 touch 事件下进度条响应延迟
在 iOS Safari 或部分安卓 WebView 中，单纯监听 touchstart/touchmove 更新进度，会明显滞后一帧甚至两帧。这是因为浏览器默认等待确认是否为滚动操作，触发了 300ms 延迟。
解决方法不是加 touch-action: manipulation（它只对点击有效），而是用 passive: false 显式接管 touch 流，并立刻调用 preventDefault() 阻止默认行为：
el.addEventListener('touchmove', e => {
e.preventDefault();
// 更新 --progress 变量
}, { passive: false });- 不加
{ passive: false }，iOS 下preventDefault()无效，延迟照旧 - 仅对进度条容器加该监听，别全局加，否则影响页面滚动
- 记得同时处理
pointerdown/pointermove，覆盖 Windows 触控笔等设备
实际项目里最常被忽略的是：progress 条的 height 和 border-radius 在不同分辨率下视觉比例失衡，尤其是圆角进度条缩放后边缘发虚。这和动画无关，但用户第一眼就注意到——得用 min-height + max-height 配合视口单位（vh）兜底。
