基础权限控制应避免硬编码角色字符串，推荐用枚举封装权限标识；权限校验应统一收敛至Service层或AOP注解驱动，DAO层仅负责数据查询，严禁嵌入角色条件；同时需确保代码与数据库权限配置同步更新。
Java 里做基础权限控制，不一定要上 Spring Security；用最朴素的 if + switch + 角色字段就能跑通核心逻辑，关键在于权限判定的时机、粒度和扩展性设计。
权限判断该放在 Controller 还是 Service 层？
多数人直接在 @PostMapping 方法里写 if (user.getRole().equals("ADMIN"))，这看似快，但很快会失控：同一个角色逻辑散落在十几个接口里，改个权限规则要翻遍所有 Controller。
更稳妥的做法是把权限检查收敛到统一入口：
- Controller 层只做「请求合法性校验」（如参数非空、ID 格式），不碰权限
- Service 方法签名明确声明所需权限，例如：
void deleteOrder(Long orderId, String requiredRole) - 真正判断交给一个轻量工具类，比如
PermissionChecker.check(user, "ORDER_DELETE")，背后查的是预定义的权限码映射表，不是硬编码角色名
用字符串比对角色还是用枚举管理权限？
用 "ADMIN"、"USER" 这类字符串做判断，开发时爽，上线后容易出错：拼错大小写、多空格、前后有不可见字符，都会导致权限失效且难排查。
推荐用枚举封装权限标识：
public enum Permission {
ORDER_READ,
ORDER_WRITE,
USER_MANAGE,
SYSTEM_CONFIG
}
再配合用户实体里的 Set 字段或通过 getPermissions() 方法动态加载。这样 IDE 能自动补全、编译期报错，也方便后续对接 RBAC 数据库表。
为什么不能直接在 DAO 层加 WHERE role = 'ADMIN'？
有人为“省事”，在 MyBatis 的 里直接拼 AND user_role = #{currentUser.role} —— 这等于把权限逻辑下沉到数据层，后果很实际
：
- SQL 复杂度飙升：不同角色看到的字段、排序、分页逻辑都不同，一个查询 XML 很快变成 200 行嵌套
- 缓存失效：同一 SQL 因角色不同返回不同结果，但 MyBatis 一级缓存按 SQL 和参数哈希，导致缓存污染
- 测试困难：DAO 单元测试无法模拟不同角色上下文，只能靠集成测试兜底
正确的做法是：DAO 只负责“查数据”，权限过滤由 Service 层调用后做内存级裁剪，或用 MyBatis 的
如何避免 if (role.equals("ADMIN")) 写十遍？
最直接的解法是抽一个静态工具方法：
public class PermissionUtil {
public static boolean hasRole(User user, String... roles) {
return user != null && Arrays.asList(roles).contains(user.getRole());
}
}
但更值得花十分钟做的是引入注解驱动：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RequireRole {
String[] value() default {};
}
再配一个 AOP 切面，在方法执行前读取注解、校验当前用户角色。这样 Controller 里就只剩干净的业务逻辑：
@PostMapping("/orders")
@RequireRole({"ADMIN", "OPS"})
public Result createOrder(@RequestBody OrderDto dto) { ... }
注意：AOP 方式要求目标方法不能是 private 或 final，且 Spring 管理的 Bean 才能生效；如果项目没用 Spring，就老实用工具类 + 显式调用。
权限控制最容易被忽略的不是“怎么写”，而是“谁来维护权限变更”——比如运营提需求说“客服也能导出订单”，你改完代码，却忘了同步更新数据库里客服角色对应的权限码集合，线上就会出现“代码允许但数据库拒绝”的静默失败。这类问题不会报错，只会让功能看起来“有时灵有时不灵”。
