初学者应先用五张表（users、roles、permissions、user_roles、role_permissions）搭建权限系统，确保字段命名统一、外键完整、permission_code采用“资源:操作”短字符串格式；避免三张表加逗号/JSON字段的反模式，因其导致查询无索引、修改易错、无法支持多对多等核心需求。
直接说结论：初学者不用追求“完美范式”，先用五张表把 users、roles、permissions、user_roles、role_permissions 搭起来，重点是字段命名统一、外键约束写全、权限码（permission_code）用短字符串定义（如 user:read），别一上来就加层级、状态、租户字段。
为什么不用三张表硬凑？
常见误区是只建 users、roles、permissions，然后在 users 表里加个 role_ids 字段存逗号分隔的 ID，或在 roles 表里加个 perm_codes 字段存 JSON。这会导致：
• 查询用户所有权限时必须用 FIND_IN_SET 或 JSON_CONTAINS，无法走索引
• 修改某个角色的权限要字符串切割+拼接，极易出错
• 无法实现“一个用户多个角色”或“一个权限被多个角色复用”的基本需求
• 后续加审计、禁用某条权限、查谁有某权限等操作全部变棘手
permission_code 字段怎么定才不翻车？
权限码不是随便起名，它会直接用于应用层校验（比如 @PreAuthorize("hasAuthority('order:delete')")），所以必须满足：
• 全局唯一，且语义清晰 —— 推荐格式 资源:操作，如 dashboard:view、product:export
• 不含空格、斜杠、中文，只用小写字母、数字、冒号、下划线
• 长度控制在 32 字符内，避免 MySQL VARCHAR 过长影响索引效率
• 不要带版本号或环境标识（如 user:read:v2），升级靠新增权限项，而不是改旧码
• 如果需要区分菜单/按钮/API，可加 type 字段（TINYINT），但别塞进 permission_code 里
外键和索引最容易漏的两处
新手建完表常忘了这两步，上线后 JOIN 查询慢、数据不一致风险高：
• user_roles 和 role_permissions 必须设联合主键（(user_id, role_id) / (role_id, permission_id)），否则同一关系可能重复插入
• 在关联字段上补索引：
– user_roles.role_id 要索引（查某角色有哪些用户）
– role_permissions.permission_id 要索引（查某权限被哪些角色使用）
• permissions.permission_code 必须加 UNIQUE 约束，防止不同 ID 却有相同权限码
最常被忽略的是：权限数据一旦写入，后续几乎只读；但角色分配（user_roles）和权限绑定（role_permissions）会高频变更。设计时就要想好——这些中间表要不要软删除？要不要记录操作人？要不要加 created_at？别等第一版上线后再补，那时数据量上来了，加字段成本极高。
