企业官网建设流程全解析

1. 系列写到第四篇，为什么停下来专门聊基础数据

写若依前后端分离版从0到1搭建项目这个系列时，我给自己定的原则是每一篇都解决一个具体问题。前几篇把环境准备、项目初始化和登录流程走通之后，后台已经能正常打开了，但真正开始往里填业务时，第一个要面对的往往不是写代码，而是把“用户、角色、部门、岗位”这四个模块先理顺。

很多人第一次打开若依后台，看到“系统管理”下面这一排菜单，第一反应是“这不就是增删改查吗，有什么好讲的”。可真到自己上手时会发现，问题几乎都出在这几个模块的组合关系上：新建了用户却登录不了，挂了角色却看不到菜单，能看到菜单了又查不到其他部门的数据。这些症状追根溯源，基本都是用户、角色、部门、岗位之间的关系没搞清楚。

这一篇的定位很明确：适合两类人。一类是刚把若依跑起来、正要往下搭功能的新手，能少走很多弯路；另一类是用若依接手过项目、但权限配置一直靠试错摸索的开发者，可以趁机把整套权限模型的逻辑重新捋一遍。读完这篇，你要能回答三个问题：这四个模块各自负责什么？它们之间怎么关联？实际项目里应该按什么顺序配置、遇到问题从哪里查？

我尽量少讲点开文档就能看到的东西，重点讲操作背后的判断逻辑和踩坑经验。毕竟权限这种东西，配错了通常不会立刻报错，而是过几天业务同事跑过来问“为什么我少了一条数据”的时候，你才意识到大事不妙。

2. 先看数据模型：四张主表和四张关联表怎么撑起权限体系

在点“新增用户”之前，建议先花五分钟了解若依权限体系的数据结构。这个框架能一直保持结构清晰，不是因为功能少，而是因为它把权限拆得非常干净：部门管组织归属，岗位管人事标签，角色管功能与数据权限，用户是所有这些的载体。

若依的基础数据落到数据库里，核心就是四张主表和四张关联表：

• 主表：sys_user、sys_role、sys_dept、sys_post；
• 关联表：sys_user_role、sys_user_post、sys_role_dept、sys_role_menu。

2.1 用户、角色、部门、岗位各管什么

用户表（sys_user）存的是能登录系统的人，登录名、密码、昵称、手机号、部门归属都在这张表里。角色表（sys_role）是权限的容器，它决定了一个用户登录后能看到哪些菜单、能操作哪些按钮，以及在业务数据上能查多大范围。部门表（sys_dept）是组织架构的树形结构，既用来把用户归类到某个组织节点，也是数据权限过滤的重要依据。岗位表（sys_post）则是纯粹的组织人事标签，比如项目经理、开发工程师、客服专员，它起到身份描述和分类筛选的作用。

这四个模块的边界，新手很容易混淆。尤其岗位和角色，看起来都是“给别人一个身份”，实际差别巨大。角色决定你能不能访问页面、能不能点按钮、能不能看别人的数据；岗位基本不影响这些，它更像公司工牌上的职位名称。

2.2 关联表才是权限真正生效的地方

用户和角色是多对多，中间通过sys_user_role关联；用户和岗位也是多对多，通过sys_user_post关联。角色和菜单的关系在sys_role_menu里，角色和部门的关系在sys_role_dept里。

看到这里你大概就能理解，若依的权限不是“用户身上挂几个权限key”这种简单模型，而是“用户 → 角色 → 菜单/部门范围”的链路。后面无论是排查登录问题，还是开发自己的业务接口，只要链路清晰，效率会高很多。

我把这几张表的核心作用整理成一个表，后面排查问题时可以直接对照：

2.3 初始化数据里的“隐藏信息”

装完若依后，SQL脚本里会自带一套示例数据，默认部门包括总公司、分公司、技术部这类组织节点，岗位也内置了董事长、项目经理、普通员工等，角色则有一个不能动的超级管理员和一个普通角色，用户默认是admin。

新手拿到这套数据，通常会纠结“要不要都删了重建”。我的建议是：前期不要删，直接拿它练手。你可以在示例部门下面挂自己的业务用户，也可以把示例岗位改名复用。等完全吃透这套权限链路之后，再根据公司真实组织架构清理重建。唯一要注意的是，admin这个超级管理员尽量保留不动，它是你所有操作的最后兜底；删了它或者把它停用了，后面想恢复只能去动数据库，非常麻烦。

3. 用户管理：建一个能正常登录的人，细节比想象中多

