Zhilink SCM（智联数贸平台）项目总结 （各种AI总结）

经过一周的打磨✨ 项目基座终于全部完成啦🎉

接下来就可以专心开发业务功能 + 拓展进阶技能咯～

域名已经申请，下来后我会第一时间对外开放！

欢迎大家来体验试用🙋‍♂️🙋‍♀️，多多帮我提修改建议、揪 bug、测稳定性～

你的每一条反馈，都是项目变得更棒的动力💪

感谢大家支持，一起期待它慢慢长大吧～🚀

Enterprise Digital Supply Chain Management Platform 企业级数字化配件供应链管理平台

一、项目背景

Zhilink SCM 项目是源于家里配件门店的真实管理需求。

通过调研分析传统门店过去长期使用：

• Excel 记账
• 手工统计库存
• 微信记录沟通
• 人工登记进货、出货

导致出现很多问题：

• 库存不准、经常账实不符
• 进货出货没有记录，无法追溯
• 多人使用时权限混乱
• 无法统计销售情况、无法分析经营数据

一开始只是想做简单的商品管理系统，但在开发过程中，我希望把项目做得更规范、更完整、更接近企业级标准，于是逐步扩展成一套前后端分离 + RBAC 权限体系的企业后台基座。

二、项目演进思路

项目从简单到规范，一共分为四个阶段：

1. 第一阶段：基础后台 完成登录、用户管理、RBAC 权限、动态菜单、操作日志。

2. 第二阶段：业务扩展 未来会加入商品、库存、进货、销售、订单模块。

3. 第三阶段：性能优化 引入 Redis 缓存、权限缓存、会话管理。

4. 第四阶段：架构升级 未来可升级为微服务、云原生、多门店 SaaS 平台。

三、项目整体架构

▼
text
复制代码
前端：React 18 + TypeScript + Ant Design + Zustand
     ↓
后端：Spring Boot 3 + Spring Security + JWT
     ↓
存储：PostgreSQL + Redis

四、技术栈（含：为什么选 + 怎么用）

前端

• React 18 为什么：组件化、生态成熟、企业后台主流框架。 怎么用：开发页面、搭建后台管理系统。

• TypeScript 为什么：提供类型安全，减少错误，提高可维护性。 怎么用：约束接口、状态、组件类型。

• Ant Design 5 为什么：企业级 UI 库，开箱即用，美观稳定。 怎么用：快速构建表格、表单、按钮、菜单。

• Zustand 为什么：轻量、简单、比 Redux 更容易使用。 怎么用：存储用户信息、Token、权限列表、菜单。

• Axios 为什么：支持拦截器、统一处理请求。 怎么用：自动携带 Token、自动刷新、统一异常提示。

后端

• Spring Boot 3 为什么：Java 企业开发标准，自动配置，开发效率高。 怎么用：搭建项目、整合所有框架。

• Spring Security 为什么：安全框架，适合做登录、权限控制。 怎么用：实现接口权限拦截、登录认证。

• JWT 为什么：无状态认证，适合前后端分离。 怎么用：生成 AccessToken + RefreshToken。

• Redis 为什么：高性能内存数据库，适合缓存、会话。 怎么用：存储登录状态、权限缓存、强制下线。

• PostgreSQL 为什么：开源、强大、支持复杂查询，适合进销存系统。 怎么用：存储用户、角色、权限、日志等数据。

• MyBatis-Plus 为什么：简化 CRUD，提高开发效率。 怎么用：快速实现数据库操作。

• JDK 17 为什么：LTS 版本，Spring Boot 3 强制要求。 怎么用：项目运行环境。

五、数据库表结构（共 6 张）

采用 RBAC 权限模型，是企业后台最标准、最通用的设计。

六、已完成的核心功能

1. 登录认证体系

• 登录、登出
• JWT 双 Token 机制
• AccessToken 自动刷新
• Redis 会话管理
• 单点登录、强制下线

2. RBAC 权限体系

• 用户管理
• 角色管理
• 权限管理
• 动态菜单
• 按钮级权限控制
• 接口级权限控制

3. 动态菜单 & 动态路由

• 后端根据角色返回菜单
• 前端自动生成路由和侧边栏

4. 操作日志审计

• 记录谁、在何时、做了什么操作
• 支持行为追溯、问题排查

5. 工程化能力

• 统一返回格式
• 全局异常处理
• 跨域配置
• 权限缓存

七、项目亮点

1. 源于真实业务，不是Demo项目
2. 标准 RBAC 权限体系，企业级设计
3. JWT + Redis 双 Token，安全且体验好
4. 前后端双重权限校验
5. 动态菜单、动态路由
6. 6张表极简设计，稳定易扩展
7. 可直接扩展商品、库存、销售业务

八、遇到的问题与解决方案

• 权限修改不生效 → 清理 Redis 缓存
• 页面刷新菜单丢失 → 状态持久化
• 上传接口被拦截 → Spring Security 白名单

九、未来规划

1. 商品管理模块
2. 库存管理模块
3. 订单管理模块
4. 系统监控与运维
5. 数据看板
6. 多门店管理

十、项目收获

通过本项目，我掌握了：

• 前后端分离项目完整开发流程
• Spring Security + JWT + Redis 认证体系
• RBAC 权限模型设计与实现
• React 企业后台开发
• 项目工程化、规范设计
• 从真实需求到系统落地的完整思路

