企业官网建设流程全解析

简介：面向移动端H5开发者的部门树展示资源包，主要解决企业组织架构与员工层级在手机端的高效呈现问题，适配内部管理系统、协作平台及各类需要层级选择的业务场景。资源共11个文件，包括HTML页面、JavaScript逻辑、CSS样式、JSON示例数据以及6张PNG交互图标（展开、折叠、编辑、加减号等），压缩包仅76KB，结构紧凑便于快速移植。代码基于jQuery实现，封装了AM-treeList树形列表组件，演示如何用递归遍历JSON数据构建DOM，并支持节点展开与折叠、图标切换、触摸点击等移动端交互；同时兼顾响应式布局与运行性能，整体轻量易读。开发者既可将其作为独立Demo直接运行，也能提取核心代码嵌入现有项目，节省从零搭建的时间。该资源已有4162人学习下载，适合需要在H5项目中快速集成部门树功能的初中级前端开发者。 先说结论：移动端做部门树，和PC端完全是两码事。PC上你随便用个zTree、Element Tree都行，但手机上屏就那么大，触屏交互又和鼠标完全不一样，如果直接把PC那套树组件搬过来，用户大概率会疯掉——缩小的滚动条、点不准的箭头、层层展开后层级混乱看不清楚，基本就是灾难现场。我最近刚好把一个PC端的“部门树”需求搬到了H5移动端，顺手解决了一批历史遗留问题，这篇就把完整的技术方案、性能优化思路和踩坑记录都捋一遍，给后来人做参考。

1. 需求本质：部门树不是一个“组件”，是一套交互方案

1.1 这个需求的真正难点在哪

部门树这个需求，最核心的矛盾在于：移动端屏幕空间极其有限，而组织架构往往是多层级、多节点的。比如一个中大型企业，部门可能是“总公司–事业部–中心–部门–小组”五级结构，单层节点数量可能上百，全部展开后可能是几千个节点。如果按PC端原始树那种“递归展开、全部渲染”的思路做，即使不考虑交互体验，光是渲染几千个DOM节点，中低端手机就直接卡死。

所以，要做好移动端部门树，本质上是三件事的组合：

• 信息架构的重设：把一个“大树”拆成“逐级下钻的页面流”，让用户每屏只面对一层数据，把纵深问题化解为横向导航。
• 交互模式的适配：触屏没有hover、没有右键、没有精确滚动条，点击区域要足够大、层级切换要足够顺手、返回路径要足够清晰。
• 渲染性能的保障：尽量避免一次性渲染全部节点，用懒加载、虚拟滚动等手段把DOM数量和主线程负担压下来。

1.2 移动端部门树的适用场景

这个方案不是只给“展示”用的，实际上它覆盖了几个典型入口：

• 组织架构查看：HR、管理层在手机上查看公司组织架构，按层级浏览。
• 流程发起选人：发起审批时选择接收部门或抄送人，按部门逐级找到目标。
• 人员调度/指派：把任务指派给某部门，或者按部门筛选人员名单。
• 消息定向推送：运营/行政按部门范围选择推送目标。

场景不同，细节会有差异。比如“选人”场景通常要支持搜索、多选、勾选记忆；“只看架构”场景则不需要复杂交互。所以动手写代码前，先想清楚你这个树到底是“看”还是“选”，这决定了整个页面流的复杂度。

提示：我这次做的是“按部门逐级下钻+面包屑回退+懒加载”的模式。如果你的场景需要“全局搜索部门”或“同一屏跨级展示”，可以在这套骨架基础上扩展，核心渲染和性能优化思路是通用的。

1.3 技术方案选型

• 前端框架：Vue 3 + Vant 4（移动端H5最主流的组合，组件库自带Cell、List、Search等，能省不少事）。
• 数据加载：首屏不再一次性返回全量树，改成“按父节点ID加载子节点”，也就是懒加载模式，每次最多渲染几十个节点。
• 状态管理：这场景不需要引入Pinia，用一个可组合的useDeptTree模块，内部维护层级栈和加载状态就够。引入全局状态反而增加维护成本。
• 后端接口：建议接口设计成/api/dept/children?parentId=xxx，返回当前层级的直接子部门和基本信息。