用户管理在“系统管理 → 用户管理”里，界面是一个标准的列表页面，带用户名、昵称、手机号、部门、角色、状态这些检索条件。这个模块在权限链路上是终点——前面所有配置最终都要汇聚到一个用户身上，但实际操作时，它反而是错误高发区。

3.1 新增用户的完整流程与字段背后的用意

点击“新增用户”，表单里字段不算多，但每个字段都有讲究：

• 用户名：这是登录名，全系统唯一。创建后能不能改取决于版本和配置，但我的建议是一开始就按规范来，比如用拼音或工号。
• 昵称：展示用名称，可以不唯一，前台显示时通常用它。
• 手机号和邮箱：建议必填。虽然不填也能创建成功，但后续涉及密码找回、通知推送时，空字段会带来麻烦。一些企业做等保测评时，也会要求登录账号有真实的联系方式。
• 部门：必选。用户挂在哪个组织节点下，直接决定“本部门数据”和“本部门及以下数据”这类权限的过滤范围。这里有个常见误解：把用户挂在总公司，让他“看所有部门的数据”，这其实是走了一个取巧路径，一旦角色范围缩小，反而会出现权限越界或失效。
• 岗位：可以多选。比如一个人既负责研发又兼顾产品评审，就给他挂两个岗位。岗位本身不影响登录和权限，但会出现在列表和统计里，方便按岗位筛选人员。
• 角色：必选。这是用户能否看到菜单的核心，千万别建完用户不勾角色。用户登录后一片空白的案例，十有八九是这一步漏了。
• 初始密码：若依有系统参数控制密码规则，旧版本常见的是123456，但正规项目里建议第一次创建时就设置一个临时密码，随后让用户自己修改。密码复杂度太低，等保和客户评审都会被挑战。

完整操作顺序就是：系统管理 → 用户管理 → 新增 → 填资料 → 选部门和岗位 → 勾角色 → 设初始密码 → 保存。保存后最好立刻用这个账号登录一遍，确认菜单和数据范围符合预期。

3.2 新增用户之外的三个高频操作

用户管理列表里还有一个“分配角色”的操作，它和新增用户时勾选角色效果一样，都是为了维护用户与角色的绑定关系。区别在于，当你已经建了一批用户，想批量调整权限时，用“分配角色”会更方便；而新增用户时直接勾角色，能避免“建了用户忘了授权”。

重置密码也是日常高频操作。点击重置密码会弹出窗口让你设置新密码，一旦执行，用户当前密码立即失效。这里有两个习惯可以参考：重置前先线下确认对方身份，避免误操作；重置后让用户首次登录马上改密码，降低口令泄露风险。

删除用户则是典型的物理删除。删掉后用户与角色、岗位的关联关系会一起清理，如果这个用户已经产生了业务数据，就会出现创建人字段查不到用户的情况。我在项目里一般会先用一个停用操作替代删除，确认一段时间没有问题后再清理，这样更稳妥。

另外，不要把测试账号和正式账号混用。很多团队为了省事，几个人共用一个账号，权限出了问题根本说不清是哪个配置导致的。我通常建test_ops、test_view这类一次性测试账号，配合不同角色反复验证，测完删掉，反而比共用一个admin靠谱得多。

4. 角色管理：菜单权限与数据权限，权限体系的核心地带

如果你只打算在这四个模块里多花点时间，我的建议是全部投给角色管理。用户只是“谁”，角色才是“能干什么、能看多少数据”的定义者。若依的角色管理分两大块：菜单权限和数据权限，绝大多数权限问题都出在这两块没配好。

4.1 菜单权限：一棵决定你能看到什么的树

新建角色时，左侧是一棵菜单权限树，按目录、菜单、按钮三级展示。目录和菜单决定页面是否出现在导航栏，按钮节点则对应具体的操作权限，比如“用户新增”“用户编辑”“用户删除”。若依在后端接口层面做鉴权，用的就是这些按钮节点映射出来的权限标识。

勾选菜单权限时有几个容易踩的误区。第一，只勾了目录没勾里面的菜单和按钮，用户登录后能看到目录，但点进去是一片空白，或者操作时报403。第二，勾选时没有展开子节点，以为全选了，实际只选了一部分。第三，为了方便把整棵树全勾上，结果用户登录后所有模块全露出来，这既违背了“最小权限”原则，也让业务界面变得冗余。

