企业官网建设流程全解析

1. 整体认识：若依前后端分离版中的权限体系

若依前后端分离版系列教程写到第4篇，前几篇把环境跑通之后，大家最纠结的通常是系统管理里的用户、角色、部门、岗位这四个模块。打开“系统管理”菜单，左边一长串功能，按钮也都认识，但就是搞不清它们之间到底是什么关系，配置先后的顺序是什么，更不知道部门下的“本部门及以下”数据权限是怎么算出来的。这篇文章就专门把四者的定位和关联说清楚。

很多从0开始接触若依的人，第一反应是先建用户，因为登录就得有账号。这个直觉没错，但实际配置时你会发现，新建用户页面里部门、岗位、角色全是下拉框，而且都标着必填。也就是说，如果不先把部门、岗位、角色建好，用户根本建不出来。所以这个系列我把这四个模块放到一起讲，因为它们本来就是一套完整的权限基础数据。

这篇文章适合两类人：一类是已经把若依前后端分离版跑起来、开始配置后台管理数据的新手；另一类是准备基于若依做二次开发的开发者，需要理清权限模型的边界。读完你至少能回答这几个问题：部门树和岗位有什么区别？角色的数据权限范围怎么选？为什么给用户配了角色还是看不到菜单？下面我们逐个拆。

1.1 四个模块分别解决什么问题

借用一个实际场景：公司新来一个员工，叫小王，在研发部做后端开发，他能登录后台，能查看和编辑他自己创建的报销单，但看不到财务部的数据。落到若依的数据模型里，“研发部”就是部门信息，“后端开发”是岗位，“能查看和编辑报销单”是角色权限，“小王”就是系统里的用户。

部门描述的是组织架构树，解决“你在哪个分支”的问题。岗位描述的是工作职位，解决“你在这个部门里是什么角色标签”的问题。角色描述的是操作权限集合，解决“你能点哪些菜单、调哪些接口”的问题。用户则是所有信息的汇合点，登录后台后，系统需要同时知道他属于哪个部门、有哪些岗位、配了哪些角色，才能决定他能看到什么内容。

如果把权限体系比作一张工牌：部门决定你属于哪栋楼，岗位决定你胸前的职级标签，角色决定你能开哪几扇门，用户就是持卡人本人。这样类比，后面看代码和配置表都会清爽很多。

1.2 模块之间的关系与数据表结构

上面四个模块不是孤立存在的，若依用一张主表和几张关联表把它们串起来。用户在核心表sys_user里通过dept_id挂到一个部门，通过sys_user_role关联多个角色，通过sys_user_post关联多个岗位。角色通过sys_role_menu关联菜单，通过sys_role_dept关联部门（用于自定义数据权限）。部门通过parent_id和ancestors形成树结构。

为什么用户要挂靠一个部门，而且是一个部门？因为若依的数据权限里，本部门数据、本部门及以下数据都是通过当前用户的dept_id去判断的。如果用户挂多个部门，数据范围会变得非常难处理。现实中大多数后台管理系统也遵循“一个员工只有一个直属部门”的规则，虽然一个人可能兼职多个项目组，但行政归属是唯一的。

为什么角色和岗位都是多对多？因为一个用户确实可能身兼数职，比如既是开发又是项目负责人；也完全可以同时拥有多个角色。多对多关系在数据表里就是拆成两张关联表，避免主表字段无限扩张。

1.3 官方默认账号与基础数据

若依前后端分离版默认有一个超级管理员admin，默认密码文档里通常标注为admin123，但不同版本可能要求首次登录修改密码。这个admin用户属于顶级部门，拥有名为“超级管理员”的角色，数据权限范围是“全部数据权限”。所有其他用户、部门、角色的初始化，都应该先围绕admin把基础数据摸一遍。

