数据库设计：RBAC数据模型

这是一个典型的基于SQLAlchemy的RBAC权限系统数据模型实现，各模型分工明确，共同构成完整的权限管理系统。

图解说明：

1. 实体关系：

   • 用户(USER)和角色(ROLE)通过 USER_ROLE 中间表实现多对多关系

   • 角色(ROLE)和权限(PERMISSION)通过 ROLE_PERMISSION 中间表实现多对多关系

2. 关键连接点：

   USER → USER_ROLE ← ROLE → ROLE_PERMISSION ← PERMISSION

   这个链条完整表达了"用户→角色→权限"的授权路径

3. 箭头含义：

   • ||--o{ 表示一对多关系

   • PK 表示主键

   • FK 表示外键

4. 实际业务流：
   当检查用户是否有某接口的访问权限时，系统会：

   用户ID → 查询USER_ROLE → 获取角色列表 → 
   查询ROLE_PERMISSION → 获取权限列表 → 
   匹配权限中的resource字段与当前请求接口

这个图示清晰地展示了您提供的四个模型如何协作完成RBAC权限控制。如果需要更详细的流程图或时序图，我可以进一步补充。

1. Role (角色模型)

• 核心作用：定义系统中的角色实体

• 关键字段：

  • role_name: 角色唯一标识（如admin/hr/interviewer）

  • description: 角色描述信息

• 关联关系：

  • users: 通过UserRole关联到用户（一对多）

  • permissions: 通过RolePermission关联到权限（一对多）

• 业务意义：角色是权限分配的中间层，用户通过角色间接获得权限

2. Permission (权限模型)

• 核心作用：定义系统中的具体权限项

• 关键字段：

  • permission_name: 权限唯一标识（如knowledge_create）

  • resource: 关联的资源路径/API端点

• 关联关系：

  • roles: 通过RolePermission关联到角色（一对多）

• 业务意义：权限是系统中最细粒度的访问控制单元，直接对应具体操作

3. UserRole (用户-角色关联模型)

• 核心作用：维护用户与角色的多对多关系

• 关键设计：

  • 联合唯一约束(uq_user_role): 防止重复分配相同角色

  • 级联删除: 用户删除时自动解除关联

• 关联关系：

  • user: 关联到用户表

  • role: 关联到角色表

• 业务意义：实现"用户拥有哪些角色"的映射关系

4. RolePermission (角色-权限关联模型)

• 核心作用：维护角色与权限的多对多关系

• 关键设计：

  • 联合唯一约束(uq_role_permission): 防止重复分配相同权限

  • 级联删除: 角色删除时自动解除关联

• 关联关系：

  • role: 关联到角色表

  • permission: 关联到权限表

• 业务意义：实现"角色包含哪些权限"的映射关系

整体协作流程

1. 管理员创建权限(Permission)并定义其对应的资源

2. 创建角色(Role)并将相关权限关联到角色(RolePermission)

3. 为用户分配角色(UserRole)

4. 系统通过检查用户的角色→权限→资源路径链来确定访问权限

这种设计实现了权限管理的解耦，使系统能够灵活应对权限变更，同时通过中间表实现了多对多关系的维护。

class User(Base):__tablename__ = 'user'__table_args__ = {'extend_existing': True}user_id = Column(Integer, primary_key=True, autoincrement=True, comment='Primary Key')user_name = Column(String(100), nullable=False)password = Column(String(200), nullable=False)user_email = Column(String(100), nullable=False, unique=True)user_department = Column(String(100), nullable=True)join_time = Column(DateTime, nullable=False, default=datetime.now)# 关联 Session 模型，代表该用户的所有会话sessions = relationship("Session", back_populates="user", cascade="all, delete-orphan")# 关联 Knowledge 模型，代表该用户关联的所有知识knowledge = relationship("Knowledge", back_populates="user", cascade="all, delete-orphan")# 添加与UserRole的关系roles = relationship("UserRole", back_populates="user", cascade="all, delete-orphan")class Role(Base):__tablename__ = 'role'__table_args__ = {'extend_existing': True}role_id = Column(Integer, primary_key=True, autoincrement=True, comment='Primary Key')role_name = Column(String(50), nullable=False, unique=True, comment='角色名称，如admin/hr/interviewer')description = Column(String(200), comment='角色描述')create_time = Column(DateTime, nullable=False, default=datetime.now)modify_time = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)# 关联到UserRole和RolePermissionusers = relationship("UserRole", back_populates="role", cascade="all, delete-orphan")permissions = relationship("RolePermission", back_populates="role", cascade="all, delete-orphan")class Permission(Base):__tablename__ = 'permission'__table_args__ = {'extend_existing': True}permission_id = Column(Integer, primary_key=True, autoincrement=True, comment='Primary Key')permission_name = Column(String(100), nullable=False, unique=True, comment='权限名称，如knowledge_create/session_delete')description = Column(String(200), comment='权限描述')resource = Column(String(200), comment='对应的资源路径/API端点')create_time = Column(DateTime, nullable=False, default=datetime.now)modify_time = Column(DateTime, nullable=False, default=datetime.now, onupdate=datetime.now)# 关联到RolePermissionroles = relationship("RolePermission", back_populates="permission", cascade="all, delete-orphan")class UserRole(Base):__tablename__ = 'user_role'__table_args__ = (UniqueConstraint('user_id', 'role_id', name='uq_user_role'),{'extend_existing': True})id = Column(Integer, primary_key=True, autoincrement=True)user_id = Column(Integer, ForeignKey('user.user_id', ondelete='CASCADE'), nullable=False)role_id = Column(Integer, ForeignKey('role.role_id', ondelete='CASCADE'), nullable=False)create_time = Column(DateTime, nullable=False, default=datetime.now)# 关联到User和Roleuser = relationship("User", back_populates="roles")role = relationship("Role", back_populates="users")class RolePermission(Base):__tablename__ = 'role_permission'__table_args__ = (UniqueConstraint('role_id', 'permission_id', name='uq_role_permission'),{'extend_existing': True})id = Column(Integer, primary_key=True, autoincrement=True)role_id = Column(Integer, ForeignKey('role.role_id', ondelete='CASCADE'), nullable=False)permission_id = Column(Integer, ForeignKey('permission.permission_id', ondelete='CASCADE'), nullable=False)create_time = Column(DateTime, nullable=False, default=datetime.now)# 关联到Role和Permissionrole = relationship("Role", back_populates="permissions")permission = relationship("Permission", back_populates="roles")

后端技术实现流程：

JWT (JSON Web Token)

• 一种紧凑的、URL安全的令牌格式

• 包含三部分：Header(头部)、Payload(负载)和Signature(签名)

• 用于在各方之间安全地传输信息

OAuth 2.0

• 一个授权框架，允许第三方应用获取对资源的有限访问权限

• 定义了四种授权流程(授权码、隐式、密码、客户端凭证)

典型 JWT + OAuth 2.0 流程 (授权码模式)

1. 用户发起授权请求

   • 客户端将用户重定向到授权服务器

   • 携带参数：response_type=code, client_id, redirect_uri, scope等

2. 用户认证与同意

   • 用户在授权服务器登录并同意请求的权限

3. 获取授权码

   • 授权服务器返回授权码到客户端的redirect_uri

4. 用授权码交换令牌

   • 客户端向授权服务器的令牌端点发送请求

   • 携带：grant_type=authorization_code, code, redirect_uri, client_id, client_secret

5. 返回JWT令牌

   • 授权服务器验证后返回访问令牌(通常是JWT)和刷新令牌

   • 响应示例：

     {"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...","token_type": "Bearer","expires_in": 3600,"refresh_token": "def50200ae2f..."
     }

6. 使用访问令牌访问资源

   • 客户端在请求头中加入：Authorization: Bearer <access_token>

   • 资源服务器验证JWT签名和声明

7. 刷新令牌(可选)

   • 当访问令牌过期时，使用刷新令牌获取新的访问令牌

JWT在OAuth中的优势

1. 自包含：JWT包含所有必要信息，减少数据库查询

2. 可验证性：资源服务器可以独立验证JWT而不需联系授权服务器

3. 标准化结构：易于跨语言和平台实现

# app/middlewares/permission.py
from fastapi import Request, HTTPException, Depends
from sqlalchemy.orm import Session
from app.db_init import SessionLocal
from app.models.model import User, Permission, RolePermission, UserRole, Role  # 添加 Role 导入
from functools import wrapsdef permission_required(permission_name: str):"""权限检查依赖工厂函数"""async def dependency(request: Request):db: Session = SessionLocal()try:user_id = getattr(request.state, 'user_id', None)if not user_id:raise HTTPException(status_code=401, detail="未认证")# 检查是否是管理员/root用户user = db.query(User).filter(User.user_id == user_id).first()if not user:raise HTTPException(status_code=401, detail="用户不存在")# 检查用户角色admin_role = (db.query(UserRole).join(Role, Role.role_id == UserRole.role_id).filter(UserRole.user_id == user_id).filter(Role.role_name == 'admin').first())if admin_role:return  # 管理员直接通过权限检查# 普通用户权限检查has_permission = db.query(Permission).join(RolePermission, RolePermission.permission_id == Permission.permission_id).join(UserRole, UserRole.role_id == RolePermission.role_id).filter(UserRole.user_id == user_id,Permission.permission_name == permission_name).first()if not has_permission:raise HTTPException(status_code=403, detail="权限不足")finally:db.close()return Depends(dependency)

permission_required 函数是一个 FastAPI 的权限检查依赖工厂函数，主要用于实现基于权限的访问控制。它的主要作用和功能如下：

1. 功能概述：

   • 它是一个装饰器工厂函数，接收一个权限名称作为参数，返回一个 FastAPI 依赖项

   • 用于检查当前请求的用户是否拥有指定的权限

2. 工作流程：

   • 从请求中获取用户 ID

   • 查询数据库验证用户是否存在

   • 检查用户是否是管理员角色（role_name 为 'admin'），如果是则直接通过检查

   • 对于非管理员用户，检查用户是否拥有指定的权限

   • 如果没有权限则返回 403 错误

3. 权限检查逻辑：

   • 通过连接查询检查用户角色关联的权限

   • 查询涉及多个表：User → UserRole → RolePermission → Permission

   • 只有当用户至少有一个角色拥有指定的权限时才会通过检查

4. 异常处理：

   • 未认证用户（无 user_id）：返回 401

   • 用户不存在：返回 401

   • 权限不足：返回 403

什么是中间件？

在 Web 开发中，中间件（Middleware） 是一种机制，用于在 HTTP 请求到达路由处理函数之前 或 响应返回客户端之前 执行某些逻辑。它类似于一个“拦截器”，可以对请求和响应进行预处理或后处理。

---

中间件的作用

1. 全局处理请求/响应

   • 例如：身份验证、日志记录、跨域处理（CORS）、请求限流、数据压缩等。

2. 修改请求或响应

   • 例如：添加请求头、解析请求体、修改响应数据。

3. 拦截非法请求

   • 例如：检查权限（如你的 permission_required）、阻止未授权的访问。

---

中间件的工作原理

在 FastAPI 或类似的框架（如 Express.js、Django）中，中间件通常按照 洋葱模型（Onion Model） 工作：

请求 → 中间件1 → 中间件2 → ... → 路由处理 → ... → 中间件2 → 中间件1 → 响应

• 请求阶段：中间件按顺序执行（如先验证身份，再检查权限）。

• 响应阶段：中间件按相反顺序执行（如先记录日志，再返回数据）。

---

FastAPI 中的中间件示例

1. 普通中间件（全局拦截）

from fastapi import FastAPI, Requestapp = FastAPI()@app.middleware("http")
async def log_requests(request: Request, call_next):print(f"收到请求: {request.method} {request.url}")response = await call_next(request)  # 继续执行后续中间件或路由print(f"返回响应: {response.status_code}")return response

• 这个中间件会在 每个请求前后 打印日志。

2. 依赖注入式中间件（如你的 permission_required）

from fastapi import Depends, HTTPExceptiondef check_auth(token: str):if token != "secret":raise HTTPException(status_code=403, detail="无权访问")return True@app.get("/admin")
async def admin_route(auth: bool = Depends(check_auth)):return {"message": "欢迎管理员"}

• Depends(check_auth) 是一个依赖项，作用类似于中间件，但更灵活（可以针对单个路由使用）。

---

中间件 vs 依赖注入

特性	中间件	依赖注入（如 Depends）
作用范围	全局或路由组	单个路由
执行顺序	所有请求必经	仅对声明了的路由生效
典型用途	日志、CORS、全局认证	细粒度权限检查、数据库会话管理

---

你的 permission_required 是中间件吗？

严格来说，它 不是传统中间件，而是一个 依赖项工厂函数（返回 Depends）。但它实现了类似中间件的功能（权限检查），只是作用范围更精确（仅对使用它的路由生效）。

---

总结

• 中间件：适合全局逻辑（如日志、CORS）。

• 依赖注入：适合路由级逻辑（如权限、数据库会话）。

• 你的 permission_required 是依赖注入的典型应用，用于实现 RBAC（基于角色的访问控制）。

@router.post('/login')
async def login(request_data: LoginRequest, db = Depends(get_db)):'''登录界面'''username = request_data.usernamepassword = request_data.password# 根据用户名查询数据库中用户的密码info = AuthService.select_user_info(username, db)if info is None:return {'code': 401,'message': 'user not found'}# 密码验证if password != info['password']:return {'code': 401,'message': 'password error'}# 获取用户角色user_roles = AuthService.get_user_roles(info['user_id'], db)is_admin = 'admin' in [role.lower() for role in user_roles]# 获取用户权限permissions = AuthService.get_user_permissions(info['user_id'], db)if permissions is None:permissions = []# 创建JWT令牌access_token_expires = timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)access_token = create_access_token(data={"sub": str(info['user_id']),  # 确保user_id是字符串"username": info['user_name'],"permissions": permissions,"is_admin": is_admin,"roles": user_roles},expires_delta=access_token_expires)return {'code': 200,'message': 'success','data': {'user_id': info['user_id'],'username': info['user_name'],'access_token': access_token,'token_type': 'bearer','permissions': permissions,'roles': user_roles,'is_admin': is_admin}}

这个 login 函数是一个 FastAPI 路由处理函数，用于实现用户登录认证流程。它的核心作用是：

---

主要功能

1. 用户身份认证

   • 接收前端提交的用户名和密码（通过 LoginRequest 模型）。

   • 验证用户名是否存在、密码是否正确。

   • 返回 401 错误码和提示信息（如 "user not found" 或 "password error"）。

2. 权限和角色信息收集

   • 查询用户的角色（如 user_roles）并检查是否是管理员（is_admin）。

   • 查询用户拥有的权限列表（permissions）。

3. 生成 JWT 令牌

   • 使用 create_access_token 生成包含用户信息的 JWT（有效期通过 ACCESS_TOKEN_EXPIRE_MINUTES 控制）。

   • 令牌中存储的关键数据：

     {"sub": "用户ID",          # 用户唯一标识"username": "用户名","permissions": ["权限1", "权限2"],  # 用户权限列表"is_admin": True/False,   # 是否是管理员"roles": ["角色1", "角色2"]       # 用户角色列表
     }

4. 返回登录结果

   • 返回 200 状态码和用户信息（包括令牌、权限、角色等），供前端后续使用。

---

详细流程

1. 参数接收

   • 通过 LoginRequest 模型（未展示但应包含 username 和 password 字段）接收前端提交的登录数据。

2. 用户验证

   • 调用 AuthService.select_user_info 查询数据库，检查用户名是否存在。

   • 比对数据库中的密码（明文比对，实际项目中应使用 哈希密码比对，如 bcrypt）。

3. 权限角色查询

   • 通过 AuthService.get_user_roles 获取用户角色列表，并检查是否包含 admin 角色。

   • 通过 AuthService.get_user_permissions 获取用户权限列表（用于前端动态路由或按钮权限控制）。

4. 令牌生成

   • 使用 create_access_token（可能是 fastapi-jwt 或类似库）生成 JWT，包含用户关键信息。

5. 响应返回

   • 返回结构化响应，包含令牌和用户信息，例如：

     {"code": 200,"message": "success","data": {"user_id": 123,"username": "john","access_token": "xxx.yyy.zzz","permissions": ["read", "write"],"roles": ["user"],"is_admin": false}
     }

---

关键点说明

1. 安全注意事项

   • 密码明文存储问题：当前代码直接比对明文密码，实际项目应使用 密码哈希（如 bcrypt）存储和验证。

   • JWT 敏感信息：令牌中存储了 permissions 和 roles，需确保 JWT 使用 HTTPS 传输并设置合理有效期。

2. 权限控制设计

   • 前端可根据返回的 permissions 和 roles 动态渲染界面。

   • 后端可通过 permission_required 中间件（如你之前提供的）进一步校验权限。

3. 扩展性

   • 可添加登录日志记录、多设备登录限制、验证码等功能。

---

典型使用场景

1. 前端提交登录表单 → 后端验证 → 返回令牌。

2. 前端将令牌存储在 localStorage 或 Cookie 中，后续请求通过 Authorization: Bearer <token> 头部携带。

3. 其他受保护的路由通过中间件校验令牌和权限（如 @router.get("/admin", dependencies=[Depends(permission_required("admin_access"))]）。

这个函数是典型的认证系统核心部分，实现了从登录到权限令牌分发的完整流程。

from fastapi import Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
from jose import JWTError, jwt
from datetime import datetime, timedelta
from utils.configs import SECRET_KEY, ALGORITHM, ACCESS_TOKEN_EXPIRE_MINUTES
from fastapi import Request# OAuth2 配置
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")# 创建访问令牌
def create_access_token(data: dict, expires_delta: timedelta = None):to_encode = data.copy()if expires_delta:expire = datetime.utcnow() + expires_deltaelse:expire = datetime.utcnow() + timedelta(minutes=15)to_encode.update({"exp": expire})encoded_jwt = jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)return encoded_jwtasync def get_current_user(token: str = Depends(oauth2_scheme)):credentials_exception = HTTPException(status_code=status.HTTP_401_UNAUTHORIZED,detail="Could not validate credentials",headers={"WWW-Authenticate": "Bearer"},)try:payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])user_id = payload.get("sub")if user_id is None:raise credentials_exceptionpermissions = payload.get("permissions", [])username = payload.get("username")is_admin = payload.get("is_admin", False)roles = payload.get("roles", [])# 返回一个包含所需信息的字典return {"user_id": user_id,"username": username,"permissions": permissions,"is_admin": is_admin,"roles": roles}except JWTError:raise credentials_exceptionasync def auth_middleware(request: Request, call_next):try:token = request.headers.get('Authorization')if token and token.startswith('Bearer '):token = token.split(' ')[1]payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])request.state.user_id = payload.get("sub")request.state.permissions = payload.get("permissions", [])except JWTError:passresponse = await call_next(request)return response

