简介：这是一套基于uni-app开发的微信小程序源码，专为智慧仓储管理场景设计，面向前端开发者与小程序学习者，解决多角色权限下底部tabbar动态渲染的实际问题。资源包含完整项目流程：支持管理员与普通员工双角色切换登录，涵盖账号注册、登录鉴权、公司选择、授权名单管理、项目与储物仓列表、盘点任务及柜子详情等20+核心功能页面，代码结构清晰，便于理解角色驱动的路由与tabbar控制逻辑。压缩包共668个文件，以116个Vue组件页、110个JS逻辑脚本、72个PNG图标资源、38个JSON配置及26个WXSS样式文件为主，辅以SCSS、WXS等增强能力文件，整体体积仅3.25MB，轻量易读。已有6605人学习下载，适合用于权限系统实践、uni-app跨端开发进阶及小程序tabbar动态适配方案研究。 如果你的项目只需要一套固定的底部导航，看到这里差不多就可以收藏了再关掉页面。但如果你接手的是一个后台管理类、多角色商城类或者任何需要"用户登录后看到的菜单不一样"的微信小程序，那"底部tabbar根据角色动态变化"这件事，你大概率逃不掉。用uni-app开发时，这个需求尤其容易让人抓狂：明明是同一个tabbar，管理员要看到"工作台、订单、我的"，普通用户要看到"首页、分类、购物车、我的"，游客可能只有"首页、我的"。一旦把角色这个变量加进来，原生tabbar配置的短板就会暴露得干干净净。
我最早做这个需求时，想得特别天真：pages.json里写死一套tabBar，登录之后用后端返回的角色去改一改不就行了？现实是改是可以改，但坑一个接一个。这篇文章我会把我在uni-app + 微信小程序环境下做动态tabbar的完整思路、两套主流实现方案、登录时序处理和踩过的坑全部写出来，希望能帮你少走点弯路。
1. 原生tabbar的"静态基因"，和动态需求天然冲突
1.1 藏在需求背后的真实场景
先说清楚这个需求是怎么来的。管理者后台类小程序最常见：员工登录是审批、统计、我的；普通用户登录是首页、订单、我的。还有一种常见场景是App在未登录时展示一套tab，登录后展示另一套tab，比如游客只能逛，会员能看购物车。
这类需求表面上是"底部导航不一样"，本质上是"不同角色对应不同的产品功能入口"。产品经理会跟你说得很轻松："就根据角色切换一下tabbar嘛"，但落到技术侧，你要面对的是三个问题：tab的数量不一样、tab的名称和图标不一样、tab对应的页面也不一样。
1.2 原生tabbar到底限制在哪
微信小程序的tabBar是一个在app.json里配置的静态导航，它有几个硬约束：
- tabBar的list配置必须在编译期写死，2到5个tab，顺序固定。
- 不能运行时增删tab项，没有类似hideTabBarItem这样的API。
- tabBar的pagePath必须存在于pages列表中，而且不能是分包页面。
- 原生tabBar由微信框架渲染，不参与页面的DOM结构，样式定制能力很弱。
uni-app里虽然对tabBar做了兼容，但本质没有突破微信的这些限制。也就是说，只要你在pages.json里用tabBar声明了底部导航，它就天然是"静态"的。
1.3 两条技术路线的取舍
既然原生tabbar不能真正动态，业内通常走的路线就两条：
- 路线A：保留原生tabbar，登录后通过uni.setTabBarItem修改文字和图标。
- 路线B：放弃原生渲染，用custom-tab-bar做一个完全由自己控制的tabbar组件。
这两条路线解决的是不同层级的诉求。路线A适合"角色之间tab数量一致，只是名称和图标不同"的场景，改动小、成本低。路线B则把tabbar的渲染、交互、数据源全部收归自己控制，适合"不同角色看到的tab数量完全不一样"的场景。
我在项目中做过一次比较，表格放在下面，你可以先做个判断：
| 对比项 | 原生tabbar + setTabBarItem | 自定义tabbar组件 |
|---|---|---|
| tab数量动态变化 | 不支持 | 支持 |
| 文字/图标动态变化 | 支持 | 支持 |
| 自定义样式 | 弱 | 强 |
| 实现成本 | 低 | 中高 |
| 多端兼容性 | 高 | 需要适配 |
| 页面栈管理 | switchTab天然支持 | 需注意跳转方式 |
下面我分别把两条路线的实现细节展开，直接照着做基本能通。
2. 方案一：基于uni.setTabBarItem的轻量改造
2.1 这个方案真的省事，但边界很明显
先说适用条件：角色之间的底部tab数量完全一致，只是文字、图标、高亮图标不一样。比如管理员和普通用户都有4个tab，只是第2个tab管理员显示"订单"，用户显示"分类"，那这个方案是性价比最高的。
这里有个很多文章不会提的坑：setTabBarItem只能改，不能增删。如果你在pages.json里配置了4个tab，那不管什么角色登录，底部都必须是4个tab，少了不行，多了也不行。有些项目为了"看起来动态"，会把某个tab的文字改空、图标改成透明，让用户视觉上看不到这个tab。我劝你别这么干——文字为空时tab栏会出现一块空白热区，点击后还会跳转到一个不该去的页面，体验非常糟。
2.2 接入步骤：登录成功后重写tab项
直接在页面代码里调uni.setTabBarItem就行，不需要额外安装依赖。通常我会在首页的onShow里做一次，或者在登录成功的回调里做一次：
// 登录成功后，根据角色重写tabbar function resetTabBarByRole(role) { if (role === 'admin') { uni.setTabBarItem({ index: 1, text: '订单', iconPath: '/static/tabbar/admin/order.png', selectedIconPath: '/static/tabbar/admin/order-active.png' }); uni.setTabBarItem({ index: 2, text: '统计', iconPath: '/static/tabbar/admin/stat.png', selectedIconPath: '/static/tabbar/admin/stat-active.png' }); } else { uni.setTabBarItem({ index: 1, text: '分类', iconPath: '/static/tabbar/user/category.png', selectedIconPath: '/static/tabbar/user/category-active.png' }); uni.setTabBarItem({ index: 2, text: '购物车', iconPath: '/static/tabbar/user/cart.png', selectedIconPath: '/static/tabbar/user/cart-active.png' }); } }注意index的值是0开始的。这里有个时序问题：setTabBarItem必须在tabbar渲染完成之后调用才稳定。如果你在登录页调用，登录成功后跳转到首页，首页又在onShow里调用，会出现tabbar先闪烁成默认配置、再变成角色配置的情况，观感很差。
解决思路是：把角色配置存到本地，然后在首页onLoad里同步设置。如果之前已经设置过，页面跳转时不会重置。同时page.json里的tabBar配置尽量就按"高权限角色"的样子写，这样就算初始化闪一下，也是闪成管理员的样子，而不是普通用户的样子。
2.3 这个方案没办法覆盖的场景
方案二主推的自定义tabbar，主要就是为了弥补方案一的两个硬伤：
- tab数量不能变。
- tab项完全绑定pages.json的pagePath，无法让某个角色看到"另一个页面"作为tab入口。
如果你确认项目只会在固定的4个tab里改文字图标，那方案一已经够了。但只要你发现"这个角色其实不需要购物车这个tab"，或者"管理员想有一个只有管理员才有的工作台页面"，方案一就彻底退场，必须上自定义tabbar。
3. 方案二：基于custom-tab-bar的自定义组件，让tabbar真正"活"起来
3.1 先理解微信自定义tabBar的运行机制
微信官方对自定义tabBar的支持是有一套完整机制的：在app.json（uni-app对应pages.json）的tabBar配置里加一个custom字段，值为true，然后在项目根目录创建custom-tab-bar目录，放一个自定义组件。编译后微信框架会代替原生tabbar渲染这个组件。
在uni-app里，目录位置是src/custom-tab-bar/index.vue。比如：
{ "tabBar": { "custom": true, "color": "#999999", "selectedColor": "#3B82F6", "backgroundColor": "#ffffff", "list": [ { "pagePath": "pages/home/index", "text": "首页" }, { "pagePath": "pages/order/index", "text": "订单" }, { "pagePath": "pages/mine/index", "text": "我的" } ] } }这里最关键的一点是：list仍然要写，而且要把所有角色可能会用到的tab页面都写进去。因为微信的switchTab依赖这个list来校验页面路径。你的custom-tab-bar组件只是"决定显示哪些tab"，但底层跳转还是靠switchTab，跳转的url必须在这个list里。这就好比你把菜单的展示层换成了自己人，但后厨的食材清单还是得提前报备。
3.2 组件核心实现：角色驱动tab列表
custom-tab-bar/index.vue内部逻辑很简单：读取Pinia/Storage里的角色，维护一张"角色 -> tab列表"的映射表，然后根据角色渲染。
我用vue3 + Pinia的方式写，如果你项目还在用vue2 + Vuex，逻辑是通用的。
<template> <view class="tab-bar" :style="{ paddingBottom: safeAreaHeight }"> <view v-for="(item, index) in visibleTabs" :key="item.pagePath" class="tab-bar__item" :class="{ 'tab-bar__item--active': selected === index }" @click="handleSwitchTab(item, index)" > <image class="tab-bar__icon" :src="selected === index ? item.selectedIconPath : item.iconPath" mode="aspectFit" /> <text class="tab-bar__text">{{ item.text }}</text> </view> </view> </template> <script setup> import { ref, computed, watch } from 'vue'; import { useUserStore } from '@/stores/user'; const props = defineProps({ selected: { type: Number, default: 0 } }); const userStore = useUserStore(); const tabConfig = { guest: [ { pagePath: '/pages/home/index', text: '首页', iconPath: '/static/tabbar/guest/home.png', selectedIconPath: '/static/tabbar/guest/home-active.png' }, { pagePath: '/pages/mine/index', text: '我的', iconPath: '/static/tabbar/guest/mine.png', selectedIconPath: '/static/tabbar/guest/mine-active.png' } ], user: [ { pagePath: '/pages/home/index', text: '首页', iconPath: '/static/tabbar/user/home.png', selectedIconPath: '/static/tabbar/user/home-active.png' }, { pagePath: '/pages/category/index', text: '分类', iconPath: '/static/tabbar/user/category.png', selectedIconPath: '/static/tabbar/user/category-active.png' }, { pagePath: '/pages/cart/index', text: '购物车', iconPath: '/static/tabbar/user/cart.png', selectedIconPath: '/static/tabbar/user/cart-active.png' }, { pagePath: '/pages/mine/index', text: '我的', iconPath: '/static/tabbar/user/mine.png', selectedIconPath: '/static/tabbar/user/mine-active.png' } ], admin: [ { pagePath: '/pages/workbench/index', text: '工作台', iconPath: '/static/tabbar/admin/workbench.png', selectedIconPath: '/static/tabbar/admin/workbench-active.png' }, { pagePath: '/pages/order/index', text: '订单', iconPath: '/static/tabbar/admin/order.png', selectedIconPath: '/static/tabbar/admin/order-active.png' }, { pagePath: '/pages/mine/index', text: '我的', iconPath: '/static/tabbar/admin/mine.png', selectedIconPath: '/static/tabbar/admin/mine-active.png' } ] }; const visibleTabs = computed(() => { return tabConfig[userStore.role] || tabConfig.guest; }); const safeAreaHeight = ref('0px'); watch( () => userStore.role, () => { // 角色变化后，如果当前选中项超出长度，回到第0项 if (props.selected >= visibleTabs.value.length) { // 这里可以让父页面来处理重定向 uni.reLaunch({ url: visibleTabs.value[0].pagePath }); } } ); function handleSwitchTab(item, index) { if (props.selected === index) return; uni.switchTab({ url: item.pagePath }); } // 获取安全区高度 function initSafeArea() { const sysInfo = uni.getSystemInfoSync(); if (sysInfo.safeAreaInsets && sysInfo.safeAreaInsets.bottom > 0) { safeAreaHeight.value = sysInfo.safeAreaInsets.bottom + 'px'; } } initSafeArea(); </script> <style scoped> .tab-bar { position: fixed; left: 0; right: 0; bottom: 0; display: flex; height: 50px; background: #ffffff; box-shadow: 0 -2px 10px rgba(0, 0, 0, 0.05); z-index: 999; padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); } .tab-bar__item { flex: 1; display: flex; flex-direction: column; align-items: center; justify-content: center; } .tab-bar__icon { width: 24px; height: 24px; } .tab-bar__text { font-size: 10px; color: #999999; margin-top: 2px; } .tab-bar__item--active .tab-bar__text { color: #3B82F6; } </style>看到这里你可能注意到一个问题：tabbar的图标是写死的本地图片路径。如果角色有几十个，图片文件会非常多，而且后端可能希望动态下发图标。这块我放到第7节再讲。
3.3 页面接入与选中态同步
把custom-tab-bar组件放到每个tab页面的底部，并传入当前页面对应的selected值：
<template> <view class="page-wrapper"> <!-- 页面内容 --> <Tabbar :selected="0" /> </view> </template> <script setup> import Tabbar from '@/custom-tab-bar/index.vue'; </script>selected的维护是自定义tabbar最容易出错的地方。微信原生的tabbar帮你维护了高亮态，但自定义tabbar不会。你必须保证三点：
- 每个tab页面传入的selected跟它在tab列表中的位置一致。
- 页面从后台切回来（onShow）时，selected不能被其他页面覆盖。
- 不同角色下同一个页面的selected值可能不同，比如"我的"在游客角色下是下标1，在用户角色下是下标3。
这就是为什么我建议用props传入selected，而不是在tabbar组件里自己搞一套全局current。你可以在每个页面的onShow里把当前页面的selected值写进store，然后组件从store读取。但注意，如果角色切换导致tab列表变了，当前页面可能已经不在新列表里了，这时候优先reLaunch到新角色第一个tab，不要停留在旧页面上。
3.4 安全区、占位、图标这些细节别图省事
自定义tabbar是fixed定位，不占文档流，页面底部内容会被遮挡。所以需要给每个tab页面设置padding-bottom，高度大概是50px加上安全区高度。你可以直接在App.vue里给page加公共样式：
page { padding-bottom: calc(50px + constant(safe-area-inset-bottom)); padding-bottom: calc(50px + env(safe-area-inset-bottom)); }但要注意，这只适用于所有tab页面。如果有非tab页面也要用这个组件（比如从列表进入的详情页不需要tabbar），就别全局加，建议用页面维度分别控制。
安全区用env(safe-area-inset-bottom)是微信小程序的标准做法，但不同基础库对constant和env的支持有差异，最好两个都写上，让旧版本也能兜底。还有一点，tabbar组件的css里不要用position: fixed之后再用top相关属性，容易在部分安卓机型上出现高度计算偏差。实测下来用flex布局放底部是最稳的。
图标路径是另一个坑。在custom-tab-bar组件里引用图片，建议用绝对路径（以/开头，指向static目录），不要用相对路径。微信自定义tabbar组件在编译后可能不在原目录层级，相对路径会失效导致图标白屏。
4. 角色状态管理与登录时序：动态tabbar翻车的重灾区
4.1 角色数据的来源、存储与同步
角色信息通常来自登录接口或用户信息接口。我的习惯是：登录成功后，后端一次性返回token、角色、用户基础信息，前端统一写进Pinia和Storage。后续小程序冷启动时，App.vue的onLaunch里先从Storage恢复登录态，再决定是否调用刷新用户信息接口。
Pinia的写法前面代码里已经出现过，这里补一个相对完整的：
// stores/user.js import { defineStore } from 'pinia'; export const useUserStore = defineStore('user', { state: () => ({ token: uni.getStorageSync('token') || '', role: uni.getStorageSync('role') || 'guest', userInfo: uni.getStorageSync('userInfo') || {} }), actions: { setLogin({ token, role, userInfo }) { this.token = token; this.role = role; this.userInfo = userInfo; uni.setStorageSync('token', token); uni.setStorageSync('role', role); uni.setStorageSync('userInfo', userInfo); }, logout() { this.token = ''; this.role = 'guest'; this.userInfo = {}; uni.removeStorageSync('token'); uni.removeStorageSync('role'); uni.removeStorageSync('userInfo'); } } });这里有个一般人不会注意的点：Storage和Store要保持同步。如果你只写Store不写Storage，冷启动后角色信息丢失，tabbar会先渲染成游客版，再异步变成正式版，视觉上闪变。如果你只写Storage不写Store，页面内的响应式更新就失效了，tabbar不会自动切换。两个都写是最稳的。
4.2 先渲染还是先拿角色：时序问题的本质
"进入小程序先闪现默认tabbar，登录后跳变"是动态tabbar最容易遇到的体验问题。要根治它，核心思路是：在tabbar组件拿到稳定的角色信息之前，不要渲染任何tab项，或者渲染一个占位空壳。
一个比较简单的处理方式是，在custom-tab-bar组件里加一个loading状态：
const loading = ref(true); onMounted(() => { // 等store初始化完成 nextTick(() => { loading.value = false; }); });模板里loading为true时只渲染一个空白的底部条，不显示具体tab。这样即使角色异步到达，用户也只会看到一瞬空白，而不会看到"先游客后管理员"这种明显的闪变。
另一个更彻底的做法：把登录态恢复做成同步阻塞。uni.getStorageSync是同步的，冷启动时角色信息其实已经拿到了，只是你在接口刷新用户信息之前不确定角色是否变化。这里建议根据业务容忍度决定：如果是电商类，角色基本不会变，直接用Storage里的角色渲染，再后台静默刷新；如果是后台类，角色可能被管理员调整，那就需要loading遮罩到接口返回后再进入主框架。
4.3 角色切换和退出登录的兜底处理
角色不是永远不变的。管理员把你的账号从user提升到admin，或者被降权，这时候如果小程序还开着，tabbar必须实时响应。好在Pinia的state是响应式的，custom-tab-bar里computed依赖role，role一变tab列表就变。
但有一个边界：角色变化后，当前所在页面可能不属于新角色的tab列表。比如你正停在工作台页，角色被降为普通用户，工作台页不在用户tab里，那tabbar列表里找不到当前页面对应的高亮项，还会出现"底部导航没有当前页入口"的尴尬。
处理方式是watch角色的变化，主动重定向到新角色第一个tab页面：
watch( () => userStore.role, () => { const currentPath = '/' + getCurrentPages().slice(-1)[0].route; const isInTabs = visibleTabs.value.some(item => item.pagePath === currentPath); if (!isInTabs) { uni.reLaunch({ url: visibleTabs.value[0].pagePath }); } } );退出登录同理，调用logout后，在用户信息页主动reLaunch到游客角色的默认tab页面。这里用reLaunch而不是switchTab，是为了清掉整个页面栈，避免退出登录后用户按返回键又回到上一个登录态的页面。
5. 从登录到tabbar：一条完整的落地链路
5.1 项目结构与全局配置
先看一下完整落地时项目里需要的东西：
src/ ├── custom-tab-bar/ │ └── index.vue # 自定义tabbar组件 ├── stores/ │ └── user.js # Pinia用户状态 ├── pages/ │ ├── login/index.vue # 登录页 │ ├── workbench/index.vue # 管理员工作台 │ ├── home/index.vue # 用户首页 │ ├── order/index.vue # 订单 │ ├── category/index.vue # 分类 │ ├── cart/index.vue # 购物车 │ └── mine/index.vue # 我的 ├── static/ │ └── tabbar/ # 角色tab图标，按角色分目录 ├── App.vue ├── main.js └── pages.jsonpages.json的tabBar.list需要包含所有角色的所有tab页面。上面这个例子里，把workbench、home、order、category、cart、mine都配进去，common字段按正常tabbar配置写就行，反正不会被原生渲染。
5.2 登录流程把角色写进store
登录页的逻辑一般是：uni.login拿code，传给后端，后端返回token和角色。
// pages/login/index.vue import { useUserStore } from '@/stores/user'; const userStore = useUserStore(); async function handleLogin() { const loginRes = await uni.login({ provider: 'weixin' }); const res = await request({ url: '/api/auth/login', method: 'POST', data: { code: loginRes.code } }); userStore.setLogin({ token: res.token, role: res.role, userInfo: res.userInfo }); // 跳转到该角色的默认tab页 const defaultPageMap = { guest: '/pages/home/index', user: '/pages/home/index', admin: '/pages/workbench/index' }; uni.reLaunch({ url: defaultPageMap[res.role] || '/pages/home/index' }); }注意这里用reLaunch而不是switchTab，是因为登录前可能停留在一个非tab页面（比如授权页），reLaunch可以清掉页面栈，避免返回时回到登录页。
5.3 路由拦截与页面鉴权
动态tabbar只解决了"入口"问题，没有解决"越权访问"问题。用户完全可以通过历史记录、扫码等方式直接打开一个不属于他角色的tab页面。所以必须在路由层做一层拦截。
在main.js里用uni.addInterceptor统一拦截跳转：
// main.js import { useUserStore } from '@/stores/user'; const roleTabMap = { guest: ['pages/home/index', 'pages/mine/index'], user: ['pages/home/index', 'pages/category/index', 'pages/cart/index', 'pages/mine/index'], admin: ['pages/workbench/index', 'pages/order/index', 'pages/mine/index'] }; function checkAccess(url) { const userStore = useUserStore(); const role = userStore.role; const allowedPages = roleTabMap[role] || []; const path = url.split('?')[0].replace(/^\//, ''); return allowedPages.indexOf(path) > -1; } uni.addInterceptor('switchTab', { invoke(args) { if (!checkAccess(args.url)) { uni.showToast({ title: '无权限访问', icon: 'none' }); return false; } return true; } }); uni.addInterceptor('navigateTo', { invoke(args) { if (!checkAccess(args.url)) { uni.showToast({ title: '无权限访问', icon: 'none' }); return false; } return true; } });这里有个细节：页面内的普通业务页面（比如详情页、商品列表页）不该被这个tab级权限拦截，所以roleTabMap的判定只针对tab页面。你可以用一个白名单数组区分，也可以约定只有tab页面才走校验。否则你会在调试的时候发现人人喊打的"跳转被拦截"。
5.4 各tab页面的接入样式
每个tab页面底部引入Tabbar组件，传入自己的selected值：
<template> <view class="mine-page"> <!-- 页面内容 --> <Tabbar :selected="3" /> </view> </template> <script setup> import Tabbar from '@/custom-tab-bar/index.vue'; </script>为了减少重复代码，你也可以把Tabbar改成全局组件，在main.js里use注册，页面里直接用。但我的习惯是显式引入，因为selected这个props语义清晰，后面调样式、测试都方便。
最后再说一下两种角色共用页面的情况。"我的"页面在多个角色下都存在，但页面内容完全不同。你可以在mine页面里根据userStore.role做条件渲染。这样"我的"页面的tabbar显示逻辑不重复，页面内部又不串数据。
6. 我踩过的坑，以及对应的排查办法
6.1 开发者工具里白屏，真机却正常
这个现象在社区里讨论过很多次，我也被它折磨过一下午：手机上预览一切正常，微信开发者工具里打开就是白屏，console还报一堆看不懂的错。后来定位到几个常见原因，按出现频率排：
- 开发者工具的基础库版本和真机不一致。工具会默认用最新基础库，但真机预览用的是你手机微信内置的基础库。解决办法是检查工具详情里的调试基础库版本，调到和真机一致。
- 缓存问题。custom-tab-bar组件改过之后，工具偶尔不会重新编译，强制清缓存再重新编译。
- 自定义tabbar组件里用了某些基础库不支持的新特性，比如vue3的script setup在某些老版本基础库下编译异常。如果遇到，把组件改成options API再试一次。
排查白屏有个固定动作：先在真机预览看是否复现，再看console是否有报错，再看network和storage。真机正常工具白屏，九成是工具缓存和基础库问题。
6.2 切换角色后旧tabbar残留
角色切换后，偶尔能看到旧tabbar还闪了一下，或者部分tab的文字图标还是旧的。这个问题的根源通常是custom-tab-bar组件的响应式更新没有覆盖到所有实例。
检查这几个位置：
- 确认角色写在Pinia/Vuex里，而不是只存在页面data里。
- 确认custom-tab-bar的template里没有把tabConfig写死在onLoad里，它应该是一个computed，跟随role变化。
- 确认onShow没有覆盖组件数据。
还有个细节：如果同一个tab页面在页面栈里存在多个实例（比如从tabA跳到tabB，再返回），每个实例都会渲染一次Tabbar组件。旧实例被onHide掉后不会自动销毁，如果它内部缓存了旧角色，就可能出现残留。解决思路是给Tabbar组件绑定页面的唯一key，或者在onShow里强制刷新当前角色。
6.3 点击tab后高亮错乱
自定义tabbar的selected不会自动维护。我见过最典型的错乱场景：用户在首页（selected=0）点进购物车（selected=2），此时购物车页面高亮正确；但返回首页后，首页底部高亮却停留在购物车位置。
原因很简单：页面返回时不会重新触发onLoad，只触发onShow，而你的selected如果只在onLoad里设置，就会保持旧值。正确做法是把selected的设置放在onShow里。
// 页面里 onShow(() => { // 这里把当前页面对应的selected传给Tabbar });如果你用的是uni-app的options API：
onShow() { this.currentTab = 2; }6.4 高度计算差异与底部安全区
自定义tabbar的底部高度，在不同机型上的差异比想象中大。iPhone X系列有底部小黑条，需要额外的高度；部分安卓机型没有安全区，但虚拟导航栏会在底部占一块；还有微信开发者工具模拟器和真机的表现也不完全一致。
最稳的做法是不要硬编码高度，而是用env(safe-area-inset-bottom)自动适配。我在组件里写了双保险：
.tab-bar { padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); }同时页面内容的padding-bottom也要跟着变，否则内容会被遮挡。如果你觉得每个页面单独设置太麻烦，可以在App.vue里定义一个全局CSS变量（如果项目基础库支持）或者用公共样式类，总之不要只改一处。
7. 再进一步：把tabbar配置做成接口下发
7.1 动态配置的数据结构
如果你的项目是多租户、多业务线，每个租户的tabbar都不同，那"角色写死在前端"也不够用了。这时候可以把tabbar配置做成接口下发，后端返回什么，前端就渲染什么。
接口返回的数据结构可以这样设计：
{ "code": 0, "data": { "role": "admin", "tabbar": [ { "pagePath": "/pages/workbench/index", "text": "工作台", "iconUrl": "https://cdn.example.com/icons/admin/workbench.png", "selectedIconUrl": "https://cdn.example.com/icons/admin/workbench-active.png" } ] } }前端拿到后，把它作为角色映射的动态补充。这个方案的优势是产品改动tab不用发版，但也带来两个新问题。
7.2 缓存与异常兜底
第一个问题是图标。微信tabbar不推荐使用网络图片，本地图片路径才稳定。接口下发的一般是URL，你需要先把图标下载到本地缓存，或者直接用image标签加载网络URL。如果直接用网络URL，注意配置downloadFile域名白名单，否则正式版会加载失败。
第二个问题是接口异常。后端没返回tabbar配置时，前端必须有一个兜底配置，否则底部导航直接消失。我做了一个merge逻辑：默认配置写死在前端，接口返回后merge进去。这样即使接口超时，用户依然有tabbar可用。
const mergedTabbar = computed(() => { const remoteTabs = userStore.remoteTabbar || []; if (remoteTabs.length > 0) { return remoteTabs; } return getDefaultTabbar(userStore.role); });这种"默认配置兜底 + 服务端动态覆盖"的模式，在B端后台类小程序里非常实用。灰度发布、租户定制、运营活动都变得灵活很多。不过也要小心一个问题：如果接口下发的pagePath不在pages.json的tabBar.list里，switchTab会跳转失败。所以每次后端调整tab配置，前端还是要同步维护pages.json的list底表，这块必须通过文档或脚本保证一致性。
我在实际项目里的做法是，加一个本地校验函数，tabbar组件每次渲染前检查pagePath是否在白名单里，不在就直接过滤掉并console.error提醒。这样就算后端配错了，前端也只是少一个tab，不至于整个组件崩溃。
最后再分享一个我自己的习惯：凡是牵扯到动态tabbar的需求，我都会在需求评审阶段多问产品一句："角色切换时tab列表会不会增删？"如果只是改文字和图标，方案一就够；如果会增删，方案二起步；如果不同租户的tab都不一样，那就直接按接口下发来设计。提前想清楚这层，后面能少改三版代码。
本文还有配套的精品资源，点击获取
