咨询：Django模型层行级权限的无依赖实现方案

针对你不想依赖手动调用for_user()、不想使用threadlocal的需求，以下是几种可靠的实现思路：

1. 视图混合类+管理器自动过滤 #

通过视图混合类在请求处理前后自动给模型管理器注入/清理当前用户，管理器的get_queryset方法自动应用过滤规则，无需手动调用过滤方法。

# 自定义模型管理器
class EntryManager(models.Manager):
    def __init__(self):
        super().__init__()
        self._current_user = None

    def set_current_user(self, user):
        self._current_user = user

    def get_queryset(self):
        queryset = super().get_queryset()
        # 仅在有用户且非超级管理员时过滤
        if self._current_user is not None and not self._current_user.is_superuser:
            return queryset.filter(owner=self._current_user)
        return queryset

# 视图混合类，用于自动注入用户
class UserFilterMixin:
    def dispatch(self, request, *args, **kwargs):
        # 给目标模型管理器设置当前用户
        Entry.objects.set_current_user(request.user)
        try:
            return super().dispatch(request, *args, **kwargs)
        finally:
            # 请求结束后重置用户，避免线程污染
            Entry.objects.set_current_user(None)

# 使用示例：继承混合类的视图
class EntryListView(UserFilterMixin, ListView):
    model = Entry

这种方式对业务代码侵入小，视图层只需继承混合类即可自动生效，同时避免了全局状态污染。但仅对通过该视图发起的查询生效，命令行或异步任务中需手动设置用户或跳过过滤。

2. 上下文管理器实现查询范围控制 #

通过上下文管理器包裹查询逻辑，在上下文内自动注入用户，管理器自动应用过滤规则，适用于视图、序列化器等任意需要查询的场景。

from contextlib import contextmanager

class EntryManager(models.Manager):
    _current_user = None

    @classmethod
    @contextmanager
    def user_scope(cls, user):
        cls._current_user = user
        try:
            yield
        finally:
            cls._current_user = None

    def get_queryset(self):
        queryset = super().get_queryset()
        if cls._current_user is not None and not cls._current_user.is_superuser:
            return queryset.filter(owner=cls._current_user)
        return queryset

# 使用示例：在视图中包裹查询逻辑
def entry_list(request):
    with EntryManager.user_scope(request.user):
        # 这里的Entry.objects.all()会自动过滤当前用户的数据
        entries = Entry.objects.all()
        return render(request, 'entry/list.html', {'entries': entries})

这种方式灵活性更高，可按需在代码块中启用过滤，同样能避免手动调用过滤方法，且上下文结束后自动清理状态，线程安全性有保障。

3. 请求ID映射+查询集自动过滤 #

借助中间件生成请求唯一标识，将用户与请求ID绑定存储，自定义查询集在初始化时自动根据当前请求ID获取用户并应用过滤，完全无需手动干预。

import threading
from django.db.models import Q

# 线程安全的存储容器，用于关联请求ID和用户
_request_storage = threading.local()

class RequestBindMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # 生成请求唯一标识（简化使用线程ID，生产环境可替换为UUID）
        request.rid = threading.get_ident()
        _request_storage.current_rid = request.rid
        # 初始化用户映射字典（避免线程间干扰）
        if not hasattr(_request_storage, 'user_map'):
            _request_storage.user_map = {}
        _request_storage.user_map[request.rid] = request.user

        response = self.get_response(request)

        # 请求结束后清理用户映射，避免内存泄漏
        del _request_storage.user_map[request.rid]
        return response

class EntryQuerySet(models.QuerySet):
    def __init__(self, model=None, query=None, using=None, hints=None):
        super().__init__(model, query, using, hints)
        self._apply_user_filter()

    def _apply_user_filter(self):
        try:
            current_rid = _request_storage.current_rid
            user = _request_storage.user_map.get(current_rid)
            if user and not user.is_superuser:
                self.query.add_q(Q(owner=user))
        except AttributeError:
            # 非请求上下文（如命令行、任务队列），不执行过滤
            pass

class EntryManager(models.Manager):
    def get_queryset(self):
        return EntryQuerySet(self.model, using=self._db)

这种方案实现了完全自动化的过滤，无需业务代码做任何额外操作，但需要注意请求ID的唯一性（避免异步场景下的冲突），以及及时清理用户映射防止内存泄漏。

关于你提到的Laravel与Django设计理念差异：Django的模型层设计为无状态、与请求上下文解耦，是为了让模型能在命令行、异步任务、测试等非HTTP场景下复用；而Laravel更偏向请求驱动的设计，允许全局访问Request。如果要在Django中实现类似Laravel的全局用户访问，需要接受这种设计带来的上下文依赖限制，上述方案已经在遵循Django设计原则的前提下，尽可能减少了手动操作的成本。

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