这几个函数共同构成了一个 FastAPI 的 JWT 认证系统，分别负责 令牌生成、用户认证和请求拦截。以下是它们的详细作用：

---

1. create_access_token - JWT 令牌生成

作用：
生成一个包含用户信息的 JWT（JSON Web Token），用于身份验证和授权。

关键逻辑：

• 接收一个字典 data（包含用户信息如 user_id、permissions 等）。

• 设置令牌过期时间（默认 15 分钟，或通过 expires_delta 自定义）。

• 使用 SECRET_KEY 和 ALGORITHM（如 HS256）签名令牌。

示例输出：

token = create_access_token({"sub": "123", "username": "john"})
# 类似：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE2...

---

2. get_current_user - 当前用户认证

作用：
解析请求中的 JWT 令牌，验证用户身份并返回用户信息。

关键逻辑：

• 通过 OAuth2PasswordBearer 自动从请求头 Authorization: Bearer <token> 提取令牌。

• 解码令牌并验证签名（使用 SECRET_KEY）。

• 提取关键字段（如 user_id、permissions、is_admin）。

• 如果令牌无效或过期，抛出 401 Unauthorized 错误。

典型用法：

@app.get("/protected")
async def protected_route(user: dict = Depends(get_current_user)):return {"user": user}

---