项目已从家庭自用小系统成长为可扩展、可上线、可面试展示的企业级后台基座。

🔥 RBAC改造 + 权限面试题（详细易懂版 · 项目专用）

1. 什么是 RBAC？

RBAC 是基于角色的访问控制。 核心思路是：用户不直接绑定权限，而是通过角色关联权限，结构是： 用户 → 角色 → 权限。 好处是权限统一管理、复用性强、维护成本低，是企业后台最标准的权限模型。

2. 为什么企业普遍使用 RBAC？

• 权限统一由角色管理，不用给每个用户单独配置
• 角色可以复用，比如“管理员、店员、运营”一次配置多人使用
• 新增用户只需要分配角色，权限自动继承
• 结构清晰、扩展性强，适合多人、多部门、复杂后台系统

3. RBAC 核心表有哪些？

• sys_user：用户信息
• sys_role：角色定义
• sys_permission：权限/菜单/按钮
• sys_user_role：用户与角色多对多关联
• sys_role_permission：角色与权限多对多关联
• sys_operation_log：操作日志记录

这是企业最标准、最通用的 6 张表结构。

4. 你的项目权限是怎么实现的？

我项目采用： Spring Security + JWT + Redis + RBAC 实现整套权限体系。

流程：

1. 用户登录，校验账号密码
2. 验证通过，生成 JWT Token
3. 把用户信息、权限列表存入 Redis
4. 前端每次请求在请求头携带 Token
5. 后端通过 JWT Filter 解析 Token
6. 校验 Redis 登录状态是否有效
7. 把用户权限存入 Spring 上下文
8. 接口通过 @PreAuthorize 做权限校验

5. 为什么不直接让用户绑定权限？

如果用户直接绑权限：

• 每个用户都要配一遍，重复工作量巨大
• 权限变更时要改所有用户，极易出错
• 用户越多越难维护

而 RBAC 通过角色中转，一次配置，全员生效。

6. 动态菜单权限怎么实现？

1. 用户登录成功
2. 后端根据 用户 → 角色 → 权限 查询可访问菜单
3. 直接返回菜单树（无权限菜单不返回）
4. 前端根据返回结果动态生成侧边栏与路由

实现不同角色看到不同菜单。

7. JWT 是无状态的，为什么还要用 Redis？

因为纯 JWT 无法主动作废！ 一旦签发，没到期就一直有效。 无法支持：

• 用户退出登录
• 管理员踢人下线
• 修改密码后旧 Token 失效
• 权限变更实时生效

所以我用 JWT 做身份凭证 + Redis 做状态管理，兼顾安全与体验。

8. 为什么要使用双 Token？

项目使用 AccessToken + RefreshToken：

• AccessToken：有效期短，用于接口鉴权，更安全
• RefreshToken：有效期长，用于刷新 AccessToken

好处：

• AccessToken 泄露风险窗口小
• 用户不用频繁登录
• 实现无感续签，体验更流畅

9. 踢人下线怎么实现？

1. Redis 保存用户对应的 Token
2. 管理员踢人时，删除该用户在 Redis 中的所有 Token
3. 用户下次请求时，JWT 还在，但 Redis 校验失败
4. 后端返回未登录，前端强制跳转到登录页

10. 权限修改后怎么实时生效？

角色/权限修改后：

1. 找到拥有该角色/权限的用户
2. 删除他们在 Redis 中的权限缓存/Token
3. 用户下次请求会自动重新登录
4. 加载最新权限，确保立即生效

11. 菜单权限和接口权限为什么要分开？

• 菜单权限：只控制前端页面显不显示
• 接口权限：控制真正的数据访问安全

前端可以被绕过，直接调用接口。 所以后端必须做接口级权限校验，实现前后端双重控制。

12. 什么是 ABAC？

ABAC 是基于属性的权限控制。 不是按角色，而是按： 用户属性、部门、数据范围、时间、条件 动态判断权限。

例如： 只能看自己部门的数据、只能看自己创建的数据。

13. 为什么大型系统会从 RBAC 升级到 ABAC？

RBAC 角色多了会出现角色爆炸： 北京运营、上海运营、夜班运营、高级运营… 维护成本极高。

ABAC 不用建大量角色，通过规则动态控制，更灵活，适合 SaaS、多租户、复杂数据权限场景。

14. ABAC 主要控制什么？

主要控制数据权限（行权限）。 比如：

• 只能看自己部门的订单
• 只能看自己创建的商品
• 不同区域看到不同数据

15. 企业里真实用 RBAC 还是 ABAC？

绝大多数企业是： RBAC + ABAC 混合使用。

• RBAC：控制菜单、页面、按钮、接口
• ABAC：控制数据范围、部门权限、数据隔离

16. 你的权限系统未来可以怎么升级？

• 增加 ABAC 数据权限
• 优化 Redis 权限缓存
• 支持 多租户 SaaS
• 拆分为微服务认证中心
• 加入限流、日志、安全审计增强

17. 你觉得权限系统最难的点是什么？

最难的不是 CRUD，而是权限一致性与实时性：

• 权限修改后要实时生效
• Redis 缓存要及时清理
• 前后端权限必须同步
• 踢人、失效、刷新逻辑要严谨
• 登录状态、Token 生命周期要安全

这些细节最容易出问题，也是企业项目最看重的部分。