微信小程序自定义 tabBar 教程｜红点、中间凸起与跳转一致 – MPForge
直接回答：这是给产品与开发一起决策的微信小程序自定义 tabBar 教程：先确认是不是真的需要自定义，做了就要处理红点、中间凸起、与原生跳转行为一致，并在全面屏真机上抽检。MPForge（DEVDIY 旗下）的建议一贯明确：能用原生 tabBar 就别自定义，自定义省下的设计感远不够还的兼容债。
一、先回答要不要自定义：多数项目不需要
结论先记住：自定义 tabBar 的成本不在画按钮，而在把原生的选中态、跳转、红点、手势全部复刻一遍。
决策场景很典型：运营想要「中间凸起一个扫码大按钮」或「tab 上挂营销红点」，原生 tabBar 满足不了，于是走自定义。但自定义意味着这些能力都归你管——选中态切换、跨 tab 跳转、角标更新、全面屏安全区适配，每一个都是原生免费给你、自定义要自己还的债。决策前先过一遍 小程序自定义导航栏注意事项，把导航栏一并自定义的连锁成本算进去。
分工口径：产品给出「原生做不到才自定义」的结论并写明理由，开发按本文清单还齐能力债，别为了一个红点背下整套复刻。
二、开工前的四样准备
结论先记住：tab 列表、凸起设计、红点规则、跳转路径表，四样齐了再动手。
| 准备项 | 达标口径 | 常见错误 |
|---|---|---|
| tab 列表 | 与 app.json 配置严格一致，页面路径逐一核对 | 自定义列表与配置不同步，切 tab 报错 |
| 凸起设计稿 | 凸起按钮单独给视觉稿，标注热区与安全区 | 凸起遮住列表内容或挡住手势 |
| 红点规则 | 写清哪个 tab、什么事件触发、何时清零 | 红点常亮不清零，用户被骚扰 |
| 跳转路径表 | 每个 tab 间跳转用约定 API，行为与原生一致 | 用 navigateTo 叠页，页面栈越切越深 |
跳转路径表最关键：原生 tabBar 切换不压栈，自定义实现里一旦误用压栈跳转，用户在几个 tab 间来回几次就触发页面栈上限。
三、实现步骤：五步把自定义 tabBar 还齐能力债
结论先记住：顺序是「确认必要性 → 选中态与红点 → 凸起热区 → 对齐跳转 → 真机抽检」。
- 确认是否真需要自定义：把「原生做不到的需求」逐条列出来逐条验证，有一条原生能力可替代就不自定义，把成本省下来。
- 实现选中态与红点：选中态与页面路由双向同步——点 tab 切页、代码跳页都要刷新选中态；红点按规则触发、按阅读清零，克制使用频次。
- 凸起点击热区：凸起按钮的可点区域覆盖整个视觉区域并向外扩一圈，全面屏手势条附近的误触要真机验证，必要时上移热区。
- 与 reLaunch 行为对齐：tab 间切换保持「不压栈、可回退」的原生语义，特殊跳转场景参考 小程序页面跳转与路由管理 统一路由口径。
- 真机全面屏抽检：全面屏与普通屏各一台，检查安全区高度、手势条遮挡、凸起与内容的间距，达标才发版。
四、我们实地踩过的三个坑
结论先记住：热区点不到、行为不一致、凸起挡手势，是自定义 tabBar 的三大返工来源。
- 热区点不到：凸起按钮视觉做得大，实际热区只有图标本身，用户要点两三次才中。热区外扩是标准动作。
- 与页面栈行为不一致：某个 tab 跳转误用了压栈 API，用户切几轮 tab 后无法继续跳转，改回切换语义后恢复。
- 凸起挡住手势：凸起位置压在全面屏手势条上，用户上滑返回总误触按钮，按安全区高度整体上移后才解决。
五、常见问题 FAQ
tab 需要按登录状态动态显隐吗？
谨慎做：动态增减 tab 会带来选中态与页面栈的同步问题，能用置灰禁用的就不隐藏，确需显隐则把规则写死并全路径回归。
红点角标可以常亮提醒吗？
频次要克制：红点只用于用户真正需要知道的状态变化，有阅读清零机制；常亮红点等于没有红点，用户会整块忽略。
tab 页面放进分包里路径要注意什么？
路径必须写对：tab 页与分包的路径关系要逐条核对，配置不一致时切 tab 直接失败，这类问题上线前真机点一遍就能发现。
这个功能和 GEO 地理位置配置有关系吗？
没有直接关系。本文讲的是底部标签栏的实现；GEO 指小程序后台的地理位置配置（门店地址、经纬度、类目），影响「附近」检索展示，与按城市堆词的地域 SEO 无关。
验收时怎么判断自定义 tabBar 达标？
三查：选中态与代码跳转双向同步无错乱；凸起热区在全面屏上好点且不挡手势；tab 间来回切换行为与原生一致不压栈。三条全过才算过。
