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”这种简单模型而是“用户 → 角色 → 菜单/部门范围”的链路。后面无论是排查登录问题还是开发自己的业务接口只要链路清晰效率会高很多。我把这几张表的核心作用整理成一个表后面排查问题时可以直接对照表作用常见误区sys_user存登录账号与用户基本资料以为用户表里有权限字段其实权限都在角色那边sys_role存角色名称、权限字符、数据范围只关注菜单权限忽略数据权限配置sys_dept组织架构树用户归属部门层级乱建导致数据权限过滤范围异常sys_post岗位名称与编码以为岗位能控制权限实际上只是人事标签sys_user_role用户和角色的关系一个用户挂多个角色后权限范围不好判断sys_role_dept自定义数据权限时勾选的部门部门后来改了角色关联的部门不会自动同步sys_role_menu角色可见的菜单/按钮忘记勾按钮节点接口权限校验不通过sys_user_post用户与岗位的关系多岗位时列表展示容易混淆实际不影响登录权限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 实操示例给角色配一个“部门运营”权限我以一个最常见的配置为例带你把整个过程走一遍。假设公司要设置一个“部门运营”角色只看本部门及以下的数据进入“系统管理 → 角色管理”点击新增。角色名称填“部门运营”权限字符填“dept_operator”。权限字符建议用统一的英文缩写避免后面做接口鉴权时看不懂。菜单权限里勾选“系统管理 / 用户管理 / 部门管理 / 岗位管理”以及对应的按钮节点。如果运营人员还需要查字典、参数按需追加。数据权限选择“本部门及以下数据权限”。保存后在角色列表点击“分配用户”把目标用户加进来。这样做完之后让目标用户重新登录打开用户管理刷新列表会发现列表里只剩本部门及以下的人。如果同时挂了一个“全部数据”的管理员角色那“部门运营”的过滤就会被放宽所以调试权限时最好一个用户只挂一个测试角色。4.4 多角色叠加时的权限合并逻辑若依支持一个用户挂多个角色权限并不是只取其中一个而是会合并。菜单权限上是并集被任何一个角色勾选的菜单都会显示数据权限则是取更宽松的范围哪个角色的数据范围更大最终过滤就按更大的来。这里就产生了一个常见隐患给用户同时挂了“仅本人”和“全部数据”两个角色实际效果等于“全部数据”。你再怎么解释“我只想让他看自己的数据”都没用配置本身已经把范围放开了。所以一个用户尽量只挂一个角色除非你非常清楚合并规则。排查权限问题时也建议先把用户的角色列表拉出来看一遍而不是只盯着某一个角色分析。5. 部门与岗位组织架构怎么搭才不会给权限挖坑部门与岗位在操作上比角色简单但只要架构搭错了后面改起来比写代码还痛苦。尤其是部门树它牵扯到数据权限和用户归属乱建层级会直接导致查询结果莫名其妙。5.1 部门管理树形结构背后是祖级路径部门管理用左侧树形目录展示新增部门时选择上级部门然后填部门名称、排序、负责人、电话、邮箱。数据库里每个部门除了parent_id还有个ancestors字段记录从根部门到当前部门的完整路径。查询某个部门下面的所有子部门时就是靠这个路径做匹配。手动改数据不推荐让框架维护就好。搭部门树有三条经验层级别太深建议控制在三层以内比如“公司 → 部门 → 小组”。数据权限“本部门及以下”会把这一整段范围全部算进去层级越深越难解释权限关系。不要把部门和岗位混着建比如在部门里建一个“财务经理”节点这就把组织架构和人事头衔混在一起了后面统计会很乱。部门停用后该部门下的用户登录会受影响所以不要随便停用部门最好先确认下面的用户是否已经迁移到其他部门。另外部门树里有个“负责人”字段很多人会忽略。它的意义更多在于业务层面的联系人信息比如后续开发审批流、通知提醒时可以直接读取负责人邮箱和电话。新建部门时顺手填上比之后回头补省事得多。5.2 岗位管理一个不影响权限但影响人效的模块岗位管理界面相对冷清字段也就是岗位编码、岗位名称、岗位排序和状态。如果你从人事系统的角度去理解它就是职位头衔如果你从若依的权限链路去理解它其实不参与菜单权限和数据权限的计算更像一个分类标签。有人说“那岗位不是没用吗”不是没用它有两种现实价值一是用户列表和详情里能展示这个人担任什么职务方便按岗位筛选二是你在开发业务模块时如果希望按岗位划分处理人比如工单系统里只允许项目经理审批某些操作就可以通过用户与岗位的关系拿到身份来做规则判断。岗位编码是个容易被忽视的字段。我见过不少项目里岗位编码随便填“1”“2”等后来做接口对接或者写Excel导出时根本认不出岗位含义。建议统一收口成类似“dp_manager”“dp_staff”“dp_director”的风格即使现在用不上后续扩展也会轻松很多。5.3 部门、岗位、角色三者为什么不能混着理解经常有人问“部门经理这个头衔我是建个部门、建个岗位还是建个角色”正确的拆法是部门是组织节点岗位是职务头衔角色是权限集合。一个人可以属于“技术部”这个部门拥有“组长”这个岗位同时被分配了“普通开发”这个角色。当他升职带团队后部门可以不变岗位改成“经理”角色从“普通开发”换成“项目经理”这样调整最小、排查最清楚。在公司组织架构频繁调整的现实里如果部门、岗位、角色混在一起改每次调动都会牵一发而动全身。保持三者的职责边界就是给后续维护省时间。6. 一套可以直接上手的配置顺序和一份高频坑清单最后这部分我把实际项目中验证过的一套配置顺序和排查清单整理出来。按这个顺序操作即使中途出问题也能把排查范围控制在很小的范围内。6.1 为什么我建议按“部门 → 岗位 → 角色 → 用户”的顺序来配这个顺序的核心逻辑是“先有组织再有标签再有权限最后把人和权限绑定”。步骤操作理由1搭部门树用户和角色的数据权限范围都依赖部门节点2建岗位岗位是纯标签但建用户时要选所以先备好3建角色并配好菜单与数据权限建用户时直接勾选可用角色避免中间折返4建用户绑定部门和岗位分配角色然后立刻用测试账号验证反过来操作会怎么样你会遇到“先建了用户回头发现角色还没配又跑回去新建角色再把用户重新分配一遍”的折腾。顺序调好体验差距很大。6.2 一个完整的小型组织配置示例假设一个小团队要上线若依系统部门管理里创建“总公司”下面建“技术部”和“市场部”技术部下面再建“后端组”和“前端组”。岗位管理里创建“技术总监”“后端组长”“后端开发”“市场专员”。角色管理里创建“管理员”“项目经理”“普通开发”“访客”分别配置菜单权限和数据权限。“普通开发”数据权限设为“仅本人”“项目经理”设为“本部门及以下”“访客”只勾部分菜单。用户管理里创建张三部门选“后端组”岗位选“后端开发”角色选“普通开发”。然后分别用管理员、项目经理、普通开发登录对比一下“用户管理”里能看到的数据条数。这个对比做完整个权限链路就一目了然了后面再遇到权限问题你自己脑子里就会先走一遍这条链路。6.3 高频坑清单从登录失败到数据范围异常最后这份清单基本覆盖了我见过的绝大多数配置类问题登录提示用户已停用检查用户状态也要检查所在部门状态部门停用同样会影响用户登录。登录后页面空白检查角色是否分配菜单权限是否勾到菜单和按钮这一层。接口返回403检查菜单树的按钮节点是否勾选后端权限标识是否匹配。数据权限没生效先确认角色里数据权限选的是哪种再确认用户挂的角色是否唯一自研业务还需要接入若依的数据权限机制不是配完就自动过滤。自定义数据权限看不到新部门角色管理里“自定义”勾选的部门是一个快照不会自动包含后来新建的部门部门调整后要回到角色里重新勾选。停用部门导致整批用户无法登录这是正常逻辑不是bug先迁移用户再停用。删除了admin或给admin改了异常配置管理后台瞬间失守强烈建议保留初始超级管理员不动。权限字符重复或随意命名后续统计和接口鉴权会非常被动建议从第一天起就定一套命名规则。我自己操作时还有一个习惯每次调整完权限不只在界面里刷新而是用一个隐身窗口重新登录测试账号走一遍“看到菜单 → 点击列表 → 导出数据”的完整路径。权限配置这种事界面显示正常不等于接口真正受控。等基础数据搭建好这套逻辑理解透了后面开发业务模块、挂菜单、配按钮权限都会顺很多至少不会再有人隔三差五跑过来问“为什么我登录后没有这个菜单”。下一篇要聊的内容大概率会落在菜单管理和字典配置上那是业务功能落地前必须铺好的底子。