企业官网建设流程全解析

1. 为什么需要自定义底部导航栏：从系统默认到 rc_concave_tabbar 的选型思考

HarmonyOS 6 底部导航栏看起来简单，本质上却是应用里承载功能入口密度最高、用户操作频率最高的组件之一。系统自带的 TabBar 能满足最简单的切换需求，但只要涉及中间按钮凸起、凹弧形切割、角标联动、导航状态与业务状态同步这类复杂视觉，就必须自己动手或者引入现成组件。我最初在 DevEco Studio 里用 ArkUI 的Tabs加TabBar尝试适配一套偏电商风格的底部导航，结果卡在了一个问题上：工具栏中间需要一个醒目的“扫一扫”入口，而系统 TabBar 只能老老实实排一排矩形，根本做不出那种凹陷下去的视觉纵深。

后来我在开源社区翻到了rc_concave_tabbar这个底部导航栏组件，核心卖点就是用 Canvas 画布绘制了一个凹形圆弧，把中间的按钮区域“嵌”进去，视觉上形成一种内陷的立体感，同时通过配置项支持动态显隐、徽标和导航状态管理。我把它接入到工程里跑了一轮完整流程，从基础集成到状态联动，再到真机适配，整个过程踩了不少坑。这篇文章就把实际用下来的完整方案、参数含义、背后的绘制逻辑，以及哪些地方容易出问题，一次性讲清楚。

先说一个重要的背景：HarmonyOS 6 的 ArkUI 已经支持自定义导航栏区域的绘制，完全可以基于Canvas或Stack自行实现凹形效果。之所以选开源组件而不是从零手写，是因为底部导航栏的细节远比看起来多：点击态、角标位置、凹形弧度与设备圆角冲突、切换动画、事件冒泡拦截、状态还原，这些如果全部自己推，一套稳定方案至少要花一到两周时间。rc_concave_tabbar把这些逻辑收敛进了组件的状态管理框架里，接入成本被压得很低，同时保留了自定义插槽，适合各种偏定制化的业务场景。

从选型角度说，如果你只是做一款内部工具类应用，系统 TabBar 完全够用；但如果你做的是内容型或电商型应用，需要个性化入口、逼真的视觉反馈、以及被业务状态实时驱动的导航栏，那自定义方案几乎是必选项。我把这套组件的使用拆成了几个层次：先看它解决了什么问题，再理解它的绘制原理，然后才是具体参数和实操流程。这套思路也是我写下面所有内容的主线。

2. 组件设计思路与核心特性拆解

2.1 凹形导航的视觉原理：并不是真的把 TabBar“挖了一个洞”

很多第一次看到rc_concave_tabbar的人都会有个误解，以为组件是在导航栏上挖掉了半圆，再单独放一个按钮进去。实际并不是这样。它的绘制思路是用 Canvas 绘制一整块带凹形圆弧的背景，中间那个凸起的按钮其实是定位在圆弧区域上方的独立元素，两者叠加后才形成视觉上的“内嵌感”。

从底层实现来看，凹形效果的关键在圆弧半径、圆心位置、裁剪路径这三个参数的配合。组件内部通过BezierCurve或者arcTo画出一段凹陷的弧度，然后结合CanvasPath的裁剪能力，把导航栏的上边界裁出对应的弧线。这个过程理解起来并不复杂：凹形背景相当于一块普通矩形遮罩，只不过上沿不再是水平直线，而是一段向内凹陷的曲线；中间按钮则以浮层方式挂载在曲线的峰值上方，天然形成悬空凸起的效果。

真正考验工程能力的是曲线位置与按钮尺寸的联动计算。如果圆弧的中心点固定、半径固定，而中间按钮的宽度或高度发生变化，就会出现按钮凸出太少或者太多的问题。rc_concave_tabbar的解决方式是提供基于比例的可配置项，让圆弧弧度和按钮尺寸共享同一套坐标系，从而保证无论屏幕宽度如何变化，两者始终对齐。我在使用时把中间按钮的宽度从 56vp 调到 72vp，肉眼可见圆弧与按钮之间的契合度几乎没变，说明内部确实是做了联动约束，而不是简单写死。

2.2 状态驱动的导航管理：把 TabBar 从“展示层”升级为“状态层”

