@longpress在h5和微信小程序中不可靠，必须用touchstart+touchend+settimeout手动实现500ms长按判定，避免平台兼容性问题及事件冲突。
@longpress 在 H5 和微信小程序里根本不可靠
直接写 @longpress="deleteItem(index)，上线后大概率失效：H5 端只在 Chrome 84+ 且开启 enablelongtap 配置时才支持；微信小程序虽有该事件，但响应延迟高、易被父容器或子元素（如 input、scroll-view）拦截；支付宝/百度小程序则完全不支持。
这不是“偶尔失灵”，而是平台能力缺失。别等用户反馈“点半天没反应”才查文档——官方明确写了兼容性限制，必须绕开。
用 touchstart + setTimeout 实现稳定长按判定
核心逻辑是手动模拟 500ms 长按阈值：touchstart 启动定时器，touchend 或 touchmove 清除它。500ms 是实测平衡点——太短（如 300ms）易误触，太长（如 1s）用户感知迟钝。
-
touchstart.prevent必须加，防止触发默认滚动或缩放 - 每次 touchstart 前先
clearTimeout(this.longPressTimer)，避免重复注册导致多次弹窗 - touchend 中清除定时器即可，不用延时；但若需区分长按和点击，要配合
isLongPress标志位 +setTimeout(() => { isLongPress = false }, 200)防抖 - APP 端 iOS 若元素含
input，需加 CSS：user-select: none防止系统选中干扰
示例片段：
touchstart(index) {
clearTimeout(this.longPressTimer);
this.longPressTimer = setTimeout(() => {
uni.showModal({
title: '删除',
content: '确定要删除吗？',
success: (res) => {
if (res.confirm) this.list.splice(index, 1);
}
});
}, 500);
},
touchend() {
clearTimeout(this.longPressTimer);
}
同一个元素既要长按又要点击，怎么防冲突
关键不是“禁用点击”，而是用状态标记隔离行为：长按时设 this.isLongPress = true，点击事件开头加 if (this.isLongPress) return，并在 touchend 后短延时重置标志位。
- 不能在 touchend 立即设
isLongPress = false，否则快速点击会误判为长按结束后的点击 - 推荐延时 150–200ms 重置，既避开点击触发时机，又不让用户感知卡顿
- 如果列表项内有可点击子元素（如图标按钮），务必在子元素上加
@click.stop，否则事件冒泡会干扰主逻辑 - 震动反馈（
uni.vibrateShort()）建议只在长按确认后触发，避免误触时频繁震动
删除后数据同步不及时？问题常出在跳转时机
常见错误是删完直接 uni.navigateTo，但此时异步请求可能还没返回，页面跳走后数据仍是旧的。尤其多端联调时，H5 的 request 延迟更明显。
- 删除逻辑应放在
uni.showModal的success回调里，确保用户点了“确定”才执行 - 若删除依赖后端返回（如需刷新 token 或校验权限），应在
request的success中再做跳转或更新 - 全局数据（如
getApp().globalData）更新后，记得在目标页面onShow中重新读取，而不是只靠 onLoad - 不要在定时器回调里直接操作
this.list后不通知视图更新——uni-app 的响应式对 splice 是监听的，但若用下标赋值（this.list[index] = newItem）需用Vue.set或替换整个数组
最易被忽略的是：touchstart 绑定在 <image></image> 上时，iOS 下可能因原生渲染层拦截导致 touchend 不触发，建议把事件绑定到外层 <view></view> 容器，而非内部媒体元素。