3. auth_middleware - 认证中间件

作用：
拦截所有请求，解析 JWT 令牌并将用户信息注入到 request.state 中，供后续路由或中间件使用。

关键逻辑：

• 从请求头提取 Bearer 令牌。

• 解码令牌并提取 user_id 和 permissions，存入 request.state。

• 如果令牌无效，静默跳过（不中断请求，适合非强制校验的场景）。

与 get_current_user 的区别：

特性	auth_middleware	get_current_user
作用范围	全局（所有请求）	单个路由（需显式声明 Depends）
认证严格性	静默失败（仅注入数据）	严格失败（401 错误）
典型用途	日志、基础用户信息注入	需要强认证的路由

---

协作流程

1. 用户登录

   • 调用 create_access_token 生成令牌并返回给前端。

2. 前端请求

   • 在请求头中添加 Authorization: Bearer <token>。

3. 请求处理

   • auth_middleware 拦截请求，解析令牌并注入用户信息到 request.state。

   • 路由层可通过 get_current_user 进一步严格校验（如需要权限的接口）。

---

安全注意事项

1. 密钥管理

   • SECRET_KEY 必须保密，且不要硬编码在代码中（从环境变量读取）。

2. 令牌有效期

   • 生产环境中 ACCESS_TOKEN_EXPIRE_MINUTES 不宜过长（通常 15-60 分钟）。

