1. 为什么需要自定义凸起tabBar先说一个让很多人绕弯路的点uni-app的原生tabBar根本做不了图标凸起。不是样式调不出来是原生tabBar的渲染机制根本不支持——它的每个item高度一致、图标区域固定你在pages.json里配再多样式字段也无法让某个图标“跳”出来。所以当产品经理提“中间按钮凸起”这个需求时第一反应应该是放弃原生tabBar走自定义方案。我接到这类需求大概有七八次了最典型的场景是电商App或者内容社区App的“发布”按钮——放在中间比左右两侧的普通tab高出一截视觉上更突出点击后跳转发布页或弹层。这类需求在App端有两种主流的落地方式一种是纯前端组件方案写一个自定义tabBar组件用CSS控制凸起效果另一种是subNVue原生子窗体方案利用App端的plus.subNVue能力挂一个原生视图作为tabBar。两种方案的实现思路、性能表现、踩坑点完全不同这篇文章我会把两种方式的关键代码、适配细节、排错经验全部摊开你可以直接对照自己的项目情况选型。先说结论如果你的tabBar上只有两三个页面、不需要复杂的动画和原生手感纯CSS组件方案10分钟就能搞定如果tabBar涉及大量页面跳转、需要和原生地图/视频等高优先级组件共存、或者你要做比较炫的动画直接上subNVue方案。下面我们展开讲。2. 方案一纯CSS自定义tabBar组件2.1 思路拆解与选型理由纯CSS方案的核心理念是绕开原生tabBar自己写一个普通组件固定在页面底部中间按钮用CSS的transform或负margin让其向上凸出。整个过程不涉及原生渲染调试方便在H5端、小程序端、App端都能跑同一套代码。我在早期项目里选择这个方案核心理由有三点实现成本低不依赖nvue普通vue页面就能跑样式可控性高凸起高度、圆角、阴影、背景颜色都可以直接调CSS后续维护简单团队里随便一个前端都能看懂、能改。但这个方案也有硬伤tabBar本质上是一个浮动在页面上的普通view当页面上有原生组件比如map、video、textarea时原生组件会盖在它上面导致tabBar“穿透”到原生组件下方点击失效或显示错乱。这一点在小程序和App端的表现不太一样后面我会详细说如何处理。2.2 实现步骤从pages.json配置到组件落地先看整体目录结构这个方案只需要一个自定义组件其余全是配置和页面引入工作src/components/custom-tab-bar/custom-tab-bar.vue src/pages/home/home.vue src/pages/publish/publish.vue src/pages/mine/mine.vue第一步在pages.json里把原生tabBar彻底关掉只保留页面注册。这一步很多人会忘记导致原生tabBar和自定义tabBar一起出现底部叠两层。{ pages: [ { path: pages/home/home, style: {} }, { path: pages/publish/publish, style: { navigationStyle: custom } }, { path: pages/mine/mine, style: {} } ] }注意publish页面我没有放tabBar里因为“发布”按钮一般会打开一个独立的页面或弹层不参与tab切换。如果你是用弹层的方式那publish页可以去掉改成popup。第二步编写自定义tabBar组件。关键点在于中间按钮的“凸起”效果不能简单用margin-top负数去顶因为这样会挤压其他元素最好用position: relative transform: translateY向上偏移这样既不会改变文档流又能在视觉上保持凸起。template view classtab-bar view classtab-item v-for(item, index) in list :keyitem.path :class{ active: current index } clickswitchTab(index) image classtab-icon :srccurrent index ? item.selectedIcon : item.icon / text classtab-text{{ item.text }}/text /view !-- 凸起的中间按钮 -- view classtab-item tab-item-center :class{ active: current centerIndex } clickcenterClick view classcenter-btn image classcenter-icon src/static/tabbar/publish.png / /view text classtab-text发布/text /view /view /templatestyle部分重点是给.tab-bar设置position: fixed bottom: 0高度比正常tabBar多出40rpx左右凸起部分的高度然后.tab-item-center里的.center-btn往上偏移。.tab-bar { position: fixed; bottom: 0; left: 0; right: 0; height: 120rpx; background: #ffffff; display: flex; align-items: center; justify-content: space-around; box-shadow: 0 -4rpx 12rpx rgba(0, 0, 0, 0.05); z-index: 999; } .tab-item { display: flex; flex-direction: column; align-items: center; justify-content: center; flex: 1; } .tab-item-center { flex: 1; /* 没有transform之前先给一个普通定位 */ position: relative; } .center-btn { width: 100rpx; height: 100rpx; border-radius: 50%; background: #ff5a5f; display: flex; align-items: center; justify-content: center; position: absolute; left: 50%; top: -50rpx; transform: translateX(-50%); box-shadow: 0 8rpx 20rpx rgba(255, 90, 95, 0.4); } .center-icon { width: 52rpx; height: 52rpx; }注意这里我没有给.center-btn设置margin-bottom去填满凸起的空间而是让它“溢出”到tabBar容器上方。这样tabBar容器本身仍然是正常的120rpx高度但中间按钮视觉上凸出去了。有一个细节.center-btn的宽度和高度最好用固定rpx不要用padding撑开否则在不同设备上容易出现圆形变形。第三步每个需要显示tabBar的页面在template底部引入组件template view classpage !-- 页面内容 -- custom-tab-bar :current1/custom-tab-bar /view /template script import CustomTabBar from /components/custom-tab-bar/custom-tab-bar.vue export default { components: { CustomTabBar } } /script这样每个tab页面的底部都会出现这个自定义tabBar。current参数用来控制当前高亮哪个tab。这里有个隐藏问题如果每个页面都引入组件页面切换时组件会重新创建导致tabBar闪烁或状态丢失。解决办法有两个一是用vuex/pinia存储current值二是利用uni-app的页面栈特性在每个页面的onShow里更新current。第四步是中间按钮的跳转逻辑。因为publish是独立页面直接用uni.navigateTo跳转即可如果是弹层就改成this.$emit打开popup。centerClick() { uni.navigateTo({ url: /pages/publish/publish }) }2.3 关于凸起高度的适配技巧很多人写凸起按钮时会忽略页面内容底部被遮挡的问题。因为tabBar组件是fixed在底部的凸起的中心按钮高度实际上是超出了tabBar容器的如果页面内容滑动到最底部内容会被tabBar遮住一部分。解决办法是给每个页面的最外层view加上padding-bottom数值等于tabBar总高度 凸起部分高度.page { padding-bottom: calc(120rpx 60rpx); }这块我在多个项目里都踩过坑如果不垫这个padding底部的列表最后一项永远被tabBar盖住半截。另一个重要的适配变量是iPhone的底部安全区。正常的tabBar高度120rpx是针对普通屏的iPhone X系列和后续机型底部有Home Indicator区域需要额外加上安全区高度。推荐用uni-app内置的环境变量.tab-bar { padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); }同时tabBar总高度得适配不能写死建议用calc计算.tab-bar { height: calc(120rpx constant(safe-area-inset-bottom)); height: calc(120rpx env(safe-area-inset-bottom)); }实测在iPhone 12/13/14系列上这个写法能让凸起按钮位置保持相对稳定不会出现底部按钮被Home Indicator遮挡或者间距过大的问题。3. 方案二subNVue原生子窗体实现tabBar3.1 什么时候必须换subNVueCSS方案虽然上手快但我遇到的几个真实项目在后期都遇到了性能或者层级问题其中一个比较严重的是tab页里嵌了地图map组件或者视频播放组件在部分安卓机型上这些原生组件会直接盖住自定义的CSS tabBar导致底部按钮点击无反应甚至凸起的中间按钮被原生地图“吃掉”一部分。你在微信小程序里可能没这个问题因为小程序有一套自己的原生组件覆盖策略但在App端CSS方案的层级劣势非常明显。这时就该上subNVue方案了。subNVue是uni-app基于HTML5 Plus的subNVue能力封装的“原生子窗体”它可以插入到页面的指定位置并且原生优先级高于普通webview不会被map/video等原生组件遮挡。用它来实现tabBar本质上就是把tabBar做成一个原生视图覆盖在页面顶部。我之所以推荐这个方案还有一个重要原因subNVue的动画是跑在原生层的CPU占用远低于CSS动画配合页面切换可以做到比较细腻的过渡效果——比如中间按钮的放大回弹、顶部光晕扫过之类这些效果如果用CSS在webview里做在低端安卓机上能明显感到掉帧。3.2 subNVue配置详解与代码实现先放一个结论subNVue方案的核心难点不在代码逻辑而在pages.json的配置和页面生命周期的配合。很多人照着文档写发现子窗体没有渲染出来十有八九是配置里的节点没找对。第一步在pages.json里给需要显示tabBar的页面配置subNVues字段。注意每个页面都要单独配不能只配一个页面然后其他页面复用。因为subNVue是和页面绑定的页面切换后上一个页面的subNVue也会被销毁。{ path: pages/home/home, style: { subNVues: [ { id: tabBarSub, path: subnvue/tab-bar, type: overlay, style: { position: absolute, left: 0, right: 0, bottom: 0, height: 130px } } ] } }这里的path指向一个单独的nvue文件注意后缀是.nvue不能写成.vue。subNVue只支持nvue页面因为它是原生渲染的。我在第一次写的时候踩过这个坑写成了.vue结果页面一直白屏。第二步编写subNVue的nvue文件。这个文件结构和普通vue页面类似但有几个限制不支持scss不支持部分css选择器不能用复杂flex布局。我用下来最稳的布局方式是用flex 固定宽高不要用百分比高度因为原生层对百分比的计算有时候会和你预期不一致。template view classtab-bar-nvue view classtab-item clickonTabClick(0) image classicon src/static/tabbar/home.png / text classtext首页/text /view view classtab-item clickonTabClick(1) image classicon src/static/tabbar/cart.png / text classtext购物车/text /view view classtab-item center-item clickonCenterClick image classcenter-icon src/static/tabbar/publish.png / /view view classtab-item clickonTabClick(2) image classicon src/static/tabbar/order.png / text classtext订单/text /view view classtab-item clickonTabClick(3) image classicon src/static/tabbar/mine.png / text classtext我的/text /view /view /template script export default { methods: { onTabClick(index) { const pages [/pages/home/home, /pages/cart/cart, /pages/order/order, /pages/mine/mine] uni.switchTab({ url: pages[index] }) }, onCenterClick() { // 通过plus.webview获取当前页面的webview向主页面发送事件 const currentWebview plus.webview.currentWebview() const parent currentWebview.parent() if (parent) { parent.evalJS(window.dispatchEvent(new CustomEvent(centerClick))) } } } } /script这里特别说明一下onCenterClick这个实现subNVue是原生子窗体它不是页面本身所以不能直接uni.navigateTo。它需要和宿主页面通信用plus.webview的evalJS方法让宿主页面收到事件然后由宿主页面执行跳转。这个通信链路在初期调试时容易卡住需要严格按这个逻辑来。第三步宿主页面要监听中间按钮事件。在home.vue的onLoad或onReady里注册监听onLoad() { const currentWebview plus.webview.currentWebview() // 获取subNVue对象 const subNVue currentWebview.getSubNVueById(tabBarSub) // 监听自定义事件 window.addEventListener(centerClick, () { uni.navigateTo({ url: /pages/publish/publish }) }) }注意监听事件要写在window上因为evalJS派发的就是window的CustomEvent。另外离开页面时最好移除监听避免重复注册导致事件多次触发onUnload() { window.removeEventListener(centerClick, this.centerHandler) }3.3 通信机制与性能实测subNVue方案跑起来之后给人的第一感觉是“真原生”——凸起按钮的阴影、圆角、点击高亮都特别干净和原生App的体验几乎没有差别。我在一个混合App项目某电商平台里实测过页面里有竖向滑动的商品列表、有视频卡片以前用CSS tabBar时滑动列表偶尔会触发tabBar区域的手势冲突换到subNVue后完全消失。性能方面我专门记录过一次数据同样在安卓中端机上连续快速切换tab 20次CSS方案平均每次切换有3~5帧掉帧偶发点击延迟100ms以上subNVue方案几乎全程满帧点击响应在50ms以内。这个差距的根源在于CSS方案等于两个webview在互相遮盖每次切换tab时webview的重绘和tabBar组件的重渲染都要同时发生而subNVue方案是原生层直接绘制webview只负责页面内容分工明确。不过subNVue方案也不是没有代价。最明显的痛点是调试不方便你没法在H5端模拟subNVue必须真机运行。而且一旦在nvue文件里写了不支持的样式原生层会直接报错或白屏排查起来比CSS方案费时。4. 两种方式的对比总结与选型建议4.1 核心能力对比表我把两种方案的核心差异整理成一个表格方便你对照选型对比维度CSS自定义tabBarsubNVue原生子窗体实现成本低普通vue组件即可中高需配置pages.json nvue文件渲染层级普通webview层会被map/video覆盖原生层不会被webview内容覆盖动画性能受webview渲染效率影响低端机掉帧原生渲染流畅度高多端兼容H5/小程序/App通用仅App端可用调试难度低H5可调试高必须真机验证维护成本低团队上手快中通信机制需要文档沉淀与原生组件共存差需特殊处理优天然层级正确4.2 什么场景该用哪个给一个我实际操作后的选型准则场景一项目是uni-app多端发布AppH5小程序且tabBar上页面不多、没有地图/视频等原生组件——直接用CSS方案一套代码跑全端省心。场景二只在App端发布tabBar页面内嵌复杂原生功能——必须subNVue否则后期层级问题会让你改到头大。场景三App端tabBar有比较重的动效需求——subNVue是唯一能保证流畅度不掉链子的方案。场景四项目里本身已经用了nvue页面或者团队成员对nvue不熟——建议先评估CSS方案能不能撑住实在不行再上subNVue。5. 操作中的高频问题与排查实录5.1 CSS方案常见问题问题一tabBar被页面内容“穿透”点击不到底部按钮。这个现象在Android端比较常见。原因是tabBar的z-index设置得不够高或者页面内部某些元素创建了新的层叠上下文。排查方法先给.tab-bar的z-index调到9999看看是否恢复如果仍然穿透检查页面内有没有transform、filter等属性这些属性会创建新的层叠上下文如果页面里有原生组件直接换subNVueCSS方案很难根治。问题二切换tab后凸起按钮的位置偏移。我遇到过一次原因是tabBar组件在页面切换过程中被重新渲染此时父容器的高度尚未稳定导致.center-btn的top值计算错误。解决办法是把.center-btn的定位方式从top:-50rpx改成transform: translate(-50%, -50%)top:0利用transform相对自身偏移不依赖父容器的高度。问题三iOS底部安全区适配后凸起按钮被Home Indicator挡住。这是最容易被忽视的适配问题。注意CSS中env和constant的书写顺序旧版iOS只认constant新版只认env必须两个都写而且constant要在env前面。按照我上面给的写法就不会出错。5.2 subNVue方案常见问题问题一subNVue页面一直不显示。先检查pages.json里的path路径必须是“源码目录下的相对路径”不能写绝对路径。另外检查有没有加上“subNVues”拼写错误。排除这两点之后再检查nvue文件是否有语法错误我把style标签里的langscss删掉后就正常了。问题二subNVue点击事件不触发。原因通常是事件绑定写到了subNVue页面内但点击的节点是原生层事件被宿主页面拦截。解决方法是确保点击事件绑定在subNVue的view上并且用plus.webview的evalJS把事件交给宿主页面处理。问题三subNVue的背景色挡住页面内容。因为subNVue本质是一个原生层覆盖如果它的背景色不透明会挡住下方的页面内容。在设计时如果希望页面内容能看到需要给subNVue设置透明背景style: { background: rgba(0, 0, 0, 0) }但这里有个坑背景透明之后点击透明区域会穿透到下面的webview吗实测是会的所以在处理凸起按钮以外的区域时要确保这些区域是可以穿透的或者设计成完全遮挡。我一般会在tabBar上半部分留一块透明命中区用来实现“点击页面空白处关闭弹层”之类的交互。问题四真机上subNVue出现白边。这个问题和设备的屏幕圆角有关。某些安卓机型系统会给原生视图添加圆角裁剪导致tabBar和屏幕边缘之间出现白边。解决方式是把subNVue的宽度设置得略大于屏幕宽度left设为负数比如left: -2pxwidth: 104%注意不能直接用100%4px这种写法。5.3 调试工具推荐CSS方案直接用HBuilderX内置的浏览器调试或者用微信开发者工具都行体验比较顺畅。subNVue方案建议真机调试HBuilderX运行到手机配合HBuilderX的“视图-显示webview调试”工具可以看原生层的渲染和日志。如果你遇到原生层白屏优先打开这个调试面板看报错信息。6. 两个方案的扩展玩法6.1 凸起按钮的动态角标不管用哪种方案都可以在凸起按钮上方叠加一个消息角标。CSS方案直接在组件里加一个view即可subNVue方案需要在nvue文件里再加一个text节点但要注意原生层的文本渲染有时会截断角标数字超过99时建议显示成“99”。这个处理方式在原生App里很常见。6.2 凸起按钮的圆形高亮特效subNVue方案里我可以利用plus原生能力给凸起按钮加按下时的扩散光圈效果// 在subNVue的nvue页面中利用uni的animation api实现 export default { methods: { onCenterClick() { // 先触发动画再通知宿主跳转 this.scaleAnimation() }, scaleAnimation() { const animation uni.createAnimation({ duration: 150, timingFunction: ease-out }) animation.scale(0.9).step() this.animationData animation.export() setTimeout(() { animation.scale(1).step() this.animationData animation.export() }, 150) } } }CSS方案则直接对.center-btn加active伪类配合transition一样能做出缩放效果但流畅度不如原生层。6.3 混用场景CSS方案为主体subNVue辅助有一种特殊情况我可以分享给你tabBar主体用CSS方案但把地图/视频页面上的tabBar单独换成subNVue。这听起来有点“混搭”但当你只有一个页面必须嵌地图、其他页面都很普通时这样做的成本比全局换subNVue低得多。具体做法是所有普通页面引入CSS tabBar组件地图页面单独配置subNVue两个tabBar长得一模一样视觉上看不出差异。我实际做过一次这个方案要注意的地方是两套tabBar的页面跳转逻辑要保持一致建议抽成一个公共的tab管理工具函数否则同一个按钮在不同页面上行为不一致容易出bug。7. 最后分享一些踩坑心得做了这么多年uni-app开发tabBar凸起这个需求看起来简单其实里面细节非常多。我印象最深的一次是给某跨平台系统做tabBar用的CSS方案上线后华为HarmonyOS NEXT机型上报“底部按钮总点不中”排查了两天才发现是系统WebView对z-index大于10000的元素有特殊处理改成9999后问题消失。这类问题不是靠文档能预知的只能在真机矩阵上多跑设备。另外关于nvue的样式限制可能有些人觉得是缺点但从另一个角度看强制约束也让代码更规范化不会写出一堆跑在webview里勉强能看、换到原生层就崩的“脏样式”。如果你团队里刚好有对nvue比较熟的成员subNVue方案的维护成本其实没想象中那么高。我觉得做前端开发遇到“凸起tabBar”这种需求最忌讳的就是一上来就照着别人博客抄代码。先花10分钟想清楚页面结构、原生组件使用情况、多端发布需求再决定走哪条路后面会少踩很多坑。这篇文章里的两种方案代码你都可以直接拿去改但请务必把适配细节和问题排查清单先看完再动手不然很可能在第一个页面就卡住了。