2. 数据层设计：树形结构不是硬编码堆出来的

2.1 扁平结构 + id/parentId 映射

很多后端同学习惯直接存树形JSON，数据量小的时候问题不大，但一旦层级深、节点多，前端做状态维护就非常难受。我的建议是：接口返回扁平列表，每条记录包含id、parentId、name、childCount等字段，前端自行构建树或按需取子节点。

比如这样一个扁平数组：

[ { "id": 1, "parentId": 0, "name": "总公司", "childCount": 4 }, { "id": 2, "parentId": 1, "name": "技术中心", "childCount": 3 }, { "id": 3, "parentId": 2, "name": "前端组", "childCount": 0 }, { "id": 4, "parentId": 2, "name": "后端组", "childCount": 2 } ]

前端要做的事情就很简单：每次请求时，按parentId过滤出直接子节点，渲染到当前层级的列表。

这种设计的最大好处是：前端可以不持有完整的树对象，只用当前层的数组就够了，内存占用小，渲染清晰。而且如果后续要加搜索，直接对扁平数组做关键词过滤，比递归搜索树结构要简单得多。

2.2 childCount 字段是懒加载的关键

为什么一定要有childCount？因为移动端列表项右侧需要一个箭头图标，提示用户“这个节点下面还有子级”。如果不返回这个字段，前端就不得不通过判断“已加载的子节点数组是否为空”来决定是否展示箭头，会造成两种情况很尴尬：

• 先请求了子节点，发现为空，再隐藏箭头，导致闪烁；
• 对未展开的节点，根本不知道该不该显示箭头。

有了childCount，一行代码解决问题：

const hasChildren = node.childCount > 0

2.3 接口设计建议

后端接口可以按这样设计（RESTful风格）：

GET /api/dept/children?parentId=0&page=1&pageSize=50

响应体：

{ "code": 0, "data": { "list": [ { "id": 1, "parentId": 0, "name": "总公司", "childCount": 4 }, { "id": 2, "parentId": 0, "name": "研究院", "childCount": 6 } ], "hasMore": false } }

parentId=0表示顶级部门，hasMore用来支持分页加载，如果部门数量很大（比如几千个二级部门），前端可以做触底加载，而不是一次全量渲染。

特别注意：如果接口是后端的同事写的，一定要沟通清楚childCount的准确性。我这次就吃过亏，某节点的childCount返回了3，但实际子部门只有2个，前端展示了箭头，用户点进去却是空白页面，很影响体验。

3. 交互设计：别让用户在一个“大树”里迷路

3.1 递进下钻：每屏只做一件事

移动端树交互我强烈推荐“递进下钻”模式。核心思路是：不要尝试在同一屏展开多级节点，而是点击某个部门后，把当前页替换成该部门的子部门列表页，同时记录层级路径，用面包屑让用户随时回退。

简单类比：这就像手机文件管理器，你点进一个文件夹，看到的是这个文件夹里面的内容，而不是所有文件夹都摊开在同一屏。如果所有层级都展开，信息密度太大，用户根本看不过来。

3.2 页面的信息结构

每个层级的页面，从上到下分三个区域：

• 顶部导航栏：显示当前部门名称，左侧有返回按钮。
• 面包屑区：显示完整路径，可点击任意层级跳转。
• 子部门/成员列表区：以Cell列表形式展示当前层级的直接子部门。

页面结构如下：

<template> <div class="dept-page"> <!-- 顶部导航栏 --> <van-nav-bar :title="currentNode.name" left-arrow @click-left="goBack" /> <!-- 面包屑区域 --> <div class="breadcrumb" v-if="breadcrumbList.length > 0"> <span v-for="(item, index) in breadcrumbList" :key="item.id" class="breadcrumb-item" @click="jumpTo(item.id, index)" > {{ item.name }} <i v-if="index < breadcrumbList.length - 1">/</i> </span> </div> <!-- 列表区域 --> <van-list v-model:loading="loading" :finished="finished" finished-text="没有更多了" @load="loadChildren" class="dept-list" > <van-cell v-for="dept in currentList" :key="dept.id" :title="dept.name" :is-link="dept.childCount > 0" @click="handleDeptClick(dept)" /> </van-list> </div> </template>

3.3 路径与状态管理