3. 算法选择

   • 推荐使用 HS256（对称加密）或 RS256（非对称加密）。

4. 中间件静默失败

   • auth_middleware 不强制拦截无效令牌，需确保关键路由额外依赖 get_current_user。

---

扩展建议

• 刷新令牌：添加 refresh_token 机制实现无感续期。

• 权限校验：结合 permission_required（你之前的代码）实现细粒度控制。

• 日志记录：在中间件中记录用户操作日志。

这些函数共同构建了一个完整的 JWT 认证体系，覆盖了从令牌生成到请求处理的完整链路。

然后将这个认证中间件添加到接收HTTP请求之前

然后在路由中添加权限名称

在 FastAPI 中，_=permission_required("abilities_read") 是一种 依赖注入（Dependency Injection） 的用法，用于在路由处理函数执行前进行 权限校验。以下是详细解释：

---

1. 代码含义

• permission_required("abilities_read")
  这是一个依赖项工厂函数（你之前定义的），它会检查当前用户是否拥有 abilities_read 权限。

• _=
  将依赖项的返回值赋值给变量 _（下划线是 Python 中约定用于“忽略此变量”的命名方式），表示我们不需要在函数体内使用这个返回值。

---

2. 执行流程

1. 请求到达路由
   当客户端访问 GET /api/abilities 时，FastAPI 会先执行 permission_required("abilities_read") 的校验逻辑。

