scroll-view + swiper 组合是 uni-app 中实现品牌滑动切换最稳定方案，因纯 swiper 存在标签不居中、事件延迟、无法实时高亮三大硬伤，而二者配合可双向绑定实现滚动与切换同步，且需动态计算 dom 宽度确保准确定位。
scroll-view + swiper 组合是目前 uni-app 中实现「品牌滑动切换」最稳定、兼容性最好的方案，尤其在微信小程序和 App 端表现一致。纯 swiper 做 tab 切换容易卡顿或响应延迟；纯 scroll-view 又无法联动内容区域滚动。二者配合才是正解。
为什么不能只用 swiper 控制 tab 栏？
uni-app 的 swiper 在 tab 导航场景下有三个硬伤：
• current 改变时，tab 标签不会自动居中对齐（尤其标签多、宽度不均时）
• 小程序端 bindchange 事件触发有约 80–120ms 延迟，用户快速滑动后松手，常出现“跳帧”或“回弹错位”
• scroll-x 模式下，swiper 无法监听手指拖拽过程中的实时偏移，没法做“跟随式高亮”效果（唯品会那种标签随滑动渐变高亮）
所以品牌栏必须用 scroll-view 实现可滚动导航，内容区用 swiper 同步切换——二者靠 current 和 scroll-into-view 双向绑定。
scroll-view 如何让品牌标签横向滚动且居中高亮？
关键不是写死样式，而是动态计算每个标签宽度并控制滚动位置：
• 给每个 scroll-view 子项（即品牌 item）加 id，格式如 brand-0、brand-1
• 使用 scroll-into-view="brand-2" 触发滚动定位（注意：该属性只在 scroll-x 为 true 时生效）
• 高亮逻辑不能只靠 class 切换，要结合 transform: scale(1.1) + opacity 渐变，否则 iOS 微信里动画生硬
• 必须监听 scroll-view 的 bindscroll 事件，手动计算当前可视区域中心点落在哪个标签范围内，再更新高亮索引 —— 这一步绕不开，否则无法实现“滑动中实时高亮”
swiper 和 scroll-view 怎么保持同步？
双向绑定不是靠 watch，而是靠事件驱动：
• 用户点击 tab → 触发 scroll-view 的 scroll-into-view + 更新 swiper 的 current
• 用户滑动 swiper → 监听 @change，拿到 detail.current，再调用 scroll-view 的 scrollTo 方法（需用 this.$nextTick 确保 DOM 渲染完成）
• 注意：小程序里 scrollTo 不支持平滑滚动，要用 scroll-left + 动态计算偏移量模拟，公式是：offset = itemWidth * currentIndex - (viewWidth / 2) + (itemWidth / 2)
• App 端可直接用 scrollIntoView API，但 H5 端需 fallback 到 scrollLeft，务必做平台判断
性能坑：iOS 微信里 scroll-view 卡顿怎么办？
这不是代码问题，是微信 WebView 的渲染限制：
• 避免在 scroll-view 内放过多图片或复杂组件，品牌图标统一用 image 标签 + mode="aspectFill"，禁用 lazy-load
• 所有品牌标签的宽高必须是固定值（rpx 或 px），不能用 flex 自适应，否则 iOS 下重排频繁
• 关键样式加 will-change: transform 强制启用 GPU 加速
• 如果品牌数超过 15 个，建议分页懒加载，用 intersectionObserver 监听可视区域，而不是一次性渲染全部
实际开发中最容易被忽略的，是 scroll-view 的 scroll-left 计算必须基于真实 DOM 宽度，而非预设值 —— 尤其当品牌名长度不一、字体渲染差异存在时，getBoundingClientRect() 获取的 width 才可靠。别图省事写死数值，那会在不同机型上错位。
