Django中能否基于变量实现管理器强制过滤防范数据泄露？

这个需求既不是反模式，也没有脱离Django的原生扩展能力，属于项目数据强隔离场景下非常典型的防御性编程实现，很多多租户SaaS系统都会用类似方案从ORM层避免越权数据泄露。

核心思路是通过自定义QuerySet增加数据范围校验标记，拦截无明确范围声明的查询入口，同时提供显式的范围声明方法，完全基于Django ORM的原生扩展点实现，不需要修改框架源码。

第一步：定义专用异常 #

class DataLeakError(Exception):
    """未显式声明数据查询范围，存在泄露风险时抛出"""
    pass

第二步：实现带校验逻辑的自定义QuerySet #

核心是加一个内部标记位_allow_all_data，默认关闭，只有开发者显式调用指定范围的方法时才打开标记；所有对外暴露的查询构造方法执行前先校验标记，没开就直接抛错；链式调用时要把标记位传递下去，避免合法查询被误拦。

from django.db import models

class BookQuerySet(models.QuerySet):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._allow_all_data = False

    def _check_scope(self):
        if not self._allow_all_data:
            raise DataLeakError("查询Book数据必须显式指定项目范围，禁止无范围全量查询")

    def for_project(self, project):
        """业务层最常用的按项目过滤方法，返回指定项目下的所有图书"""
        return self.all_projects().filter(project=project)

    def all_projects(self):
        """显式声明要查询全量项目数据，仅用于数据迁移、后台管理等可信场景"""
        qs = self._chain()
        qs._allow_all_data = True
        return qs

    # 重写所有需要拦截的查询入口方法，执行前先做范围校验
    def all(self):
        self._check_scope()
        return super().all()

    def filter(self, *args, **kwargs):
        self._check_scope()
        return super().filter(*args, **kwargs)

    def exclude(self, *args, **kwargs):
        self._check_scope()
        return super().exclude(*args, **kwargs)

    def only(self, *args, **kwargs):
        self._check_scope()
        return super().only(*args, **kwargs)

    def defer(self, *args, **kwargs):
        self._check_scope()
        return super().defer(*args, **kwargs)

    def values(self, *args, **kwargs):
        self._check_scope()
        return super().values(*args, **kwargs)

    def values_list(self, *args, **kwargs):
        self._check_scope()
        return super().values_list(*args, **kwargs)

    def _chain(self):
        """重写链式调用方法，传递范围许可标记，保证合法链路的链式调用正常运行"""
        qs = super()._chain()
        qs._allow_all_data = self._allow_all_data
        return qs

注意：不需要重写_fetch_all这类ORM内部执行方法，只需要拦截开发者直接调用的公开构造方法即可，最大程度降低对框架原生逻辑的侵入。

第三步：将自定义QuerySet绑定到模型 #

class Book(models.Model):
    project = models.ForeignKey("Project", on_delete=models.CASCADE)
    title = models.CharField(max_length=255)
    # 其他业务字段省略

    objects = BookQuerySet.as_manager()

绑定完成后就能完全匹配预期效果：

• 调用Book.objects.for_project(project)正常返回指定项目的图书查询集
• 调用Book.objects.all_projects()正常返回全量查询集，后续链式调用filter()、only()等方法都不会被拦截
• 直接调用Book.objects.all()、Book.objects.filter()等未声明范围的方法会直接抛出DataLeakError

• 不要留无标记的“后门”查询方法，所有需要跨项目查全量数据的场景，必须显式调用all_projects()，代码评审时重点关注这个方法的调用场景即可
• 如果有特殊豁免需求（比如超级管理员全量导出），可以用Python标准库的contextvars做上下文级别的临时豁免，不要修改全局校验逻辑
• 单元测试必须覆盖所有被拦截的方法，避免后续迭代有人误改校验逻辑导致防护失效

这个设计不属于反模式。相比“靠开发者自觉加过滤条件”“靠代码评审人工排查”的方式，这种ORM层强制校验的方案漏判率几乎为零，是数据强隔离场景下投入产出比极高的防护手段。唯一的禁忌是不要过度拦截ORM内部方法，避免破坏框架原生的关联查询、聚合查询等能力。

内容的提问来源于stack exchange，提问作者Wilco