在给某个内部管理系统做Django Admin二次开发的时候我遇到的第一道坎就是怎么拿到当前登录用户。听起来很简单不就是request.user吗但实际上Django Admin里涉及“当前用户”的场景远比想象中复杂列表页要做数据权限过滤、保存时要自动填充创建人、内联表格里要根据用户过滤可选数据、自定义表单校验时要判断角色每个场景的获取方式都不一样踩坑姿势也各不相同。这篇内容不是讲Django基础而是专门针对Django Admin站点二次开发中“获取当前登录用户”这一需求做一次系统性的梳理。适合正在做Admin定制的开发者也适合刚接触Django后台开发、被各种request传参问题折磨的同学。我会从最常见的ModelAdmin重写方法开始逐步延伸到Inline、自定义Form、模板上下文最后给出一套全局兜底方案和完整实战示例尽量做到看完了就能直接用。1. 需求先理清Django Admin里“当前用户”到底要用在哪1.1 四个高频场景很多人以为获取当前用户就是“在视图里用request.user”一旦进了Django Admin的世界事情就不一样了。Admin不是普通视图它是一套基于ModelAdmin的框架很多操作发生在表单保存、列表查询、Inline渲染等内部流程里想拿到用户身份得看你处在哪个环节。最常见的需求是数据权限过滤。比如一个订单管理后台销售只能看自己创建的订单管理员可以看全部订单。这个逻辑写在ModelAdmin.get_queryset里方法签名里带了request参数直接取request.user即可。类似的需求还有只能编辑自己负责的数据、下拉框里只显示当前用户所属部门的数据本质都是同一个模式。第二个高频场景是操作留痕。保存订单时要自动填入创建人、修改时要把操作人写入日志这类逻辑通常在save_model中实现签名同样带request很好拿。但如果你是在Model的save方法里做这些事那就麻烦了因为模型层拿不到request需要通过其他手段把当前用户传进去。第三个场景是内联表格和自定义表单。Django Admin的InlineModelAdmin在初始化formset的时候方法签名是get_formset(self, objNone, **kwargs)没有request参数。你没法直接在里面拿用户但内联表单又经常需要根据当前用户过滤可选外键数据。这个不解决功能就到瓶颈。第四个场景是模板定制。自定义Admin模板时比如重写change_form.html、base_site.html想在页面上显示“当前登录人某某”这时候需要用到模板上下文中的user变量。Django Admin默认传递了request所以直接用{{ request.user }}就行但如果你用了自定义的context处理容易把user丢掉。1.2 获取用户的三种层级根据使用位置的不同获取当前用户大致分三个层级。第一层级是函数参数直接传递。Django Admin在核心入口方法中都把request作为参数传进来了你只需要在方法签名里接收它然后取request.user。这是官方推荐、也是最符合框架设计的方式适合get_queryset、save_model、delete_model、get_form等场景。第二层级是模板上下文和中间件。模板里可以直接访问{{ request.user }}中间件则可以在每个请求进入时把user保存到全局或线程局部变量供后端任意位置读取。这种方式解决的是那些“拿不到request”的场合比如Model的信号处理器、自定义Form的clean方法、Celery任务等。第三层级是偏门的全局状态。通过threading.local、上下文变量或者全局设置等方式在请求开始处缓存当前用户使用时直接取。这个方法简单粗暴但稍不注意就会出并发串号问题属于“兜底方案”。我在实际项目中一般是这么分配的凡是能通过request参数拿到的场景一律用第一层级把代码写得干净可读确实拿不到request的地方比如Inline的get_formset、表单验证中需要用户身份时再考虑第二、三层级。这个思路后面会详细展开。2. 正统姿势在ModelAdmin方法里直接用request.user2.1 get_queryset做数据权限过滤先看最典型的场景数据权限隔离。假设有个订单表普通用户登录后台后只应该看到自己创建的订单管理员看全部。在ModelAdmin里重写get_queryset就够了。from django.contrib import admin from .models import Order admin.register(Order) class OrderAdmin(admin.ModelAdmin): def get_queryset(self, request): qs super().get_queryset(request) if request.user.is_superuser: return qs return qs.filter(creatorrequest.user)这段代码很简单但有几个点容易踩坑。一是不要返回None很多人写了判断之后忘了在分支末尾返回qs结果列表页直接报错。二是注意用request.user.is_superuser而不是request.user.is_staff因为所有能进后台的都是staff区分管理员和普通用户得依据角色字段或is_superuser。三是如果模型里用的是外键而且定义了related_name过滤时要和related_name保持一致。顺带提醒一下get_queryset不仅在列表页生效在添加和编辑页面选择外键时也会生效——因为它影响的是整个Admin的数据查询范围。也就是说一个普通用户在更换外键字段的下拉框里能看到的可选数据也会被这个过滤条件约束这是很多人没预料到的“连带效果”。2.2 save_model自动填充操作人另一个常见需求是自动填充创建人字段。比如订单模型里有个creator外键保存时自动填入当前用户而不是让用户在前台去选这样既不安全也不友好。class OrderAdmin(admin.ModelAdmin): def save_model(self, request, obj, form, change): if not change: obj.creator request.user super().save_model(request, obj, form, change)这里通过change参数区分新增和修改。新增时填creator修改时不覆盖原有的creator否则每次编辑订单创建人都会被改掉。如果想记录最后修改人可以再添一个updater字段在change为True时也赋值。一个容易忽略的点是如果后续还有代码通过obj.save()方式绕过save_model直接修改订单创建人字段就不会被自动填充。比如你在某个Action里批量更新订单状态走的不是Admin的保存流程那这些逻辑就不会生效需要你在Action里单独维护用户信息。2.3 其他方法签名里的request除了get_queryset和save_modelModelAdmin还有很多方法签名里带request可以随时取用户。我平时用得比较多的有这些delete_model(self, request, obj)删除时记录操作人。get_form(self, request, objNone, **kwargs)根据用户角色动态调整表单字段比如普通用户不显示“是否置顶”选项。get_list_display(self, request)根据用户角色动态决定列表显示哪些列。get_actions(self, request)根据用户角色屏蔽某些批量操作。changelist_view(self, request, extra_contextNone)给列表页上下文额外塞数据比如当前用户可见的统计数字。response_change(self, request, obj)保存成功后跳转前插一脚。这些方法的共同点是request都是第一个或第二个参数位置很规矩用起来没有任何心理负担。我在做权限控制的时候经常把get_list_display和get_queryset搭配使用普通用户列表只显示和自己相关的列管理员显示全部列后端控制而不是前端隐藏避免信息泄露。3. 边角补位Inline、自定义表单和模板里的用户3.1 InlineModelAdmin里怎么拿用户Inline是Django Admin里让人又爱又恨的东西。爱是因为它能在父对象编辑页内直接管理关联子对象很高效恨是因为它的方法签名设计得早很多地方没有暴露request。get_formset(self, objNone, **kwargs)这个方法就没有request参数。如果你负责的Inline要过滤外键选项比如订单内联了订单明细明细里的产品字段要根据当前用户的权限范围过滤怎么办常规思路有两种。一种是把request保存到中间件或线程局部变量中在get_formset里取出来用这个方案后面详细讲。另一种是重写get_formset并利用self.admin_site但admin_site里也不直接存当前request。还有一个更朴素的办法在Inline的formfield_for_foreignkey方法中处理。这个方法的签名是formfield_for_foreignkey(self, db_field, request, **kwargs)request是可以拿到的。虽然它不是在get_formset里直接干预整个formset但对外键字段级别的过滤够用了。class OrderItemInline(admin.TabularInline): model OrderItem def formfield_for_foreignkey(self, db_field, request, **kwargs): if db_field.name product: if not request.user.is_superuser: kwargs[queryset] Product.objects.filter(ownerrequest.user) return super().formfield_for_foreignkey(db_field, request, **kwargs)这个方法也能在普通ModelAdmin里用效果是对应表单字段的下拉选项按当前用户过滤是Admin里做外键范围控制的官方做法比在Form里重写字段的queryset要省事得多。3.2 自定义Form中获取当前用户的偏门方案有些场景要写自定义Form做校验比如某个字段的合法性判断依赖当前用户的角色。ModelAdmin的get_form可以返回一个自定义的ModelForm但这个Form在实例化时并不会自动拿到request。有个取巧的办法值得推荐在ModelAdmin的get_form中把request作为实例属性塞进form实例里。class OrderForm(forms.ModelForm): class Meta: model Order fields __all__ def clean_order_no(self): order_no self.cleaned_data[order_no] # 这里需要判断当前用户假设已经在实例属性里 user getattr(self, current_user, None) if user and not user.is_superuser: if Order.objects.filter(order_noorder_no).exists(): raise forms.ValidationError(订单号已存在) return order_no class OrderAdmin(admin.ModelAdmin): form OrderForm def get_form(self, request, objNone, **kwargs): form_class super().get_form(request, obj, **kwargs) original_init form_class.__init__ def new_init(form_self, *args, **kwargs): original_init(form_self, *args, **kwargs) form_self.current_user request.user form_class.__init__ new_init return form_class这段代码的核心思路是动态包装__init__方法把请求用户挂到form实例上。类级别的form对象会被多个请求共享不能在类属性上直接放user必须放到实例上才安全。这个做法稍微有点hack的味道但工作量小、逻辑清晰在项目里用起来很稳。还有一种更清爽的方案构造一个混入Mixin让Form在接受request参数时自动设置current_user不过这需要配合自定义的form实例化流程。如果只是Admin后台用上面的包装方案完全够用。3.3 模板上下文里的userDjango Admin的模板上下文策略和普通视图不一样。默认情况下Admin的若干视图在渲染模板时会通过context_processors把request注入到上下文中因此模板里可以直接用{{ request.user }}。在重写base_site.html时我经常在顶栏右侧显示当前登录人直接用{{ request.user.username }}如果用户未登录则显示“未登录”。div classuser-info {% if request.user.is_authenticated %} 欢迎{{ request.user.username }}{% if request.user.is_superuser %}管理员{% else %}普通用户{% endif %} {% else %} 未登录 {% endif %} /div但这里有一个隐藏坑不是所有Admin模板都自动带有request。当你通过extra_context传了自定义context或者在某些特殊视图如Admin站点的logout页面里可能拿不到request。这时候要么改用全局上下文处理器要么在视图里显式往context里塞用户信息。另外在change_form.html里做条件显示时比如“只有创建人本人才能看到关闭按钮”模板里有original变量可以拿到当前编辑的对象你可以直接判断request.user original.creator。这种模板层的权限控制适合做UI层面的提示真正的权限控制还是要在后端做不然别人直接构造请求就绕过限制了。4. 兜底方案用中间件配合线程局部变量全局保存用户4.1 为什么需要兜底方案很多场景是标准手段覆盖不了的。最典型的是在Model的save方法、post_save信号处理器、Celery任务、或者其他非视图层代码里需要知道当前请求用户是谁。一个常见业务订单保存后自动发站内信通知对象是订单的创建人。通过信号能拿到订单实例能拿到创建人但如果要反向操作——比如根据“当前操作者”来判断要不要发通知——信号里没有request无从知晓当前操作者。这时候就需要一个全局的“当前用户”存取机制。我的选择是中间件加线程局部变量。4.2 实现细节与代码先写一个线程局部变量存储模块# utils/user_context.py import threading _local threading.local() def get_current_user(): return getattr(_local, user, None) def set_current_user(user): _local.user user def clear_current_user(): if hasattr(_local, user): del _local.user然后编写中间件在每个请求进来时保存用户请求结束时清理# middleware/user_context_middleware.py from utils.user_context import set_current_user, clear_current_user class UserContextMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): set_current_user(request.user) try: response self.get_response(request) finally: clear_current_user() return response注册中间件时注意顺序务必放在AuthenticationMiddleware之后确保request.user已经被赋值。如果不放心可以在set之前先判断request.user.is_authenticated。之后在任何地方都能用了from utils.user_context import get_current_user class Order(models.Model): # ... def save(self, *args, **kwargs): user get_current_user() if user and not self.creator_id: self.creator user super().save(*args, **kwargs)很多场景下这比到处传request干净得多。比如在Inline里虽然get_formset没有request参数但通过get_current_user()可以曲线解决在Form的clean方法里也能直接拿到当前用户省去上一节提到的动态包装__init__技巧。4.3 线程复用的坑线程局部方案最大的坑就是线程复用。生产环境通常开启多线程一个线程处理完请求A后下一个请求B可能复用同一个线程。如果请求结束时没有清理_thread_localB请求就会拿到A请求的用户造成严重的数据错乱。这就是为什么我在中间件里用try...finally保证清理一定执行的原因。另外在单元测试里也要特别注意测试环境如果是用Django的TestClient模拟请求中间件会正常执行但如果是直接调用Model.save()做单元测试线程局部变量里的user可能是上一次测试残留的务必在setUp里主动清理。还有一点Celery任务默认不经过WSGI中间件如果在异步任务里要获取用户靠这个方案是拿不到的。我通常的做法是在任务发起的入口把用户ID作为参数传给任务任务内部再查一次数据库不依赖线程局部变量。基于这些经验我对这个方案的使用原则是能不用就不用用了就必须配套清理机制和测试约束。它适合做“锦上添花”的便捷工具不建议作为核心权限判断的唯一依据。5. 实战排查常见报错和诡异现象5.1 AnonymousUser问题表现代码里明明登录了但获取到的用户是AnonymousUser。排查思路是否拿错了位置。常见原因是自定义Form在实例化时没有拿到request而你在Form里用request.user时RuntimeError或拿到匿名用户。另一个原因是中间件注册顺序错误在AuthenticationMiddleware执行之前就访问user。解决方案优先确保通过参数进入的地方都接收requestForm里用线程局部变量取中间件顺序调整确认无误。我在项目里遇到过最隐蔽的情况是重写了ModelAdmin.get_form但把原方法的返回类丢了导致Form实例化时根本没走Admin的上下文。5.2 保存时创建人被覆盖表现新增数据时创建人字段总是空的或者编辑数据时创建人变成了修改人。排查思路先确认是不是所有写操作都走了save_model。如果Order物件在Admin里修改后某个信号里又执行了另一次save那次save没有经过Admin的save_model创建人字段就会被覆盖。还有可能是模型层的save里做了自动填充同时Admin的save_model也做了填充两次赋值把值覆盖掉了。解决方案统一一个填充入口。我习惯是前台表单提交的数据在ModelAdmin.save_model里填充系统内部脚本、批量操作在模型层save方法里使用线程局部变量填充。两处同时存在时要做好优先级判断if not self.creator_id这种保护逻辑很关键。5.3 并发下的串号问题表现A用户创建的订单B用户在后台却看到了创建人显示为B。排查思路首先怀疑线程局部变量没清理其次是缓存。缓存问题相对少见多数还是线程复用引起的。解决方案严格清理中间件中的线程局部变量遇到可疑情况在中间件开始处强制执行一次clear。我写UserContextMiddleware时在set之前先clear一次然后用try...finally包住整个请求处理过程双保险。5.4 测试环境拿不到用户表现写单元测试时直接调用某个服务函数函数内部get_current_user()返回None。排查思路单元测试没有走WSGI请求链路中间件不会执行自然没有用户上下文。解决方案测试里手动set当前用户。from utils.user_context import set_current_user, clear_current_user from django.test import TestCase class OrderServiceTest(TestCase): def setUp(self): self.user User.objects.create_user(tester, tt.com, pass) set_current_user(self.user) def tearDown(self): clear_current_user()这样可以保持服务层代码不变同时在测试中模拟用户上下文非常实用。6. 完整示例一个带数据权限的订单后台6.1 模型设计把前面提到的所有知识点揉进一个完整案例里假如有一个订单系统包含订单主表和订单明细表。模型如下# models.py from django.db import models from django.contrib.auth.models import User class Customer(models.Model): name models.CharField(客户名称, max_length100) owner models.ForeignKey(User, verbose_name归属业务员, on_deletemodels.CASCADE) created_at models.DateTimeField(auto_now_addTrue) class Order(models.Model): order_no models.CharField(订单号, max_length20, uniqueTrue) customer models.ForeignKey(Customer, verbose_name客户, on_deletemodels.CASCADE) creator models.ForeignKey(User, verbose_name创建人, on_deletemodels.SET_NULL, nullTrue) amount models.DecimalField(订单金额, max_digits10, decimal_places2) status models.CharField(状态, max_length10, defaultpending) created_at models.DateTimeField(auto_now_addTrue) class OrderItem(models.Model): order models.ForeignKey(Order, verbose_name订单, on_deletemodels.CASCADE, related_nameitems) product_name models.CharField(产品名, max_length100) price models.DecimalField(单价, max_digits8, decimal_places2) qty models.IntegerField(数量)需求是普通用户只能看到自己创建的订单。添加订单时客户下拉框只能选择自己名下的客户。添加订单时自动填充创建人。订单明细里每一行的产品名和价格不允许修改只能新增。后台顶栏显示当前登录用户。6.2 自定义ModelAdmin实现# admin.py from django.contrib import admin from .models import Order, OrderItem, Customer class OrderItemInline(admin.TabularInline): model OrderItem extra 0 readonly_fields (product_name, price) def has_change_permission(self, request, objNone): # 明细行允许新增但不允许修改已有行 return False class OrderAdmin(admin.ModelAdmin): list_display (order_no, customer, creator, amount, status, created_at) list_filter (status, created_at) inlines [OrderItemInline] readonly_fields (creator,) list_select_related (customer, creator) def get_queryset(self, request): qs super().get_queryset(request) if request.user.is_superuser: return qs return qs.filter(creatorrequest.user) def save_model(self, request, obj, form, change): if not change: obj.creator request.user super().save_model(request, obj, form, change) def formfield_for_foreignkey(self, db_field, request, **kwargs): if db_field.name customer and not request.user.is_superuser: kwargs[queryset] Customer.objects.filter(ownerrequest.user) return super().formfield_for_foreignkey(db_field, request, **kwargs)有几个细节补充说明将creator字段设为readonly防止普通用户在页面上篡改创建人。查询时用list_select_related做外键预取列表页加载速度会明显提升尤其是在数据量大的时候。formfield_for_foreignkey对客户做了过滤用户只能选择自己名下的客户这个过滤会同时作用于添加和编辑页面。6.3 内联与表单的处理OrderItemInline里我禁用了对已有明细的修改但允许新增。普通用户进入订单编辑页时内联明细的权限和主表是一致的因为内联通过has_change_permission控制默认继承父Admin的逻辑。如果你希望内联的新增明细也自动记录属于当前用户可以在内联里通过formset的save方法处理。但更轻量的做法是配合线程局部变量在模型层save里判断class OrderItem(models.Model): # ... def save(self, *args, **kwargs): from utils.user_context import get_current_user user get_current_user() if user and not self.pk: self.created_by user super().save(*args, **kwargs)虽然这是个简化示例但结构上已经覆盖了数据权限、外键过滤、自动填充、模板定制的主要知识点上线前记得再做一次权限自测。我自己在类似项目中总结下来Django Admin获取当前用户这件事思路比代码更重要。先把场景归类再决定用哪种方式获取不追求一个万能方案而是让每种方案在合适的场景里发挥作用。比如能拿request的地方就不要用线程变量避免不必要的并发风险拿不到request的地方再用中间件方案兜底同时做好线程清理。最后再分享一个实战中的小技巧在调试这种和用户身份相关的问题时我习惯在中间件里临时加一行日志把每次请求的user和访问路径打出来能看到用户上下文到底是什么时候丢的。这个方法虽然土但定位问题比翻代码快得多。