门禁访问控制应用权限设计疑问：代码或MySQL设置哪种更简便？

嘿，这个问题我碰到过好多次了，尤其是在这种角色少、权限规则明确的小型应用里，咱们一步步来捋，给你最省心的方案。

你的场景非常清晰：仅2种固定角色，权限逻辑简单且不需要频繁调整。所以核心目标就是用最少的代码/数据库改动实现可靠的权限控制。

方案1：代码中硬编码权限（强烈推荐！） #

这绝对是你当前场景下最简单的实现方式，因为角色和权限逻辑完全固定，没必要引入数据库的额外复杂度。

优点： #

• 零额外数据库表，不用写权限查询的SQL，省事儿
• 逻辑直观，调试起来也方便
• 部署简单，不需要额外的数据库迁移操作

实现思路： #

1. 先在用户表（比如users）里加一个role字段，用ENUM('保安', '主管')类型，用来存储用户的角色。
2. 在后端接口的入口处（比如拦截器、装饰器，或者接口开头）做角色判断：
   • 如果是「保安」角色，只允许执行**查看（GET访客列表/详情）和添加（POST访客）**的操作
   • 如果是「主管」角色，直接放行所有CRUD操作（GET/POST/PUT/DELETE）

举个Python Flask的伪代码例子（其他语言逻辑完全类似）：

from flask import current_user, jsonify
from functools import wraps

# 权限校验装饰器
def require_permission(allowed_actions):
    def decorator(f):
        @wraps(f)
        def wrapped(*args, **kwargs):
            user_role = current_user.role
            # 保安只能做查看和添加操作
            if user_role == '保安':
                if allowed_actions not in ['view', 'add']:
                    return jsonify({"msg": "你没有权限执行此操作"}), 403
            # 主管默认拥有全权限，未知角色直接拦截
            elif user_role != '主管':
                return jsonify({"msg": "未知角色"}), 403
            return f(*args, **kwargs)
        return wrapped
    return decorator

# 查看访客列表接口
@app.route('/visitors', methods=['GET'])
@require_permission('view')
def get_visitors():
    # 业务逻辑：从数据库查询访客列表
    return jsonify({"visitors": [...]})

# 添加访客接口
@app.route('/visitors', methods=['POST'])
@require_permission('add')
def add_visitor():
    # 业务逻辑：接收前端参数，插入数据库
    return jsonify({"msg": "添加成功"}), 201

# 删除访客接口（仅主管可访问）
@app.route('/visitors/<int:visitor_id>', methods=['DELETE'])
@require_permission('delete')
def delete_visitor(visitor_id):
    # 业务逻辑：删除指定访客记录
    return jsonify({"msg": "删除成功"}), 200

关键注意点： #

前端可以根据角色隐藏/显示按钮（比如不给保安显示删除按钮），但一定要在后端做权限校验——前端的限制只是交互优化，用户完全可以通过直接调用接口绕过前端限制，后端校验才是安全的核心。

方案2：MySQL中存储权限（不推荐当前场景） #

这种方式适合角色多、权限规则经常变动的场景，比如以后要加「经理」「行政」等角色，或者需要动态调整某个角色的权限。

实现思路： #

需要额外建3张表：

• roles：存储角色（id, role_name）
• permissions：存储权限项（id, permission_name，比如'view_visitor', 'add_visitor', 'edit_visitor', 'delete_visitor'）
• role_permissions：关联角色和权限（role_id, permission_id）

用户登录时，查询该角色对应的所有权限并存在会话中，接口调用时检查当前操作是否在权限列表中。

缺点： #

• 多建3张表，增加数据库复杂度
• 需要写权限查询、关联的SQL，代码量更多
• 对于你现在2种固定角色的场景，完全是过度设计，没必要

就你的需求而言，代码中硬编码权限是最优解——既满足需求，又把复杂度降到最低，后期如果真的需要扩展角色或权限，再迁移到数据库存储的方案也不迟。

内容的提问来源于stack exchange，提问作者M.Gumede