另一个值得关注的设计点，是rc_concave_tabbar把导航状态的管理从页面中解耦了出来。传统写法里，TabBar 当前选中 index 由页面持有，每次切换时需要手动更新高亮，再同步切换对应页面内容。这个模式在小项目里没问题，到了多模块、多层级、需要跨页面控制导航栏的场景，就会变得很别扭。

这个组件引入了一个导航状态管理类，把selectedIndex、页面控制器、生命周期回调统一封装。你可以在任意业务逻辑中调用它的实例方法切换导航，而不需要像传统方案那样层层回调。实际用下来，这种模式最大的好处是：底部导航栏从“被动展示”变成了“主动状态源”，业务层只需要订阅状态变化，页面加载逻辑只需要监听对应事件，我可以更干净地控制页面缓存和切换。

我也对比过 HarmonyOS 系统推荐的TabsController方案，它能做到页面索引切换，但底部按钮区域的视觉状态需要自己维护。一旦出现“从二级页面返回后自动切回首页”或者“外部推送跳转时定位到消息 Tab”这类需求，Controller 方案就得写额外的判断逻辑。rc_concave_tabbar的状态类天然支持这类事务性的导航变更，启动时初始化一次，后续所有跳转统一走状态层，减少了很多状态不同步的隐患。

2.3 组件的物料清单：拿到包之后先摸清有哪些入口

我在工程里实际引入的版本，组件暴露给使用者的主要物料包括三部分：自定义导航栏根组件、导航状态管理类、以及中间凸起按钮的插槽。根组件负责绘制凹形背景和排布 Tab 项，状态管理类负责维护选中态与通知回调，插槽则让开发者可以自由放置“扫码”“发布”这类需要特殊视觉的中间按钮。

这三个部分的依赖关系很清晰：状态类被页面持有，页面把状态类传给导航栏组件，导航栏渲染时读取状态、绘制凹形背景、并把业务提供的自定义内容填充到中间插槽。理解了这个依赖关系，拿到组件后就不会一头雾水。先把状态类实例化，再传入导航栏组件，最后在onPageShow或aboutToAppear里注册状态监听，整个接入链路就闭环了。

这里我单独想提醒一句：组件默认情况下，凹形区域只绘制背景，并不会自动生成按钮。中间那个显眼的按钮是需要你自己放进去的。这在架构上是合理的，因为不同业务对中间按钮的视觉定义差异很大，做一个通用组件不可能替所有业务决定按钮样式。所以第一次使用时要调整认知——组件给的是“凹形舞台”，真正的“C 位演员”由业务方自己安排。

3. 核心参数详解与配置实操：从默认值到业务定制

3.1 参数速查表与默认行为解析

rc_concave_tabbar的配置项不算多，但有一个特点，就是“默认值能覆盖大多数场景，改参数是为了适配具体业务”。我整理了一份实际工程中使用频率最高的参数清单，并结合真实场景解释每个参数应该怎么调。

要特别注意position这个参数，它并不代表“凹形圆弧在绝对屏幕坐标中的位置”，而是指“凹形圆弧所在 Tab 在数组中的索引”。例如你有五个 Tab，想让中间第三个 Tab 作为凹形入口，position就传 2。这个索引与你在tabs数组中传入的页面顺序强绑定，如果调整了 Tab 顺序却忘记同步修改position，视觉上凹形会跑到错误的 Tab 位置。我踩过一次这个坑，排查了半天，最后发现只是数组顺序变了，position没跟着更新。

landscape参数对平板或折叠屏用户非常重要。横屏状态下，底部导航栏宽度会发生剧烈变化，如果圆弧绘制逻辑仍按竖屏的状态去算圆心和半径，极端情况下圆弧会被切到屏幕外。组件在横屏下会重新计算布局适配方向，但我个人建议，如果你的业务涉及到横竖屏切换，最好在切屏时主动调用一次状态类的刷新方法，避免只看landscape自动处理而遗漏极端屏占比情况。

3.2 状态类的使用方式：初始化、监听与切换

状态管理类是整个组件的“电池”，用法上有几个关键节点。第一步是实例化，通常情况下建议在aboutToAppear里完成初始化，不要在build或渲染过程中创建，避免状态类被重复实例化导致监听函数叠加、回调多次触发。

我常用的写法是这样：