用reactive维护一个deptStack数组，它代表当前层级栈：

const deptStack = reactive([ { id: 0, name: "总公司" } ]) // 当前层级 = 栈顶元素 const currentNode = computed(() => deptStack[deptStack.length - 1]) // 下钻 function drillDown(dept) { deptStack.push({ id: dept.id, name: dept.name }) } // 回退 function goBack() { if (deptStack.length > 1) { deptStack.pop() } } // 面包屑跳转 function jumpTo(id, index) { deptStack.splice(index + 1) }

这套状态设计的好处是：层级路径天然就是面包屑数据，不用额外去维护一个路径字符串；返回逻辑也极简，就是弹出栈顶元素。

3.4 返回键与浏览器的兼容

移动端场景下，用户习惯用安卓系统的物理返回键，所以必须监听popstate事件，在层级>1时优先执行页面内回退，而不是直接把整个页面退出：

onMounted(() => { window.addEventListener("popstate", handlePopState) }) function handlePopState() { if (deptStack.length > 1) { goBack() // 阻止默认行为，需要配合 history.pushState 使用 } }

这里有个关键点：当用户首次下钻时，我们要手动history.pushState塞入一条记录，这样物理返回键触发popstate时，才能拦截住，执行页面内回退。

我踩过的坑：不加这层处理的话，用户在子部门层级按物理返回键，会直接把整个页面关闭退出，体验极差。这个问题在Android WebView和微信浏览器里特别突出。

4. 性能优化：让树在低端机上也能丝滑

4.1 懒加载：别把整棵树一次性塞给前端

部门树最常见、最致命的性能问题，就是后端一次性返回全量部门数据，前端递归构建树并渲染所有节点。做一个估算：一个1000节点的树，如果全部渲染成DOM，平板还好，手机上主线程轻则卡顿，重则白屏。

解决办法就是按层级懒加载，每次只请求当前父节点下的直接子节点。大多数场景下，单个层级的直接子节点数量也就是个位数到几十个，渲染压力完全可以接受。

4.2 虚拟滚动

如果你的第二级节点就有一两千个（比如大型连锁机构的总部下直接挂了几千家门店），那么普通列表肯定顶不住，光DOM渲染就要几百毫秒。这种情况需要引入虚拟滚动，也就是只渲染视口内可见的十几行。

Vant的List组件本身不具备虚拟滚动能力，可以搭配@vant/use的useRelation自己实现，或者直接用vue-virtual-scroller这个库。实测下来，几百上千条数据滚动都很流畅，没有明显丢帧。

但虚拟滚动有个代价：滚动条位置不可预测，无法直接“跳到某个部门”。所以如果部门数量大且用户有明确的查找目标，必须提供搜索功能，否则用户体验还是会差。

4.3 接口缓存与骨架屏

移动端网络环境不稳定，部门数据在短时间内不太可能频繁变化。所以我做了两层缓存：

• 内存缓存：同一个parentId的数据，在本次页面会话内只请求一次，再次进入不再重复拉取。
• 本地缓存：用sessionStorage（会话级，关页面即失效）存一份，配合version字段做失效控制。

这样用户在层级间切换时，体验接近原生App，几乎没有白屏等待。

同时，在首次加载时展示骨架屏，而不是转圈加载图标：

<van-skeleton v-if="firstLoading" title :row="8" />

4.4 大数据集的搜索优化

如果部门树规模大，搜索时不要用前端遍历整棵树，建议直接调后端搜索接口，关键词转发到服务端做模糊匹配。前端只需要输入防抖（300ms）和结果列表展示。

实测注意：如果接口查询慢，搜索体验会很折磨。建议后端对部门名称字段建索引，同时限制返回条数（比如最多返回50条），避免一次返回大量结果导致渲染卡死。

5. 实战踩坑记录：这些问题我一个个趟过来的

5.1 深链还原：页面刷新或分享后，层级状态丢失

用户停在“技术中心–前端组”这个层级，这时候刷新页面或者把这个链接发给同事，打开后直接回到了“总公司”根节点，用户还以为页面坏了。

解决方案：

• 把当前层级栈的id序列拼到URL上，例如：/dept?path=1,5,12
• 页面加载时解析path参数，依次请求每一层的子部门数据，还原层级栈。
• 如果中间的某个部门已被删除，要做容错处理，跳到最近的有效层级。

// 解析路径参数 const path = route.query.path ? route.query.path.split(",").map(Number) : [0] // 逐层获取，最后一层是目标层 for (let i = 0; i < path.length; i++) { const parentId = path[i] const list = await fetchChildren(parentId) const currentNode = list.find(item => item.id === path[i + 1]) || null // 更新状态... }

5.2 iOS Safari 输入框顶上去了，adjust-position 没用

热词里提到的“uni-app 苹果浏览器 iOS Safari H5 输入框会自动上顶”这个问题，在部门树搜索场景同样会遇到。原因是iOS Safari为了确保输入框可见，会自动滚动页面，但滚完不还原，就导致页面下方空白。

如果项目是纯H5而非uni-app，我的处理方案是：

• 输入框聚焦时不依赖系统自动滚动，而是手动监听focus事件，用scrollIntoView({ block: "center" })把输入框滚到视口中间。
• 失焦后，用window.scrollTo(0, 0)强制恢复顶部。
• 如果是iOS内嵌WebView，可以试一下给html, body设置height: 100%; overflow: hidden，配合内部滚动容器做滚动。这个方法能有效规避系统的自动滚动干扰。

5.3 微信浏览器返回条问题

热词里提到的“微信打开H5怎么强制去掉自带的那个返回条”，这个返回条其实是微信内置浏览器在导航时自动加上的一层工具栏。如果部门树页面层级切换时用了hash路由或history路由，就可能在页面栈里多出记录，导致微信工具栏出现返回箭头，用户点了之后直接退出整个H5页面。

最实用的解决方案是：页面层级切换尽量用“页面内状态切换”，而不是“路由跳转”。我的部门树下钻过程本质上只是splice deptStack，同时在需要支持物理返回键时pushState一条占位记录，这个占位记录不会触发微信的返回条。只有唯一的真实路由入口，微信才不会额外增加返回按钮。

5.4 免登录鉴权：飞书/钉钉H5的坑

企业中部门树通常要嵌入飞书或钉钉，这时会遇到“免登录授权”问题。常见做法是：

• 前端从URL或SDK拿到免登授权码（code）。
• 把code发给后端，后端拿着code去对应的开放平台接口换取用户身份。
• 后端返回自建系统的token给前端，后续接口都带这个token访问。

飞书和钉钉都有一套标准的jssdk初始化流程，分为四步：引入js-sdk、调用config接口注入权限、通过ready回调处理成功逻辑、通过error回调处理失败逻辑。特别注意：这两个平台的免登码有效期都是几分钟，拿到后必须立即用掉，不能存起来慢慢调。

我踩过的一个坑：部门树接口在免登逻辑没走完时就被调用，导致401。解决方案是在前端做一个全局请求拦截器，等token落地后再放行请求队列，而不是靠写死setTimeout去碰运气。

6. 常见问题速查表

7. 还能怎么扩展

这套部门树方案在人力、行政、财务等场景中很容易扩展出“部门和人员混合选”的需求。比如流程审批中既要选部门、又要选部门下的人，那么列表区域的下钻链路可以设计成“部门-子部门-人员”三级模式，每一级加载不同类型的数据，渲染层用type字段区分。再往上扩展，把部门和人员都抽象为“组织节点”，整个树就变成了通用的组织选择器，可以复用到很多业务场景中。

根据我个人经验，移动端树组件最忌讳的就是“想一次做到位、把所有功能都塞进去”。真正顺手的做法是先把“逐级下钻”这条路跑通，性能和体验都稳定了，再根据业务需要逐步加上搜索、多选、人员混选这些能力。毕竟移动端信息的消化能力有限，少即是多。

这次开发中还有一个小教训：部门树的层级栈和URL参数同步，一定要从第一行代码就开始设计。刚开始我图省事没做深链还原，测试阶段没暴露问题，上线后用户分享链接进来发现层级不对，再来补这个功能就会涉及路由和状态的联动改造，比一开始做要多花一倍的时间。所以建议所有做这类页面的同学，一开始就把“用户会刷新页面、会把链接发给别人”当作默认场景来设计。

本文还有配套的精品资源，点击获取