线程池层不适合装饰器式权限校验，因为Runnable/Callable是匿名执行单元，无调用上下文和可装饰的静态结构；权限校验必须前置到任务封装层，通过工厂或包装类将校验逻辑嵌入任务内部。
不能直接在线程池（如 ThreadPoolExecutor）层面用装饰器做任务级权限校验——因为 Java 的装饰器（如 Spring AOP）或 Python 的函数装饰器，作用对象是“方法调用”，而线程池提交的是 Runnable 或 Callable 实例，它们是匿名/无签名的执行单元，不携带调用上下文（如用户身份、请求来源），也没有可被装饰的函数名和参数结构。
为什么线程池层不适合放装饰器式权限校验
线程池只负责调度和执行任务，本身不感知业务语义。你传给 executor.submit(runnable) 的是一个已经构造好的对象，它的 run() 方法里若没做鉴权，外部装饰器根本无法介入。装饰器在 Python 中修饰的是函数定义，在 Java 中修饰的是方法声明，而线程池任务往往是动态创建、延迟执行的闭包或 lambda，不具备可装饰的静态结构。
真正可行的权限校验位置：任务封装层
权限校验必须发生在任务被创建时、提交前，把校验逻辑“包进任务内部”，而不是试图装饰线程池本身。推荐做法是：用一个带上下文的任务工厂，生成已包裹权限检查的可执行对象。
- Python 示例（推荐）：封装一个安全任务构造器
def make_secured_task(func, user, required_role):
def secured_run():
if not user.has_role(required_role):
raise PermissionError(f"用户 {user.id} 缺少角色 {required_role}")
return func()
return secured_run
# 提交前完成校验逻辑注入
task = make_secured_task(send_report, current_user, "report_viewer")
executor.submit(task)
- Java 示例（基于 Runnable 包装）：在提交前 wrap
public class SecuredTask implements Runnable {
private final Runnable delegate;
private final User user;
private final String requiredRole;
public SecuredTask(Runnable delegate, User user, String requiredRole) {
this.delegate = delegate;
this.user = user;
this.requiredRole = requiredRole;
}
@Override
public void run() {
if (!user.hasRole(requiredRole)) {
throw new SecurityException("Access denied");
}
delegate.run();
}
}
// 使用：
executor.submit(new SecuredTask(() -> doHeavyExport(), currentUser, "exporter"));
避免常见误区
- 不要试图给
ThreadPoolExecutor子类加 @PreAuthorize —— Spring 的 AOP 不会拦截submit()调用，更不会自动代理你传进去的Runnable - 不要在线程池的
beforeExecute中查用户：此时没有调用栈信息，无法知道这个任务是谁、为什么提交的 - 不要把权限判断写在
afterExecute：校验必须前置，失败就该拒绝执行，而非执行完再报错
如果必须统一管控，用任务拦截器模式
可在任务提交入口处统一包装，例如自定义一个 SecuredExecutor：
- 重载
submit(Runnable)，内部先校验再委托给原 executor - 要求所有任务实现
SecuredTask接口，暴露getRequiredPermission() - 校验逻辑集中，但前提是任务对象能携带权限元数据 —— 这本质上仍是“任务封装”，不是装饰器语法糖
