根本原因是默认配置与真机渲染逻辑不匹配：iOS/Android对touch-move拦截策略不同，scroll-view嵌套、transform动画干扰导致手势失效；需显式设duration=300、禁用scroll-x/y共存、避免fixed/scale、H5加touch-action: pan-y，并用touchstart/end计算位移防误触。
uni-app里用swiper做滑动卡片，为什么左右滑不动或卡顿？
根本原因不是swiper不能用，而是默认配置和真机渲染逻辑不匹配。iOS和Android对swiper的touch-move拦截策略不同，加上scroll-view嵌套、css transform动画干扰，很容易导致手势失效。
实操建议：
- 必须显式设置
swiper的duration（推荐300），否则某些安卓机型滑动无反馈 - 禁用
scroll-y和scroll-x同时存在的父容器，避免滚动冲突 - 卡片内容避免使用
position: fixed或transform: scale()，会触发原生层叠上下文，阻断touch事件穿透 - 在
H5平台需额外加touch-action: pan-y到swiper外层容器，否则下拉刷新会抢走横向滑动手势
如何让每张卡片支持独立点击+滑动不误触？
关键在事件委托与防抖边界控制。直接给swiper-item绑@tap会和滑动冲突，系统无法区分“短按”和“快速滑过”。
实操建议：
- 用
@touchstart记录起始坐标，@touchend计算位移差，Math.abs(dx) 才触发点击逻辑 - 在
data中维护isDragging标志位，滑动开始时置true，transitionend后延时settimeout置false - 卡片内部按钮用
@click.stop，防止冒泡干扰父级滑动判断 - 不要依赖
current属性实时取值做点击响应——它有延迟，应以@change回调返回的detail.current为准
自定义Swiper组件时，如何兼容小程序/APP/H5三端轮播逻辑？
各端swiper的autoplay行为差异极大：微信小程序自动播放不暂停，App端触碰即停但无回调，H5则可能因visibilitychange被浏览器休眠。硬写一套定时器容易失控。
实操建议：
- 统一用
setInterval+this.$refs.swiper?.change()手动切页，避开原生autoplay - 监听
visibilitychange事件，在页面不可见时clearInterval，回来后再重置计时器 - App端需额外监听
plus.navigator.getStatusBarHeight变化（如横竖屏切换），触发resize重排版，否则卡片高度塌陷 - 小程序端若用
web-view嵌套，禁止在其中使用swiper——原生组件不支持嵌套渲染
卡片带阴影/圆角/缩放动画时，为什么真机性能骤降？
不是JS慢，是swiper-item内CSS触发了频繁的合成层重建。尤其box-shadow和border-radius在非GPU加速区域绘制，安卓低端机一帧掉到10fps。
实操建议：
- 把阴影改用
background: linear-gradient()模拟，或用filter: drop-shadow()（仅H5有效） - 圆角强制加
overflow: hidden+will-change: transform，告诉引擎该元素将动画 - 缩放动画改用
scale3d(1.05, 1.05, 1)而非scale()，启用GPU加速 - 卡片数量超过5个时，用
v-if控制只渲染当前页±1范围内的swiper-item，其余设为display: none
最易被忽略的一点：swiper的circular属性开启后，首尾两张卡片实际是同一DOM节点复用，如果在@change里直接操作ref或dataset，会导致状态错乱。得用detail.source === 'touch'来过滤非用户触发的切换。