我建议新手拿到系统后，不要急着删数据，先用admin进入用户管理、角色管理、部门管理、岗位管理四个页面，各新增一条测试数据，再逐步熟悉。这样能直观看到各模块的前后端交互，后续遇到配置问题也更容易定位。

2. 部门管理：组织架构的基石

2.1 部门树结构的设计思路

部门管理界面通常是一个左侧树 + 右侧列表的组合。左侧树以dept_id作为节点ID，顶层节点的parent_id为0，子节点通过父部门的parent_id关联。ancestors字段存储了从根节点到当前节点的完整链路，例如顶级部门“若依科技”的ancestors是0，子部门“研发部”的ancestors是“0,100”，孙部门“前端组”的ancestors是“0,100,101”。

这个ancestors字段是数据权限判断的关键。后面角色数据范围选了“本部门及以下”，系统就是通过当前用户的dept_id去查所有ancestors里包含这个部门ID的子部门，把这些子部门的数据全部算进来。理解了这点，你就能明白为什么不要随意修改部门父级，改一次ancestors就要重新维护一批数据。

部门字段不多，但order_num（显示排序）容易被忽略。树形列表默认按order_num排序，值越小越靠前。如果建了很多部门后想重新排序，直接改数字就行，不用调整创建顺序。

2.2 新增部门的实操步骤

以创建一个“研发部-前端组”为例，进入部门管理页面后点击“新增”，表单里需要填写：

• 父部门：通过弹窗选择“研发部”，如果是一级部门就选顶级部门或“主部门”。
• 部门名称：建议保持唯一，避免同名部门在树里难区分。
• 显示排序：填1、2、3这种正整数，不建议多个同级部门填相同值，否则展示顺序不固定。
• 负责人、联系电话、邮箱：不是必填，但建议填真实信息，后续列表筛选和导出会用到。

点击确定后，前端会调用POST /system/dept接口，后端先校验部门名称是否重复（同级下），然后拼接ancestors并插入记录。这里要注意，新建部门时如果父部门是“研发部”，系统不会自动检查父部门状态，但如果父部门被停用，子部门虽然能创建，前端树展开时会比较奇怪，所以建议父部门保持启用状态。

保存完回到列表，展开“研发部”，就能看到“前端组”挂在下面。如果看不到，多半是浏览器缓存，刷新页面即可。刷新后仍然看不到的，检查是不是选错父部门或者被状态过滤条件挡住了。

2.3 部门管理的坑与经验

我踩过最典型的坑是：删除一个部门时，系统提示“该部门存在下级部门，不允许删除”，但明明列表里已经看不到子部门了。这种情况下，子部门很可能被软删除了，del_flag变成2，但数据还在表里，所以校验依然会拦住。解决办法有两种，一种是直接操作数据库把子部门del_flag改回0，先恢复再改挂到其他父部门；另一种是用系统自带的“删除”按钮，但需要确认子部门是否真的没了。稳妥起见，我一般先查数据库sys_dept，用父部门ID过滤所有记录，逐个处理干净再删。

还有一个经验是：顶级部门不要随便改父级。若依的顶级部门通常只有一条，根节点的parent_id=0，它的树下挂着所有部门。如果误把顶级部门的父级改成其他节点，整棵树会嵌套异常，菜单加载可能直接报错。修正方法也很麻烦，建议调整前先用SELECT * FROM sys_dept ORDER BY parent_id导出当前结构备份。

3. 岗位管理：职位与职责分离

3.1 岗位到底管什么

岗位管理页面的功能看起来比部门管理简单，只有岗位编码、岗位名称、岗位排序、状态、备注这几个字段。很多初学者会问：岗位和角色有什么区别？岗位能不能控制权限？答案是：在若依的前后端分离版里，岗位不直接参与菜单权限和数据权限的控制，它更像一个人员分类标签。

