uni.hidetabbarreddot调用无效主因是index错误或调用时机不当：需严格按pages.json中tabbar.list数组下标（从0开始）确认index，避免在非tabbar页面调用；应于用户操作后立即调用而非onshow中；若存在数字角标须先uni.removetabbarbadge再hide。
uni.hideTabBarRedDot 调用无效？先确认 index 是否合法
红点去不掉，八成是 index 值错了。TabBar 中间按钮（比如“发现”或“首页”）的索引不是凭感觉数的——它严格对应 pages.json 里 tabBar.list 数组的下标，从 0 开始。如果 tabBar 有 5 项：["首页", "分类", "中间页", "购物车", "我的"]，那中间页的 index 就是 2，不是 3 或 “居中就该是 2.5” 这种错误理解。
常见误操作：在非 tabBar 页面（如消息详情页）调用 uni.hideTabBarRedDot({index: 2})，但该页面根本不在 tabBar.list 里，API 会静默失败，控制台也不报错。
- 打开
pages.json，定位到tabBar.list，手动数一遍目标按钮的位置 - 确保当前运行环境支持该 API：H5 不支持，App 和小程序端基本都支持，但支付宝小程序偶有延迟
- 真机调试时，iOS 上红点消失可能有 100–300ms 延迟，别刚调完就断定失败
调用时机不对：onShow 里执行太晚，页面已渲染完成
很多开发者把 uni.hideTabBarRedDot 放在目标页面的 onShow 里，结果红点闪一下才消失——这是因为 TabBar 红点是在页面切换前就渲染好的，onShow 触发时，红点已经画上去了。
更稳妥的做法是：在用户“处理完消息”或“标记为已读”这类明确动作之后立刻调用，而不是等页面显示出来再清理。例如，在点击“全部已读”按钮的回调里直接执行：
uni.hideTabBarRedDot({ index: 2 })
如果逻辑分散，建议统一收口到一个状态管理函数里，避免多处重复调用或遗漏。
- 不要依赖页面生命周期（如
onLoad、onShow）来清理红点，它们不是清理的可靠时机 - 若需进入页面即无红点，应在上一个页面跳转前就调用
uni.hideTabBarRedDot - App 端（尤其 Android）有时需要加
setTimeout延迟 10ms 再调用，才能确保 DOM 渲染节奏对齐
红点还在？可能是 setTabBarBadge 和 showTabBarRedDot 混用了
一个 tab 项上不能同时存在数字角标和红点。如果之前调过 uni.setTabBarBadge({index: 2, text: '3'})，再调 uni.hideTabBarRedDot({index: 2}) 是没用的——因为此刻显示的是数字，不是红点。
要彻底清空右上角提示，得按类型分别处理：
- 有数字角标 → 必须用
uni.removeTabBarBadge({index: 2}) - 只有红点 → 用
uni.hideTabBarRedDot({index: 2}) - 不确定当前是什么 → 先调
uni.removeTabBarBadge，再调uni.hideTabBarRedDot，双保险
注意：uni.removeTabBarBadge 和 uni.hideTabBarRedDot 都不会报错，即使目标项当前没角标或红点，所以可以放心连写。
iOS 真机上红点残留？检查通知权限与系统角标干扰
极少数情况下，iOS 真机上 TabBar 红点看似清不掉，实际是被系统级应用图标角标（plus.runtime.setBadgeNumber 设置的）视觉干扰了。这两个是完全独立的机制：
-
uni.hideTabBarRedDot只影响底部 tabBar 项上的红点 -
plus.runtime.setBadgeNumber(0)只影响 iOS 应用图标右上角的数字角标 - 两者互不感知，但用户肉眼容易混淆
如果你在 App 启动时调过 plus.runtime.setBadgeNumber(3)，又没在用户处理后设回 0，就会出现“TabBar 红点没了，但图标上还有 3”的假象。
解决方法很简单：清理逻辑里补上这句（仅 iOS 有效）：
if (uni.getSystemInfoSync().platform === 'ios') {
plus.runtime.setBadgeNumber(0)
}
