本文介绍如何在 flask + jinja2 项目中，通过 `request.endpoint` 动态为 base.html 中的侧边栏菜单项添加 `.active` 类，实现当前页面对应导航项的样式高亮，避免为每个子模板重复定义结构。
在构建多页面 Flask 应用时，常使用 base.html 作为统一布局模板，其中包含公共头部、侧边栏（Sidebar）和内容区域。为了让用户清晰识别当前所处页面，通常需高亮侧边栏中对应的菜单项（如“Dashboard”“Feature1”“Feature2”）。理想方案是：逻辑集中于 base.html，无需在每个子模板中手动传递状态变量。
Jinja2 提供了简洁可靠的解决路径——结合 Flask 的 request.endpoint 属性与条件渲染语法。request.endpoint 在模板中可直接访问（需确保已启用 request 上下文），其值即为当前视图函数的端点名称（如 'dashboard'、'feature1'），与 url_for() 中使用的名称一致。
✅ 正确做法：在 base.html 中动态绑定 active 类
首先，在 CSS 中定义高亮样式（推荐放在
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
.sidebar a {
display: block;
padding: 12px 20px;
color: #333;
text-decoration: none;
}
.sidebar a.active {
background-color: #007bff;
color: white;
font-weight: bold;
}然后，在 base.html 的侧边栏部分，为每个链接添加条件类名：
<!-- base.html -->
<nav class="sidebar">
<a href="{{ url_for('dashboard') }}"
class="{% if request.endpoint == 'dashboard' %}active{% endif %}">
Dashboard
</a>
<a href="{{ url_for('feature1') }}"
class="{% if request.endpoint == 'feature1' %}active{% endif %}">
Feature 1
</a>
<a href="{{ url_for('feature2') }}"
class="{% if request.endpoint == 'feature2' %}active{% endif %}">
Feature 2
</a>
</nav>✅ 注意：此方式依赖 request.endpoint，因此要求所有路由均已正确定义端点名（默认即函数名，也可显式指定 @app.route('/feature1', endpoint='feature1')）。
⚠️ 常见注意事项
- 确保 request 可用：Jinja2 模板中默认可访问 request 对象，但若使用自定义上下文处理器或禁用了请求上下文，需检查配置；
- 避免硬编码字符串：不要用 request.path 或 request.url 做字符串匹配（易出错、难维护），endpoint 是语义化且稳定的标识；
- 支持蓝图（Blueprint）端点：若路由属于蓝图（如 admin.dashboard），则 request.endpoint 返回完整端点名（如 'admin.dashboard'），需同步调整判断逻辑；
- 增强可读性（进阶）：可封装为宏（macro）复用逻辑：
{%- macro nav_link(endpoint, text) -%}
<a href="{{ url_for(endpoint) }}"
class="{% if request.endpoint == endpoint %}active{% endif %}">
{{ text }}
</a>
{%- endmacro -%}
<!-- 使用示例 -->
{{ nav_link('dashboard', 'Dashboard') }}
{{ nav_link('feature1', 'Feature 1') }}
{{ nav_link('feature2', 'Feature 2') }}✅ 总结
通过 request.endpoint 与 Jinja2 条件渲染，我们以声明式、低耦合的方式实现了导航高亮，既保持了 base.html 的通用性，又消除了子模板中的冗余逻辑。这是 Flask + Jinja2 生态中推荐的标准实践，兼顾可维护性、可读性与性能——无需额外上下文变量，不增加服务端负担，一次配置，全站生效。