例如一个用户同时是“后端开发”和“项目经理”，岗位表里会同时出现两条记录，用户通过多选岗位关联。岗位编码是全系统唯一的，比如dev、pm、hr，岗位名称是展示给用户看的，如“开发工程师”“项目经理”。岗位排序和状态跟部门类似，停用的岗位在用户管理里不会被推荐选择，但不会影响已经关联该岗位的用户登录。

那为什么还要岗位表？因为很多业务场景需要按职位去统计、筛选或审计。比如导出一份“项目经理名单”，如果岗位信息存在用户备注里，筛选会很难受。把岗位做成独立基础表，既简洁又方便扩展。后续如果你们要做考勤、绩效系统，岗位字段可以直接作为维度复用。

3.2 创建岗位的实操要点

岗位管理里点“新增”，主要填四个内容：

• 岗位编码：建议用英文简写或数字，比如FE_DEV、10。编码必须在表里唯一，因为若依查询时会直接用post_code做匹配，重复会导致多选岗位时数据错乱。修改编码要谨慎，已经被引用的编码不建议改。
• 岗位名称：例如“前端开发”，展示给用户看，可以跟部门名重复，但不建议跟岗位编码一样。
• 显示排序：输入正整数，同部门场景下按此排序。
• 状态：正常/停用，默认正常。

保存后，岗位列表就多了一条。此时你可以在用户管理里分配给用户了。岗位本身没有层级关系，不需要像部门一样做树。如果你需要“技术部经理”和“部门经理”这种上下级关系，岗位表解决不了，要放到部门或者角色里去设计。

3.3 岗位、部门、角色三者对照表

这个表建议收藏。后续凡是有人问你“岗位和角色是不是一回事”，直接甩这张表给他。从实现上说，岗位就是一张最基础的人事字典表，角色才是权限模型的正主。

4. 角色管理：权限分配的核心

4.1 角色字段与权限字符

角色管理是四个模块里最复杂的，因为它的字段直接决定菜单权限和数据权限。进入“系统管理-角色管理”，列表显示角色名称、权限字符、角色排序、状态，操作列里有“菜单权限”“数据权限”“分配用户”等按钮。

角色名称是给人看的，比如“运营主管”。权限字符是代码层面用的标识，比如operator，它在后端接口校验里长这样：@PreAuthorize("@ss.hasRole('operator')")。这个值一旦定下来，线上环境不要轻易改，否则需要同时改代码。建议创建角色时就按项目规范命名，例如业务模块前缀加_role。

角色状态和排序跟其他模块类似。停用的角色不会立即让已关联用户失效，但用户重新登录时不会再加载该角色的菜单权限。所以如果你改了角色状态，记得让用户重新登录一次。

4.2 菜单权限树：勾错权限的后果

新增或编辑角色时，最核心的是“菜单权限”树。树上的节点有三种类型：目录、菜单、按钮。目录只是一层分组，按钮是具体的操作权限，比如“用户新增”“用户删除”。

这里有一个常见新手误区：只勾了按钮权限，没勾所属菜单，导致用户有“新增用户”按钮标识，却看不到用户管理页面。反过来，如果只勾了菜单，没勾按钮，用户能看到页面，但页面上按钮都不显示或点击后提示没有权限。所以勾选时必须把目录、菜单、按钮三层一起选中，或者至少选中菜单和它依赖的目录。

菜单权限提交后会写入sys_role_menu，一个角色对应多条菜单ID。若依后端在查询用户信息时会根据角色去查菜单集合，再返回给前端动态生成路由。前端这边，路由表是后端返回的，不是写死的，所以改了角色菜单后，用户必须退出重登，新的路由才会生效。

4.3 五种数据权限范围详解

数据权限是若依比较有特色的功能，它控制的是“接口查询出来的数据范围”。角色管理里“数据范围”下拉框有五个选项，我按实际含义逐个讲。

