uni-app订单列表状态切换核心是状态参数传递、同步与防重复请求：跳转时用uni.navigateTo传status参数，onLoad立即读取并赋值；数据按status键缓存为对象，各Tab独立更新对应键值，避免覆盖和错乱。
uni-app 实现类似淘宝的订单列表状态切换，核心不是“怎么写 Tabs”，而是「状态参数怎么传、怎么同步、怎么避免重复请求和渲染错乱」。直接用 swiper + v-for 搞个切换栏，大概率在真机上点不动、滑不跟手、切换后数据没刷新、或者 iOS 下白屏。
Tab 切换时如何正确传递并响应状态参数
用户从「我的」页点击「待发货」跳转过来，目标页必须立刻高亮对应 Tab 并加载该状态数据——不能等页面渲染完再手动 setData，否则有闪动或空白。
- 跳转时用
uni.navigateTo传参：url: '/pagesOrder/list?status=2'（注意 status 值要和后端约定一致，比如 0=全部，1=待付款，2=待发货…） - 在目标页
onLoad中立刻读取：const { status } = options，然后赋值给data.nav_status_index - 别在
onShow里重新读options——它为空；也别依赖getCurrentPages()取上一页 data，跨分包不可靠 - 如果用自定义组件（如
lxs-tabs），确保其active属性是响应式的，且初始化时能接收props.defaultIndex，否则首次渲染不匹配
不同状态的数据请求如何避免互相污染
每个 Tab 对应一个独立订单列表，但共用同一个 orderList 数组变量，容易导致 A Tab 的数据覆盖 B Tab 的缓存，下拉刷新时又全清空。
- 按状态分 key 缓存：用对象而非数组存数据，例如
orderData = { '1': [...], '2': [...] }，每次请求前先查orderData[status]是否存在 - 请求成功后只更新对应 key：
this.orderData[status] = res.data.list，而不是this.orderList = res.data.list - 下拉刷新时，只重置当前
status对应的页码和数据，别清空整个orderData - 上拉加载更多时，也要判断
orderData[status].length ，否则可能重复请求已完成状态的“更多”
swiper + tabs 组合在 iOS 和小程序里的常见卡顿点
swiper 做滑动容器、view 做 tab 栏，看似标准，但在微信小程序和 iOS App 上极易出现「点中了但没高亮」「滑到一半卡住」「切换后 swiper 不同步」等问题。
- 确保
swiper的current绑定的是nav_status_index，且二者严格双向同步——@change回调里必须显式赋值：this.nav_status_index = e.detail.current - iOS 真机下
swiper的duration设为 300 以下会失灵，建议固定用300，别设0或1 - 不要给
swiper-item加v-if控制显示，用v-show；v-if会导致组件销毁重建，tab 内滚动位置丢失、input 失焦 - 如果用了第三方 tab 组件（如
u-tabs），检查它是否内部用了cover-view——这种节点无法被uni.createSelectorQuery获取尺寸，在做动态宽度计算时会返回null
空状态和 loading 的边界处理容易被忽略
用户第一次进「已完成」Tab，接口返回空数组，你渲染了「暂无订单」，但此时如果他切到「待付款」，再切回来，「暂无订单」可能还挂着，而实际已有新订单——因为没触发重新拉取。
- 每次 Tab 切换（无论是点击还是滑动），只要
nav_status_index改变，就应检查对应状态的数据是否已加载过；没加载过就发请求，加载过就直接渲染 - loading 状态要按 Tab 隔离：
loadingMap = { '1': false, '2': true }，不能共用一个isLoading变量 - 空状态模板里别写死文字，根据
status动态判断：比如 status=1 时提示「去付款」，status=4 时提示「去评价」，并绑定对应操作事件 - App 端首次冷启动时，
onLoad可能比网络请求还快，导致options.status还没读到就进了请求逻辑——加个if (!status) return防错
