uni.vibrateshort用于轻量点击反馈（约40ms），uni.vibratelong用于较重操作确认（约400ms），二者均不支持自定义时长或频率，且ios需开启触感反馈、android需授权并适配厂商设置。
uni-app App端调用uni.vibrateLong和uni.vibrateShort的区别
App端（iOS/Android）震动反馈必须走原生能力，uni-app 封装了两个基础 API：uni.vibrateShort 用于轻量点击反馈（约40ms），uni.vibrateLong 用于较重操作确认（约400ms）。二者均**不支持自定义时长或频率**，是系统级固定行为，iOS 上还要求设备开启“触感反馈”且非静音模式才生效。
常见错误现象：uni.vibrateShort() 在真机无反应，大概率是 iOS 设置里关闭了“系统触感”，或 Android 厂商 ROM 屏蔽了后台震动权限（如小米、华为需手动开启“允许振动”）。
使用场景建议：
- 按钮点击确认、弹窗确定 → 用
uni.vibrateShort - 表单提交成功、关键操作完成 → 用
uni.vibrateLong - 连续快速点击 → 需加节流，避免高频触发被系统忽略（尤其 Android）
为什么uni.vibrate（带参数版）在App端不可用
早期文档曾提过 uni.vibrate({ type: 'light' })，但该 API **仅 H5 和小程序支持，App端完全不识别**，调用后静默失败，控制台也无报错。这是 uni-app 的平台差异陷阱——同名 API 在不同端行为不一致。
所以别写这种代码：
uni.vibrate({ type: 'light' }) // App端无效！
正确做法是按平台分支处理：
- App端：只用
uni.vibrateShort/uni.vibrateLong - H5端：可考虑
navigator.vibrate()（需检查兼容性） - 小程序端：用各自
wx.vibrateShort等（uni-app 已自动透传）
Android 端震动权限与厂商适配要点
Android 6.0+ 要求运行时申请 android.permission.VIBRATE 权限，uni-app 的 manifest.json 中必须显式声明：
"permissions": {
"android": ["android.permission.VIBRATE"]
}
但光有权限还不够。部分国产机型（如 OPPO、vivo）默认关闭应用的振动开关，需引导用户手动开启：
- 路径通常是：设置 → 应用管理 → [你的App] → 通知管理 → 振动提醒
- 可在首次点击按钮时，检测是否震动成功（通过
catch或延时判断），失败则弹 Toast 提示“请在系统设置中开启振动”
注意：uni.vibrateShort 在 Android 12+ 上可能因省电策略被延迟或丢弃，不要依赖它做关键交互反馈。
封装一个带防抖和平台判断的安全震动函数
直接裸调 API 容易出问题，推荐封装一层：
const safeVibrate = (type = 'short') => {
// 非 App 端跳过
if (!/app/.test(uni.getSystemInfoSync().platform)) return;
<p>// 节流：500ms 内只触发一次
if (safeVibrate._lastTime && Date.now() - safeVibrate._lastTime </p><p>if (type === 'short') {
uni.vibrateShort({ success: () => {}, fail: () => {} });
} else {
uni.vibrateLong({ success: () => {}, fail: () => {} });
}
};</p>
调用时直接 safeVibrate('short') 即可。这个封装避开了三个坑：平台误用、高频触发、失败静默。
震动不是万能反馈，尤其对听觉障碍用户不友好；复杂交互中过度使用反而干扰体验。App端真正可控的只有「有/无」，别在频率、波形上浪费时间。
