Fiber路由注册不支持直接挂权限标识，因其app.Get、app.Post等方法仅接收路径和处理函数，无参数预留传入权限码，无法像Spring Boot注解那样嵌入权限语义。
不能只靠中间件拦截路径，必须把权限标识和路由绑定起来，否则鉴权逻辑无法落地。
为什么 Fiber 的路由注册不支持直接挂权限标识
Fiber 的 app.Get、app.Post 等方法只接收路径和处理函数，没有预留参数传入权限码（如 "user:read" 或 "menu:user-manage"）。这意味着你无法像 Spring Boot 的 @PreAuthorize("hasRole('ADMIN')") 那样在声明路由时嵌入权限语义。
常见错误是试图在中间件里硬编码路径匹配：
if c.Path() == "/api/users" {
// 检查用户是否有 user:read 权限
}
这种写法导致权限逻辑和路由强耦合，新增接口就得改中间件，不可维护。
- 真实项目中接口路径可能带参数：
/api/users/:id，硬比对会失效 - 同一权限可能对应多个路径（如
GET /api/users和GET /api/users/export） - 权限标识需要可配置、可动态加载（比如从数据库或 Redis 读），不能写死
用全局映射表关联路由与权限标识
在启动时，手动建立一个 map[string][]string，把每个注册的路由路径（含 method）映射到其所需的权限标识列表。关键点在于：路径要标准化——去掉参数占位符，统一为可比对形式。
示例做法：
// 初始化权限路由映射
var routePermissionMap = make(map[string][]string)
// 封装注册函数（推荐）
func RegisterRoute(app *fiber.App, method, path string, handler fiber.Handler, perms ...string) {
// 标准化路径：/api/users/:id → /api/users/:id（保留占位符，但统一格式）
key := method + ":" + path
routePermissionMap[key] = perms
switch method {
case "GET":
app.Get(path, handler)
case "POST":
app.Post(path, handler)
}
}
// 使用
RegisterRoute(app, "GET", "/api/users", getUserHandler, "user:read")
RegisterRoute(app, "POST", "/api/users", createUserHandler, "user:create")
- 中间件中通过
c.Method() + ":" + c.Path()拼出 key，查表获取权限标识 - 注意：Fiber 的
c.Path()返回的是原始请求路径（如/api/users/123），需提前做路径归一化（例如用正则替换/\d+为:id），或改用c.Route().Path获取定义时的模板路径（v2.49+ 支持） - 避免用
map[string]string存单个权限，因为一个接口常需多个权限“与”关系（如["user:read", "dept:own"]）
中间件中做权限校验的实操要点
权限校验中间件不是简单判断“有没有权限”，而是结合用户角色、资源上下文、甚至数据归属做动态决策。比如“只能看本部门用户”就需要查询当前用户所属部门。
典型校验流程：
func AuthMiddleware() fiber.Handler {
return func(c *fiber.Ctx) error {
// 1. 解析 token，拿到用户 ID 和角色列表（假设已存入 c.Locals）
userID := c.Locals("user_id").(string)
roles := c.Locals("roles").([]string)
// 2. 获取当前路由对应的权限标识
routeKey := c.Method() + ":" + c.Route().Path
requiredPerms, ok := routePermissionMap[routeKey]
if !ok {
return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "no permission config"})
}
// 3. 查询 DB 或缓存，确认该用户是否满足 requiredPerms 中所有项
if !hasAllPermissions(userID, roles, requiredPerms) {
return c.Status(fiber.StatusForbidden).JSON(fiber.Map{"error": "insufficient permissions"})
}
return c.Next()
}
}
- 不要在中间件里重复解析 JWT；应在前置认证中间件（如
jwt.New()）中完成并注入c.Locals -
hasAllPermissions函数应支持 RBAC 模型：查角色→查角色关联的权限→比对 requiredPerms 是否全包含 - 若涉及行级权限（如“只看自己创建的数据”），需延迟到 Handler 内部做 WHERE 过滤，中间件只做粗粒度放行
- 性能敏感场景下，权限数据建议预加载进内存（如启动时全量加载角色-权限映射表），避免每次请求都查 DB
按钮级和菜单级权限怎么同步到前端
后端权限控制接口访问，但前端仍需隐藏无权操作的 UI 元素。最稳妥的方式是：登录成功后，后端返回该用户「可访问的所有权限标识」列表（如 ["user:read", "user:create", "menu:system-setting"]），前端存入 store，所有按钮和菜单用 v-if="hasPerm('user:create')" 控制显隐。
- 不要让前端猜权限——比如根据接口 403 状态码反推按钮是否显示，这有竞态和体验问题
- 菜单结构本身也应由后端返回（按角色动态生成），而不是前端写死再靠权限过滤，避免菜单和接口权限不一致
- 如果使用动态路由（如 Vue Router 的 addRoute），权限标识列表就是生成路由的唯一依据
- 注意：这个权限列表必须和服务端中间件使用的
routePermissionMap同源，否则会出现“前端显示了按钮，点击却 403”的割裂
真正难的不是写一个中间件，而是让权限标识在路由注册、中间件校验、前端展示、数据库存储这四个环节保持语义一致且可维护。一旦某处硬编码或手动同步，后续就容易漏配、错配，排查成本远高于初期多花十分钟设计映射机制。
