直接继承多个Mixin会引发MRO冲突，因为Python按继承顺序线性查找同名方法，靠前的Mixin方法被优先调用并屏蔽后续同名实现，导致后定义Mixin的逻辑（如权限校验）覆盖或跳过前者的逻辑，而非叠加执行。
为什么直接继承多个Mixin会引发方法解析顺序（MRO）冲突？
当多个Mixin都重写了 dispatch、get_context_data 或 form_valid 等关键方法时，Python 的 MRO 会按继承顺序线性查找，但若两个Mixin都试图在同一点“插入逻辑”，后定义的Mixin会完全覆盖前者的逻辑，而非叠加——比如 LoginRequiredMixin 和自定义的 PermissionCheckMixin 都在 dispatch 中做校验，后者可能跳过登录检查。
- 务必让所有Mixin继承自
object（不要继承View），避免与Django基类产生意外的MRO交叉 - 在Mixin中优先使用
super().method_name()而非硬编码调用，确保链式调用能延续 - 对需前置执行的逻辑（如权限校验），把
super().dispatch()放在最后；需后置执行的（如日志记录），放在最前
如何安全地复用 get_context_data 并避免键名覆盖？
多个Mixin各自往上下文中注入数据时，若都直接写 context['user_profile'] = ...，后加载的Mixin会覆盖前面的值，且无法感知冲突。
- 统一用
context.setdefault('key', value)替代context['key'] = value，避免无意覆盖 - 为每个Mixin生成命名空间化的键名，例如
context['mixin_sidebar_items'] = [...]，而非泛用sidebar - 若必须合并同类数据（如多个Mixin都要加
extra_js），改用列表追加：context.setdefault('extra_js', []).extend(['a.js', 'b.js'])
在 CreateView / UpdateView 中扩展表单逻辑时，哪些地方容易漏掉 super()？
常见错误是在重写 form_valid 时忘记调用 super().form_valid(form)，导致对象没保存、重定向失效或信号未触发。
-
form_valid必须返回super().form_valid(form)的结果（通常是HttpResponseRedirect），不能只做处理就 return None -
get_form_kwargs中若修改了kwargs字典，记得 return 它，否则父类拿不到更新后的参数 - 若在
form_valid中手动调用form.save()，要确认是否传入commit=False，否则可能绕过form_valid默认的保存流程
Django 4.2+ 中 UserPassesTestMixin 与自定义Mixin组合时要注意什么？
从Django 4.2起，UserPassesTestMixin 的 test_func 返回 False 时默认重定向到 login_url，但如果前面还有其他Mixin（比如 StaffRequiredMixin）也做了重定向，可能触发重复跳转或 Http404 被吞掉。
立即学习“Python免费学习笔记（深入）”；
- 始终显式设置
raise_exception = True（配合PermissionDenied异常），再用全局handler403统一处理，比依赖重定向更可控 - 多个权限Mixin串联时，用
and合并判断逻辑，而不是堆叠多个Mixin——例如在test_func里同时检查user.is_staff和user.has_perm('app.change_model') - 注意
UserPassesTestMixin的get_test_func可被重写，适合动态构造权限规则，但别忘了调用super().get_test_func()若需保留父行为