2. 权限校验

   • 如果用户 有权限：继续执行 get_abilities 函数体。

   • 如果用户 无权限：直接返回 403 Forbidden 错误（由 permission_required 抛出）。

3. 处理业务逻辑
   只有通过权限校验后，才会调用 get_all_competency_items() 获取数据并返回。

---

3. 为什么用 _=？

• 明确忽略返回值：
  permission_required 可能返回某些值（如用户信息），但当前路由不需要使用它，用 _ 表示“故意忽略”。

• 代码可读性：
  明确告诉其他开发者：“这里有一个权限检查，但我不需要它的结果”。

前端：基于 Vuex 的前端状态管理 + JWT 认证体系

import axios from 'axios'
import { API_URLS } from '@/config/api'const state = {token: localStorage.getItem('token') || null,user: null,permissions: [],role: null
}const mutations = {SET_TOKEN(state, token) {state.token = tokenlocalStorage.setItem('token', token)axios.defaults.headers.common['Authorization'] = `Bearer ${token}`},CLEAR_TOKEN(state) {state.token = nulllocalStorage.removeItem('token')delete axios.defaults.headers.common['Authorization']},SET_USER(state, user) {state.user = user},SET_PERMISSIONS(state, permissions) {state.permissions = permissions},SET_ROLE(state, role) {state.role = role}
}const actions = {async login({ commit }, { username, password }) {const response = await axios.post(API_URLS.LOGIN, { username, password })commit('SET_TOKEN', response.data.access_token)commit('SET_PERMISSIONS', response.data.permissions)return response.data},async fetchPermissions({ commit, state }) {if (!state.token) returnconst response = await axios.get(API_URLS.PERMISSIONS)commit('SET_PERMISSIONS', response.data.permissions)return response.data},logout({ commit }) {commit('CLEAR_TOKEN')commit('SET_USER', null)commit('SET_PERMISSIONS', [])commit('SET_ROLE', null)},async getPermissions({ commit }) {const response = await axios.get('/auth/permissions')commit('SET_PERMISSIONS', response.data)return response.data}
}export default {namespaced: true,state,mutations,actions
}

