最稳方案是用 scroll-view + v-for 渲染时间轴，配合 css flex 实现节点、图标、连接线；ios 兼容需降级为 line-height 居中和绝对定位连接线；滚动定位用 createselectorquery + scrollto 替代 scroll-into-view；状态更新必须替换整个数组而非修改原对象。
uni-app 里实现订单状态时间轴，用 scroll-view + v-for 最稳
直接上结论：别用第三方组件库封装的「时间轴」，uni-app 的 scroll-view 搭配原生 v-for 渲染是最可控、最兼容、最易调试的方式。京东那种带节点图标、状态文案、时间戳、横向连接线的样式，靠 CSS Flex 就能搞定，不需要 JS 动态计算位置。
常见错误是硬套 Vue 社区的 el-timeline 或 ant-design-vue 组件——它们依赖 DOM 高度测量或 ResizeObserver，在 uni-app 的 App 端（尤其是 iOS WKWebview）会失灵，节点错位、连线不显示、滚动卡顿都是常态。
- 状态数据结构建议用数组，每个对象含
status（如"paid"）、title（如"已支付"）、time（ISO 格式字符串）、active（布尔值，标出当前进行中） - 横向连接线用伪元素
::before实现，避免额外标签和布局干扰 - 图标统一用 uni-app 内置的
uni-icons或字体图标，别用 img 标签——App 端图片路径容易 404
时间轴节点对齐问题：iOS App 端 flex 行为不一致怎么破
uni-app 编译到微信小程序基本没问题，但 App 端（尤其 iOS）的 display: flex 对 align-items 和 justify-content 解析有偏差，常导致节点图标偏上、文字没居中、连接线断开。
根本原因是 iOS Webview 的 Flex 实现较旧，不支持某些新属性。绕过方式不是升级，而是降级写法：
- 节点容器不用
display: flex做垂直居中，改用line-height匹配容器高度 +text-align: center - 连接线不用
flex: 1占位，改用固定宽度width: 2px的绝对定位 div，父容器设position: relative - 所有尺寸单位优先用
px，少用rpx——rpx 在 App 端换算不稳定，特别是涉及伪元素时
scroll-view 滚动到底部自动定位当前状态节点？别用 scroll-into-view
很多人想让时间轴打开时自动滚动到当前进行中的那一步，于是查文档用 scroll-into-view 绑定 id。这在 H5 和小程序可行，但在 App 端（尤其 Android）经常失效——因为 scroll-view 的子节点没渲染完成就触发了滚动。
更可靠的方案是手动调用 scrollTo API，配合 $nextTick 和节点 offsetTop 计算：
uni.createSelectorQuery()
.in(this)
.select(`#step-${this.activeIndex}`)
.boundingClientRect()
.exec(res => {
if (res[0]) {
this.$refs.scrollView.scrollTo({ scrollTop: res[0].top - 100, duration: 300 })
}
})
- 必须等
v-for渲染完再查节点，所以放在$nextTick里执行 -
scrollTop要减去一个偏移量（比如 100），避免节点贴顶看不清上下文 - 不要用
scroll-into-view的字符串 id 绑定，App 端对动态 id 支持差，容易找不到元素
状态变更后重绘时间轴：别直接 splice 或 push 数组
订单状态是可能实时更新的（比如从「待发货」变成「已发货」），如果直接修改原始数组，uni-app 的响应式系统有时不会触发视图更新，尤其当新状态插入中间位置时。
关键点在于：uni-app 的 v-for 对数组引用变化敏感，但对内部对象属性变化不敏感（除非用 Vue.set）。所以状态更新要走「替换整个数组」的路子：
- 每次收到新状态数据，用
map生成全新数组，而不是forEach修改原对象 - 如果只是改某个节点的
active，也要返回新数组：this.timeline = this.timeline.map(...) - 避免在
data里直接定义 timeline 为Object，它必须是Array，否则v-for不会响应
这点容易被忽略——看着界面没变，其实是 Vue 没检测到变化，不是样式或逻辑问题。