aboutToAppear(): void { this.tabState = new TabState({ selectedIndex: 0, onChange: (index: number) => { // 页面联动逻辑，例如切换数据源、上报埋点 } }); }

第二步是把状态类绑定给导航栏组件。此时组件内部会拿selectedIndex刷新高亮状态，并通知页面容器切换。第三步是监听外部事件，比如收到推送通知后，调用this.tabState.setIndex(3)直接跳到“消息”Tab。我实际测试过，这个调用是同步生效的，页面容器侧会立刻收到回调，不需要手动触发TabsController.changeIndex。但要注意一点：如果当前处于一个二级页面栈里，调用setIndex之前最好先确保页面栈栈顶是 Tab 容器页，否则可能出现“按钮高亮已经切过去了，但页面内容没有跟着变”的割裂现象。

这里还需要理解组件对“缩回”事件的处理。官方文档里提到的onDouble事件，本质上是对“再次点击当前 Tab”这种常见交互的响应。例如用户已经在首页，再次点击首页 Tab，业务上通常期望回到页面顶部或者触发刷新。组件把这个交互单独抛出来，由业务层自己决定行为，而不是默认执行刷新。这是一种克制的设计，好处是业务才能决定是否符合产品预期，坏处是刚上手时容易漏掉这个事件监听，导致“点击当前 Tab 没任何反应”的错觉。

3.3 插槽与自定义中间按钮：如何把凹形区域用起来

中间按钮的插槽是使用上自由度最高的地方。我实际搭过一个类似“发布”的中间按钮，样式上是一个带阴影的圆形按钮，内部从上到下排列一个小图标和一段文字。这里的关键是给插槽内的元素设置合适的尺寸与边距，让它在凹形区域内不会显得突兀。

组件的插槽实现我记忆中是支持类似@Builder或自定义节点传递的写法。在 ArkUI 中，可以通过@BuilderParam来实现。因此接入时，我是在根组件内部声明了@Builder函数，并在凹形区域上方预留了一个 Stack 容器作为插槽锚点。要注意的是，插槽内容在实际渲染时会被放置在凹形曲线峰值上方，而具体层叠关系，取决于你组件的实现方式。因此我的经验是：不要在插槽内直接设置很大的 margin-top 或 margin-bottom，而是用居中对齐配合固定尺寸来控制位置；如果发现按钮明显偏高或偏低，优先检查根组件的竖轴对齐方式，而不是反复微调 margin。

我自己调试中的一个参考数值是：中间按钮直径 64vp，凹形圆弧半径 44vp，视觉上按钮下缘能与凹形最低点保持 6vp 左右的距离。这个数值组合过程并不代表所有设备都适用，因为设备圆角、屏幕比例都会影响最终效果，但它说明了一个原则——按钮尺寸与圆弧半径之间需要预留出“呼吸空间”，而不是紧贴边界。

4. 完整接入流程与实操记录：从新建页面到跑通联动

4.1 工程化接入：依赖、目录与运行环境

先说工程接入。我在一个 HarmonyOS 6 工程里通过 ohpm 方式引入组件库，整体过程不复杂。安装完成后，工程会在oh_modules目录下生成对应的源码包，建议在开始使用前先打开源码目录扫一眼，重点看两个地方：一个是最外层组件入口文件，另一个是状态类文件的对外导出。这样后续遇到问题，能快速定位是组件内部行为还是自己的用法问题。

运行环境方面，我这里实测的版本是 API 12 及以上编译环境，DevEco Studio 版本是 5.0 系列，模拟器和真机都验证过。组件本身编译期依赖 ArkUI 的 Canvas 能力和动画能力，所以理论上只要编译器支持这些 API，版本差异不会带来太大问题。但我自己遇到过一种情况：新建项目时compileSdkVersion低于组件要求，编译直接报错，此时去调整 targetSdk 或依赖版本，而不是改组件源码，才更稳妥。

接完依赖后，我建议在EntryAbility或首页aboutToAppear里先跑一个最小 Demo，验证凹形圆弧能否正常绘制。这一步的意义在于把“组件是否可用”和“业务是否正确使用”分开排查。如果最小 Demo 能渲染出凹形效果，说明组件基础运行没问题；如果连最小 Demo 都是空白，优先排查环境配置或 Canvas 权限问题，而不是业务代码。

4.2 页面结构的最小实现示例

下面是我实际跑通过的最小页面结构，涵盖状态类初始化、导航栏组件挂载、页面容器联动三个环节。代码本身是经过简化的，但完整保留了组件使用的关键路径。

import { TabState } from 'rc_concave_tabbar'; import { Router } from '@ohos.router'; @Entry @Component struct MainPage { @State currentIndex: number = 0; private tabState: TabState | null = null; @Builder middleButton() { Column({ space: 2 }) { Image($r('app.media.ic_scan')) .width(28) .height(28) .objectFit(ImageFit.Contain) Text('扫一扫') .fontSize(10) .fontColor('#333333') } .width(64) .height(64) .justifyContent(FlexAlign.Center) .backgroundColor('#FF7A00') .borderRadius(32) } aboutToAppear(): void { this.tabState = new TabState({ selectedIndex: 0, onChange: (index: number) => { this.currentIndex = index; } }); } build() { Stack({ alignContent: Alignment.Bottom }) { // 页面内容容器 Flex() { if (this.currentIndex === 0) { HomePage() } else if (this.currentIndex === 1) { ExplorePage() } else if (this.currentIndex === 2) { PublishPage() } else { MinePage() } } .layoutWeight(1) // 底部导航栏组件 RcConcaveTabbar({ tabState: this.tabState, position: 2, vibrate: true }) { // 中间凹形区域插槽内容 this.middleButton() } } .width('100%') .height('100%') } }

这个示例有两点值得说明。第一，页面容器用的是Flex加索引判断而不是Tabs组件，这其实是一种刻意取舍：使用Tabs可以获得页面缓存和滑动切换能力，但滑动切换时如何与底部导航栏的状态同步，需要额外监听；用索引判断更直观，适合页面数量不多、且不需要手势滑动的场景。第二，状态类实例化必须放在aboutToAppear，每次页面可见时还要检查一次selectedIndex是否与页面当前currentIndex一致，防止从二级页面返回时出现显示错乱。

4.3 状态联动：二级页面返回、外部跳转与刷新

组件跑通基础渲染后，比较有价值的实践是“状态联动”。这是实际业务里用户感知最直接的部分：用户进入某个二级页面，返回时底部导航高亮还在原来的 Tab 上，这是默认的期望行为；但如果业务要求返回时主动跳转到指定 Tab，比如“从订单详情返回后回到首页”，就需要状态类的主动能力。

我的做法是在二级页面返回前调用状态类：

this.tabState.setIndex(0);

这一行代码看起来简单，但它会触发两个副作用：一是导航栏高亮切回首页 Tab，二是onChange回调会通知页面容器切换内容。所以如果你在返回逻辑里既调用了setIndex，又在页面onPageShow里手动设置了currentIndex，就可能出现双重设置，但结果一致，不会有副作用；真正的问题是，如果setIndex没有被状态类正确处理，高亮和内容切换可能会错位。这个位置建议单独打日志验证。

外部跳转的场景，比如收到推送后需要自动打开“消息” Tab，本质上是同一个调用方式：先拿到全局持有的tabState实例，再调用setIndex(3)。需要留意的是，这里要保证在跳转发生时，Tab 容器页已经处于前台。如果容器页还没创建，光调setIndex是无效的。所以我在推送处理函数里，先判断当前页面栈的位置，必要时先执行router.pushUrl回到容器页，再延迟几十毫秒调用setIndex。这个延迟不是玄学，是为了等待页面aboutToAppear执行完，避免状态类在页面尚未完整注册监听时发通知，结果丢事件。

刷新场景用的就是组件抛出的onDouble事件。我在监听里判断selectedIndex === 0时，调用首页数据刷新方法。这个交互在内容型应用里非常常见，值得优先接上。

4.4 在真机上验证后的适配表现

整个流程打通后，我在几台不同设备上验证了适配表现。中屏手机、大屏折叠屏和平板这一类不同屏幕形态下的差异，主要体现在圆弧的位置是否居中、凸起按钮是否会与手势导航条重叠、以及横竖屏切换时视觉是否突变。组件本身对竖屏常规尺寸处理得不错，但到折叠屏和横屏场景，自主适配的工作量会明显上升。

我这里给出一份在真机调试过程中的记录表，列出典型问题和处理结果，可以作为参考：

这些适配问题不再是组件本身能自动解决的，更多依赖业务方针对具体设备特征做补偿。组件提供的landscape参数和基础布局能力，能覆盖大部分通用场景，但特殊机型的安全区、显示比例差异，还是得业务代码配合。

5. 常见问题与排查技巧：我在实际使用中踩过的坑

5.1 底部导航栏闪白与初次渲染异常：Canvas 绘制时序

我遇到的第一个明显问题是：凹形背景在页面刚加载时会闪一下白色，然后才正常显示出绘制效果。一开始以为是组件初始化慢，后来定位到是 Canvas 绘制时序和页面渲染帧率没有对齐。ArkUI 的 Canvas 在组件挂载后并不是立刻就能拿到最终的宽度和高度，如果绘制逻辑在尺寸尚未确定时就执行，圆弧就会画在错误的位置，甚至画不出来，表现为白底。

排查思路很简单，在 Canvas 的onReady回调里打印一次组件宽高，你会发现在某些设备上这个回调会执行两次，第一次拿到的宽高是 0 或不完整。解决办法是加入就绪判断，等待宽高合法后再触发绘制。组件内部是否已做这个处理，取决于拿到手的版本，如果你的二次封装版本没有做，就要在接入侧自行增加一个延迟或重绘触发。实际代码里，我用一个@State isCanvasReady: boolean = false，在onReady里赋值，再在 Mode 判断后调用重绘方法，闪白问题基本消除。

5.2 中间按钮“点了没反应”的根本原因：命中区域与距离判断

另一个高频问题是中间按钮有时候点了没反应，尤其在按钮边缘区域。这通常不是事件监听失效，而是按钮外层容器的高度小于视觉呈现高度，点击区域和视觉区域没有完全重叠。比如按钮视觉直径 64vp，但外层 Stack 容器高度只有 48vp，边缘位置虽然在视觉上属于按钮，但已经不在命中区域内，自然点不到。

排查这个问题的通用思路是：给按钮外层容器加一个临时背景色，肉眼对比“颜色区域”和“视觉按钮区域”是否重合。我实际排查时，发现中间按钮下方的观感高度和实际可点击区域差了 10vp 左右，就是因为外层容器 padding 没有把凹形下探部分算进去。解决办法是在插槽容器上设置合适的expandSafeArea或增大命中区域尺寸。需要注意，扩大的命中区域不能大到遮挡周围 Tab，否则会出现“点击首页 Tab 却触发了中间按钮”的误触。

5.3 页面切换时状态错乱与重复回调

页面切换时出现高亮和内容不同步，是状态类方案最容易出问题的场景。我遇到过这么一种典型情况：从“我的”Tab 进入二级页面，然后通过侧滑手势返回，结果页面内容回到了上一个 Tab，但底部导航高亮还停留在“我的”。原因是侧滑返回并不会触发状态类的onChange回调，它走的是系统手势栈逻辑，页面内容由路由栈恢复，而底部导航状态还停留在离开时的值。

这个问题我最终的解法是在容器页的onPageShow里统一做一次状态校正：检查当前路由栈顶部是不是容器页，是的话就取tabState.selectedIndex，并把页面内容 index 强制同步过去。这个方法看起来粗暴，但它能覆盖绝大多数入口方式：点击 Tab、侧滑返回、路由返回、外部推送跳转，全都能在页面可见时收敛到同一条状态链路上。

还有一个重复回调的问题：如果aboutToAppear被多次执行，而每次执行都注册了一次onChange，那么一个 Tab 切换动作可能触发多次回调。这类问题常见于页面被系统回收后重建的场景。规避方式是在注册前先解绑旧监听，或者确保状态类实例唯一。我在实际代码中增加了一个简单的防重入判断，回调内如果发现触发时的selectedIndex与页面当前值相同，直接跳过后续逻辑。

5.4 真机测试的两个偏好设置：关闭动画调试与检查安全区

最后是两个与真机测试强相关的偏好设置。第一，Debug 模式下建议先把animate参数临时改为 false，这样能更清楚地看到每次状态切换后高亮是否正确、页面内容是否同步。开着动画调试时，切换的视觉过渡会掩盖一些状态错误，排查太费眼。第二，打开开发者选项里的“显示布局边界”，检查底部导航栏是否超出了安全区边界。很多设备默认底部有手势条区域，如果导航栏没有预留安全区 padding，凹形圆弧会被手势条遮住一部分，视觉上如同“缺了一角”。

6. 视觉调优与自定义扩展：让底部导航真正贴合业务

6.1 调优原则：先保证功能链路，再追求视觉效果

视觉调优阶段，我遵循的一条原则是：先保证状态链路顺畅，再优化视觉细节。因为凹形导航栏的视觉空间非常紧凑，每一个动态效果都可能影响状态反馈的清晰度。比如切换动画如果做得太花哨，用户会不确定自己是否点中了目标；如果凹形弧度太深，两侧 Tab 的空间会被压缩，文字和图标甚至挤到安全区外。调优前必须明确功能优先级，把“状态反馈清晰”放在第一位，再让视觉为业务增色。

调优时最常用的参数组合是animate、iconSize、arcRadius和中间按钮尺寸。四个参数之间存在联动：弧形半径越大，可用面积越宽，按钮可以做得更大；按钮越大，两侧 Tab 的间距就越局促，文字大小和图标大小都需要同步调整。我用过几次“大按钮 + 小文字”的方案，效果不错，但一旦 Tab 数量超过五个，视觉就会非常拥挤。所以建议 Tab 数量控制在 3 到 5 个，中间按钮视觉优先级最高，其余 Tab 保持简洁。

6.2 自定义状态的颜色映射与主题响应

主题响应是业务接入时很容易忽略的一块。很多应用支持深色模式，底部导航栏在深色模式下需要同步调整底色、图标颜色和文字颜色。rc_concave_tabbar的backgroundColor支持直接传入颜色值，但如果你的应用已经接入了系统主题资源，最好是绑定资源变量而不是硬编码颜色。

我实际使用中，把导航栏背景色绑定到了$r('app.color.tab_background')，在浅色模式下这个资源指向白色，深色模式下指向深灰色，状态类的高亮色也通过资源变量来驱动。这样切主题时，底部导航栏能自动响应，不需要额外写监听逻辑。如果你发现自己应用的深色模式出现了“导航栏还是白的”这种突兀视觉，优先检查是否绑定了资源变量，而不是去组件源码里找问题。

6.3 中间按钮的交互扩展：长按、双击、拖拽事件的取舍

中间按钮往往承载的是高频核心动作，比如发布、扫码，因此交互设计空间较大。组件默认只处理点击，但通过插槽自定义，你完全可以为中间按钮加长按、双击甚至拖拽手势。我在一个电商 Demo 里给中间按钮加了长按触发“扫一扫快捷设置”的功能，用的是 ArkUI 的Gesture组合。要注意的是，长按手势和点击手势同时存在时，要设置好手势识别优先级，否则长按触发时点击也会被误判。

关于拖拽，个人建议谨慎。底部导航栏的视觉稳定性对用户有很强的锚定效应，拖拽中间按钮会让用户产生“导航栏漂移”的不安全感，除非产品设计明确需要这种交互，否则不太推荐。

7. 接入前后的几个经验总结：给使用者的实用建议

组件接入和调优做完一轮后，回归到实际工程管理层面，有几个经验值得单独梳理。首先是版本锁定。开源组件在上游迭代过程中，API 兼容性和默认行为都可能变化，如果你的团队有多条产品线，建议在工程里锁定组件版本，不要每次构建都拉最新代码。我经历过的场景是，某个版本的组件默认动画行为发生了变化，导致旧页面上的切换效果跟之前不一致，排查半天才发现是上游升级的影响。

其次是二次封装。如果公司内有多个业务方都要用底部导航，最好在组件之上再做一层业务封装，把通用的状态类初始化、安全区处理、主题资源绑定都收敛进去，业务方只需要传 Tab 数据和中间按钮内容。这样既能统一体验，又能减少重复踩坑。我搭的这层封装大概一百多行代码，却省掉了业务侧大量分散的适配逻辑。

最后是状态管理的边界。rc_concave_tabbar的状态类负责的是导航状态，不是业务数据状态。不要试图把页面的复杂数据都塞进状态类里，否则后续维护会很吃力。正确的使用方式是：状态类只负责“当前在哪个 Tab、切到哪个 Tab、以及通知外界”，至于每个 Tab 页面内部的数据拉取、缓存与恢复，仍然属于各页面模块的职责。这个边界划清楚之后，整个导航组件的可维护性会高很多，后续再叠加复杂的页面栈、埋点链路也不会互相纠缠。

从我个人的实际体会来说，底部导航栏真正的价值不在于凹形视觉多惊艳，而在于它能成为整个应用导航逻辑的稳定锚点。用一个配置清晰、状态收敛的组件，比每次改需求都在页面代码里打补丁要靠谱得多。这套接入流程和排查思路，如果你能按步骤走一遍，大概率会比我自己第一次接入时顺畅不少。