直接在模板中硬编码{% if user.is_staff %}会导致权限逻辑分散、难以维护，且无法支持多角色叠加、动态菜单、路径冲突处理等复杂业务需求；应通过中间件预加载结构化菜单数据到request.menu_items，统一在后端完成权限计算、排序、树形组装、缓存及active状态标记。

为什么直接在模板里写 {% if user.is_staff %} 不够用

因为角色权限常随业务变化，硬编码判断会让菜单和权限逻辑散落在模板、视图甚至 URL 配置里，改一个菜单项就得翻三处代码。更麻烦的是，当角色支持“自定义菜单项”或“按部门动态过滤”时，is_staff 或 user.groups.filter(name='admin') 这类静态检查完全无法支撑。

用中间件预加载菜单数据到 request 上最稳妥

不要依赖模板层做复杂查询，把菜单结构一次性查好、缓存好，挂到 request.menu_items 上。这样模板里只管渲染，不碰权限逻辑。

• 在中间件中检查 request.user.is_authenticated，未登录用户跳过
• 调用封装好的 get_user_menu_items(user) 函数，该函数内部按角色查 RoleMenuPermission 关联表（推荐用 select_related('menu') 减少 N+1）
• 结果按 menu.order 排序，并递归组装成树形结构（如 {'id': 1, 'label': '订单', 'children': [...]}）
• 避免每次请求都查库：对同一角色的菜单结果用 cache.get_or_set('menu_role_{}'.format(role_id), ...)

get_user_menu_items() 必须处理多角色叠加和路径冲突

真实场景中用户可能属于多个角色，而不同角色配置的菜单项可能重复（比如都包含“用户管理”），也可能冲突（A 角色允许 /users/list，B 角色禁止）。不能简单取并集。

python-script-generator

快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。

下载

• 按角色权重排序（例如 superuser > admin > dept_leader），高权重覆盖低权重
• 每条菜单记录带 permission_level 字段（allow/deny），遇到 deny 直接剔除该节点及其子节点
• URL 路径需标准化：统一用 url_path = menu.url.strip('/')，避免 /user/ 和 /user 被当成两个不同项
• 示例：若 A 角色允许 report/dashboard，B 角色 deny report，则整个 report 分组都不应出现

模板里用 menu_items 渲染时别漏掉 active 状态判断

前端需要知道当前页面对应哪个菜单项高亮，但 Django 模板无法直接访问 request.path 的深度匹配逻辑（比如 /orders/detail/123 应激活 /orders/ 菜单项）。

立即学习“Python免费学习笔记（深入）”；

• 在中间件组装菜单时，就为每个菜单项计算 is_active：用 request.path.startswith('/' + item.url)（注意加前导 /）
• 如果菜单项是外链（menu.url.startswith('http')），跳过 active 判断
• 模板中直接写 {% if item.is_active %}class="active"{% endif %}，别在前端用 JS 再算一次
• 避免用 request.resolver_match.view_name 做匹配——它依赖 URLconf 名称，而菜单配置通常用路径，二者易脱节

菜单结构本身不难，难的是权限叠加规则怎么设计得既灵活又不爆炸。很多项目卡在“角色 A 能看订单列表，但不能看详情”这种粒度上，这时候菜单节点就得关联到具体 view 或 action，而不是只靠 URL 路径。那已经是权限控制层的事了，菜单只是它的输出投影。