import { createStore } from 'vuex'
import user from './modules/user'  // 导入user模块export default createStore({state: {userId: '',isAuthenticated: false},mutations: {setUserId(state, id) {state.userId = parseInt(id)state.isAuthenticated = !!id}},modules: {user  // 注册user模块},// 添加持久化plugins: [store => {// 初始化时从 localStorage 获取状态const userId = localStorage.getItem('userId')if (userId) {store.commit('setUserId', userId)}// 订阅 mutationstore.subscribe((mutation, state) => {if (mutation.type === 'setUserId') {localStorage.setItem('userId', state.userId)}})}]
})

这两部分代码共同构成了一个 基于 Vuex 的前端状态管理 + JWT 认证体系，主要处理用户认证、权限管理和状态持久化。以下是详细解析：

---

1. user 模块（核心功能）

作用：管理用户登录状态、令牌(Token)、权限和角色信息。

const state = {token: localStorage.getItem('token') || null,  // 从本地存储初始化Tokenuser: null,      // 用户信息permissions: [], // 权限列表role: null       // 用户角色
}

关键方法：

方法/属性	功能说明
mutations.SET_TOKEN	存储Token到Vuex和localStorage，并设置Axios全局请求头(Authorization)
mutations.CLEAR_TOKEN	退出登录时清除Token和Axios请求头
actions.login	提交登录请求，保存Token和权限到Vuex
actions.logout	清理所有用户状态（Token、用户信息、权限等）
actions.fetchPermissions	主动获取用户权限（需Token有效）

流程示例：

1. 用户登录

1. 权限控制

   • 前端根据 state.permissions 动态渲染菜单/按钮。

   • 每次API请求自动携带JWT（通过Axios拦截器）。

---

2. index.js（Vuex主仓库）

作用：全局状态管理 + 模块整合 + 持久化。

export default createStore({state: {userId: '',             // 全局用户IDisAuthenticated: false  // 认证状态},modules: {user  // 注册user模块（嵌套状态）},plugins: [ /* 持久化逻辑 */ ]
})

关键设计：

1. 模块化

   • 将用户相关状态（user模块）与全局状态分离，避免命名冲突。

   • 通过 namespaced: true 启用模块命名空间。

2. 状态持久化

   • 初始化时：从 localStorage 读取 userId 恢复登录状态。

   • 状态变化时：通过 store.subscribe 监听 setUserId 突变，自动同步到 localStorage。

3. 认证状态同步

   • isAuthenticated 由 userId 自动计算得出（!!id 转为布尔值）。