我的建议是每次只按业务需要勾选。负责用户维护的角色，就勾“系统管理 → 用户管理”下的目录、列表、按钮；财务角色只勾与报表相关的菜单。权限字符的命名也要想好，比如“system:user:list”“system:user:add”这类，后面写接口校验时直接引用，命名混乱的话代码里会很难看。

4.2 数据权限五档：从“只看自己”到“看全部”

菜单权限控制的是“看得到”，数据权限控制的是“看多少”。若依提供了五种范围，理解它们比操作本身更关键：

这里要解释一个底层规则：数据权限不是天然对每个菜单都生效，它主要作用于若依内置的管理模块。后续你自己开发的业务模块，如果想让数据权限生效，需要接入若依的数据权限注解，在查询语句上自动拼接过滤条件。很多人是等到自研模块上线后，发现“明明配了数据权限却没用”，才知道了这个限制。

4.3 实操示例：给角色配一个“部门运营”权限

我以一个最常见的配置为例，带你把整个过程走一遍。假设公司要设置一个“部门运营”角色，只看本部门及以下的数据：

1. 进入“系统管理 → 角色管理”，点击新增。
2. 角色名称填“部门运营”，权限字符填“dept_operator”。权限字符建议用统一的英文缩写，避免后面做接口鉴权时看不懂。
3. 菜单权限里勾选“系统管理 / 用户管理 / 部门管理 / 岗位管理”，以及对应的按钮节点。如果运营人员还需要查字典、参数，按需追加。
4. 数据权限选择“本部门及以下数据权限”。
5. 保存后在角色列表点击“分配用户”，把目标用户加进来。

这样做完之后，让目标用户重新登录，打开用户管理刷新列表，会发现列表里只剩本部门及以下的人。如果同时挂了一个“全部数据”的管理员角色，那“部门运营”的过滤就会被放宽，所以调试权限时最好一个用户只挂一个测试角色。

4.4 多角色叠加时的权限合并逻辑

若依支持一个用户挂多个角色，权限并不是只取其中一个，而是会合并。菜单权限上是并集，被任何一个角色勾选的菜单都会显示；数据权限则是取更宽松的范围，哪个角色的数据范围更大，最终过滤就按更大的来。

这里就产生了一个常见隐患：给用户同时挂了“仅本人”和“全部数据”两个角色，实际效果等于“全部数据”。你再怎么解释“我只想让他看自己的数据”都没用，配置本身已经把范围放开了。所以，一个用户尽量只挂一个角色，除非你非常清楚合并规则。排查权限问题时，也建议先把用户的角色列表拉出来看一遍，而不是只盯着某一个角色分析。

5. 部门与岗位：组织架构怎么搭，才不会给权限挖坑

部门与岗位在操作上比角色简单，但只要架构搭错了，后面改起来比写代码还痛苦。尤其是部门树，它牵扯到数据权限和用户归属，乱建层级会直接导致查询结果莫名其妙。

5.1 部门管理：树形结构背后是祖级路径

部门管理用左侧树形目录展示，新增部门时选择上级部门，然后填部门名称、排序、负责人、电话、邮箱。数据库里，每个部门除了parent_id，还有个ancestors字段记录从根部门到当前部门的完整路径。查询某个部门下面的所有子部门时，就是靠这个路径做匹配。手动改数据不推荐，让框架维护就好。

搭部门树有三条经验：

• 层级别太深，建议控制在三层以内，比如“公司 → 部门 → 小组”。数据权限“本部门及以下”会把这一整段范围全部算进去，层级越深越难解释权限关系。
• 不要把部门和岗位混着建，比如在部门里建一个“财务经理”节点，这就把组织架构和人事头衔混在一起了，后面统计会很乱。
• 部门停用后，该部门下的用户登录会受影响，所以不要随便停用部门，最好先确认下面的用户是否已经迁移到其他部门。

另外，部门树里有个“负责人”字段，很多人会忽略。它的意义更多在于业务层面的联系人信息，比如后续开发审批流、通知提醒时可以直接读取负责人邮箱和电话。新建部门时顺手填上，比之后回头补省事得多。

5.2 岗位管理：一个不影响权限但影响人效的模块

岗位管理界面相对冷清，字段也就是岗位编码、岗位名称、岗位排序和状态。如果你从人事系统的角度去理解，它就是职位头衔；如果你从若依的权限链路去理解，它其实不参与菜单权限和数据权限的计算，更像一个分类标签。