• 全部数据权限：角色可以查询所有部门的数据，通常只给超级管理员或负责人使用。
• 自定义数据权限：选择某些部门作为授权范围，可以多选。选择结果写入sys_role_dept关联表。如果以后部门调整，要回来重新维护这个角色的部门列表。
• 本部门数据权限：只能查询当前用户所在部门的数据。这里的“当前用户”是实际登录人，不是角色创建人，因为每次请求都会从登录状态里取dept_id。
• 本部门及以下数据权限：查询当前用户所在部门，以及当前部门所有子部门的数据。子部门的查找就是通过sys_dept.ancestors，性能不错，但如果部门树层级特别深，查询范围会大一些。
• 仅本人数据权限：只能看到create_by或user_id等于当前登录人的数据，适合个人工作台、报销、工单这类场景。

需要明确的是，这些数据权限不是所有接口都自动生效。若依是在Service层方法上加@DataScope注解，AOP拦截后动态拼接SQL条件。如果你自己写的接口没加注解，那数据权限不会管你，即使是“本部门数据权限”，也照样查全表。这是新手排查“数据权限没生效”时最先要确认的一点。

4.4 创建一个角色的完整步骤

以“运营主管”角色为例，完整操作如下：

1. 进入角色管理，点击新增。
2. 角色名称填“运营主管”，权限字符填operator，排序填4，状态选正常。
3. 数据范围选“本部门及以下数据权限”。如果选“自定义数据权限”，还要点旁边的“选择部门”弹窗，勾选运营部和运营部分支部门。
4. 展开菜单权限树，勾选跟运营工作相关的目录、菜单和按钮。比如“系统工具-表单构建”可以不勾，避免运营人员操作开发工具。
5. 保存角色。
6. 回到角色列表，点击“数据权限”，确认部门授权范围（如果是自定义）。
7. 点击“分配用户”，把需要这个角色的用户加进去。

这个过程每一步都有实际作用。如果只创建了角色不分配用户，那这个角色就是空壳；如果分配了用户但菜单权限漏勾，用户登录后菜单会缺一块。我建议创建完角色后用另一个浏览器开一个无痕窗口，用测试账号登录验证，不要用admin验证，因为管理员有全部权限，看不出差异。

5. 用户管理：把人和权限串起来

5.1 新增用户表单字段逐项说明

用户管理是日常操作最多的模块。新增用户时，字段比角色还多：登录账号、用户昵称、用户类型、密码、确认密码、手机号、邮箱、用户性别、头像、部门、岗位、角色、状态、备注。

登录账号是登录系统的唯一标识，不能重复。用户昵称只是展示用，可以跟姓名一致，也可以跟账号不同。用户类型在前后端分离版里分为系统用户和注册用户，后台管理的都选系统用户。密码一般有默认规则，比如长度和复杂度要求，若依默认密码是admin123或由系统参数控制，生产环境务必改成强密码并让用户第一次登录后修改。

手机号和邮箱不是必填，但如果系统开了短信或邮件找回密码，这两个字段就必须维护。部门是单选，这个部门决定数据权限里“本部门数据”的具体归属。岗位是多选，角色也是多选。如果还没建好岗位和角色，这里会选不出来，这也是为什么我反复强调要先建基础资料。

5.2 分配角色时注意权限叠加

一个用户可以分配多个角色。多个角色的菜单权限会做并集处理，也就是角色A有“用户管理”菜单，角色B有“角色管理”菜单，用户登录后两个菜单都能看到。数据权限范围则会取最大的范围，比如一个角色是“全部数据权限”，另一个是“本部门数据权限”，那该用户实际就是全部数据权限。

这两种叠加逻辑容易让初学的人困惑，尤其是数据权限：多个角色的数据范围不是交集，而是并集。如果不想让某个用户看到太多数据，就不要同时给他一个“全部数据权限”的角色。生产环境里我习惯把权限大的角色和权限小的角色分开，分配用户时互相隔离，避免误给。