有人说“那岗位不是没用吗”？不是没用，它有两种现实价值：一是用户列表和详情里能展示这个人担任什么职务，方便按岗位筛选；二是你在开发业务模块时，如果希望按岗位划分处理人，比如工单系统里只允许项目经理审批某些操作，就可以通过用户与岗位的关系拿到身份来做规则判断。

岗位编码是个容易被忽视的字段。我见过不少项目里岗位编码随便填“1”“2”，等后来做接口对接或者写Excel导出时，根本认不出岗位含义。建议统一收口成类似“dp_manager”“dp_staff”“dp_director”的风格，即使现在用不上，后续扩展也会轻松很多。

5.3 部门、岗位、角色三者为什么不能混着理解

经常有人问：“部门经理这个头衔，我是建个部门、建个岗位，还是建个角色？”正确的拆法是：部门是组织节点，岗位是职务头衔，角色是权限集合。

一个人可以属于“技术部”这个部门，拥有“组长”这个岗位，同时被分配了“普通开发”这个角色。当他升职带团队后，部门可以不变，岗位改成“经理”，角色从“普通开发”换成“项目经理”，这样调整最小、排查最清楚。

在公司组织架构频繁调整的现实里，如果部门、岗位、角色混在一起改，每次调动都会牵一发而动全身。保持三者的职责边界，就是给后续维护省时间。

6. 一套可以直接上手的配置顺序，和一份高频坑清单

最后这部分，我把实际项目中验证过的一套配置顺序和排查清单整理出来。按这个顺序操作，即使中途出问题，也能把排查范围控制在很小的范围内。

6.1 为什么我建议按“部门 → 岗位 → 角色 → 用户”的顺序来配

这个顺序的核心逻辑是“先有组织，再有标签，再有权限，最后把人和权限绑定”。

反过来操作会怎么样？你会遇到“先建了用户，回头发现角色还没配，又跑回去新建角色，再把用户重新分配一遍”的折腾。顺序调好，体验差距很大。

6.2 一个完整的小型组织配置示例

假设一个小团队要上线若依系统：

1. 部门管理里创建“总公司”，下面建“技术部”和“市场部”，技术部下面再建“后端组”和“前端组”。
2. 岗位管理里创建“技术总监”“后端组长”“后端开发”“市场专员”。
3. 角色管理里创建“管理员”“项目经理”“普通开发”“访客”，分别配置菜单权限和数据权限。“普通开发”数据权限设为“仅本人”，“项目经理”设为“本部门及以下”，“访客”只勾部分菜单。
4. 用户管理里创建张三，部门选“后端组”，岗位选“后端开发”，角色选“普通开发”。

然后分别用管理员、项目经理、普通开发登录，对比一下“用户管理”里能看到的数据条数。这个对比做完，整个权限链路就一目了然了，后面再遇到权限问题，你自己脑子里就会先走一遍这条链路。

6.3 高频坑清单：从登录失败到数据范围异常

最后这份清单，基本覆盖了我见过的绝大多数配置类问题：

• 登录提示用户已停用：检查用户状态，也要检查所在部门状态，部门停用同样会影响用户登录。
• 登录后页面空白：检查角色是否分配，菜单权限是否勾到菜单和按钮这一层。
• 接口返回403：检查菜单树的按钮节点是否勾选，后端权限标识是否匹配。
• 数据权限没生效：先确认角色里数据权限选的是哪种，再确认用户挂的角色是否唯一；自研业务还需要接入若依的数据权限机制，不是配完就自动过滤。
• 自定义数据权限看不到新部门：角色管理里“自定义”勾选的部门是一个快照，不会自动包含后来新建的部门，部门调整后要回到角色里重新勾选。
• 停用部门导致整批用户无法登录：这是正常逻辑，不是bug，先迁移用户再停用。
• 删除了admin或给admin改了异常配置：管理后台瞬间失守，强烈建议保留初始超级管理员不动。
• 权限字符重复或随意命名：后续统计和接口鉴权会非常被动，建议从第一天起就定一套命名规则。

我自己操作时还有一个习惯：每次调整完权限，不只在界面里刷新，而是用一个隐身窗口重新登录测试账号，走一遍“看到菜单 → 点击列表 → 导出数据”的完整路径。权限配置这种事，界面显示正常不等于接口真正受控。等基础数据搭建好，这套逻辑理解透了，后面开发业务模块、挂菜单、配按钮权限都会顺很多，至少不会再有人隔三差五跑过来问“为什么我登录后没有这个菜单”。下一篇要聊的内容大概率会落在菜单管理和字典配置上，那是业务功能落地前必须铺好的底子。