用户分配岗位同理，岗位不影响权限，但影响列表里展示的“岗位”列。如果一个用户多岗位，界面上通常用逗号拼接显示。后端查询用户列表时，会把岗位名称关联出来。

5.3 重置密码与账号状态控制

用户忘记密码时，管理员直接在用户管理里点击“重置密码”，输入新密码即可。重置密码不需要知道原密码，这个操作会直接覆盖sys_user.password字段。注意重置后，该用户本地保存的登录状态不会立即失效，如果怀疑账号被盗，建议先“停用”再重置，让token失效。

用户管理里的状态切换很重要。停用一个用户，他立刻无法再获取新的访问令牌，但已经登录的会话可能还有短暂有效期，所以紧急情况下要同时调用“踢人下线”功能（如果有）或重启服务。这里我踩过坑：停用用户后，他还在当前页面操作了十几秒才被拦下来，后来我调整了token有效期配置，把过期时间调短，同时重要操作增加二次认证。

删除用户是物理删除还是逻辑删除，取决于你操作的方式。若依后台点击删除用户，会从sys_user表删除，同时清除关联角色、岗位记录，这个操作不可恢复。所以生产环境建议用“停用”代替删除，保留历史数据。

5.4 用户导入导出的使用建议

若依支持通过Excel批量导入用户和导出用户。导出很简单，列表筛选后点“导出”就会下载一个Excel。导入需要注意模板格式，用系统下载的模板填写，否则会校验失败。导入时涉及的部门、岗位、角色都会按名称匹配，所以导入之前要确保基础数据已经在系统里存在。

我通常的导入习惯是：第一次先导两三条测试数据，确认表格格式没问题，再批量导入全量数据。因为若依的导入会逐行校验手机号、邮箱格式，如果有一行错误，整批导入可能失败或部分失败，具体看版本实现。批量导入前最好先导出当前用户表存档，方便出错时回滚。

6. 核心场景实操：新入职员工的权限初始化

6.1 场景描述与配置顺序

假设公司新入职一名员工“张伟”，加入“研发部-前端组”，职位是“初级前端开发工程师”，他需要登录后台使用“项目管理”模块，并且只能看到他自己所在前端组及以下的数据。

按照数据依赖顺序，配置步骤应该是：先确认部门存在，再建岗位，再建角色，最后建用户。如果你的公司已经有很多部门和岗位，前两步可以省略，但角色必须认真建，因为角色数据范围要精确到“本部门及以下”。

顺序为什么重要？因为用户表单里的部门、岗位、角色都是选择项，如果前置数据不存在，用户根本建不出来。反过来，如果先建用户再建角色，这个用户需要再分配一次角色，多一步操作，容易漏。

6.2 实操步骤记录

第一步，确认部门“研发部-前端组”的父级是“研发部”，状态正常。如果部门没有，按照第2章流程创建。

第二步，检查岗位是否存在“前端开发工程师”。如果不存在，岗位编码填FE_DEV，岗位名称填“前端开发工程师”，排序填1，状态正常。

第三步，创建角色，角色名称“前端开发”，权限字符fe_dev，数据范围选“本部门及以下数据权限”。菜单权限勾选“项目管理”目录下的相关菜单和按钮，注意把“项目管理”这个目录本身也勾上。

第四步，新增用户。登录账号填zhangwei，用户昵称填“张伟”，密码按系统规则设置，部门选“前端组”，岗位选“前端开发工程师”，角色选“前端开发”。状态选正常，备注填“新员工”。

第五步，用zhangwei登录，验证是否能看到“项目管理”菜单，是否能正常操作自己负责的功能，再用另一个部门的账号测试数据是否被隔离。

6.3 验证数据权限的细节

要验证“本部门及以下”是否生效，不能只看菜单，要看查询结果。比如“项目管理”模块有一个项目列表接口，如果张伟的前端组下面还有几个小组，他应该能看到前端组和所有子小组的项目数据，看不到后端组的数据。

如果发现数据没隔离，先检查这个项目列表接口对应的Service方法是否加了@DataScope注解。若依很多示例代码都加了，但你二次开发的新接口不一定加。如果没有注解，即使角色数据范围选得再精准，SQL最后也不会拼部门过滤条件。这是很多人的知识盲区，我当年第一次排查这个坑花了半天。

7. 常见问题与排查技巧

7.1 用户看不到已分配的菜单

这个问题出现频率最高。按顺序排查：先确认该用户是否停用；再确认角色状态是否正常；然后确认角色菜单权限里是否包含对应目录、菜单、按钮；最后确认用户是否重新登录过。

如果以上都没问题，检查用户管理页面选择的角色是否在提交时真正写入了用户角色关联表。有时候前端表单提交失败但页面提示成功，实际后端没有完整写入。打开浏览器F12看网络请求，看PUT /system/user返回的状态码和结果，基本能定位。

还有一个隐藏原因：若依前端路由是根据登录用户返回的菜单ID动态构建的，如果用户登录时用的不是最新角色配置，需要在本地存储中清理旧的动态路由。重新登录是最有效的办法。

7.2 数据权限没生效的常见原因

我整理了一个排查顺序：第一步，确认接口是否加@DataScope注解；第二步，确认角色数据范围不是“全部数据权限”；第三步，确认用户当前登录的账号挂载了正确部门，sys_user.dept_id不为0；第四步，确认“本部门及以下”涉及的部门树ancestors有数据且正确。

如果用的是“自定义数据权限”，还要确认sys_role_dept关联表里有对应的部门ID。很多人在角色管理里选了自定义但没点“选择部门”，或者选择后没保存，导致关联表为空，结果什么都查不到。这类问题直接在数据库里查角色和部门关联表，一眼就能看出来。

7.3 删除部门或角色时提示存在依赖

删除部门时提示有子部门或用户，删除角色时提示有用户关联。解决思路是先解除引用关系，再执行删除。用户需要先调整部门到其他部门，角色需要先从用户管理中移除该角色，或者批量把关联用户改成其他角色。

这里提醒一句：不要为了删除角色直接去数据库删sys_role_menu和sys_user_role，因为若依的外键关系不一定在数据库层面强制约束，但业务代码会按关联表查询，一旦数据不一致，用户登录后可能出现空菜单或者权限异常。安全做法是利用系统界面操作，界面会维护关联关系。

7.4 修改角色权限后必须重新登录吗

是的，必须重新登录。因为用户登录成功后，后端返回的菜单权限、按钮权限、角色标识已经缓存在前端。即使后台把角色的菜单改了，已登录用户不会实时同步。这是若依当前版本的设计逻辑，也是大家普遍接受的做法。如果是生产环境，批量调整角色后，通常第二天早上让员工重新登录一次即可。

如果你希望改动后立刻生效，可以考虑在用户管理里提供一个“刷新权限”的入口，调用logout或重新拉取用户信息接口。直接改token缓存也可以实现，但不建议反复折腾，稳定优先。

7.5 岗位和角色的选择口诀

最后给一条特别好记的判断法则：如果这个配置要回答“能不能”，那就是角色；如果只是回答“他是谁、什么职位、什么级别”，就是岗位。岗位不会给你任何菜单和按钮权限，但可以让列表里显示他的职务信息。角色哪怕名称写得再复杂，也不改变它是“权限集合”的本质。两者互不替代，但在界面上经常并列出现，所以容易混淆。

我在实际项目中，每次初始化新模块，都会按“部门 → 岗位 → 角色 → 用户”的顺序来配，配完先用测试账号验证一遍菜单和数据范围，再导给真正的人用。虽然多花了十几分钟，但后面因为权限不清导致的返工麻烦少得多。这套四个模块的操作逻辑，在若依框架下是通用的，理解了之后，你再看别的类似后台管理系统，基本都能一眼抓住它的权限套路。