request.endpoint 是 Flask 中最可靠的当前视图标识方式,返回带蓝图前缀的端点名(如 'admin.users'),不依赖 URL 路径拼写,避免斜杠、参数等干扰,适用于服务端渲染场景下的菜单高亮与权限校验。

Flask + Jinja2 中用 request.endpoint 判断当前页面
服务端渲染场景下,request.endpoint 是最可靠的方式——它返回的是视图函数名(如 'dashboard.index' 或 'feature1.list'),不依赖 URL 路径拼写,避免了斜杠结尾、查询参数、哈希路由等干扰。
关键点:
- 必须在 Flask 的
before_request或模板上下文中确保request可用;Jinja2 模板里直接写{{ request.endpoint }}就能取到值 - 菜单项链接的
href应使用url_for('view_name')生成,保证 endpoint 和链接一一对应 - 若视图用了蓝图,endpoint 名会带前缀(如
admin.users),匹配时要写全,不能只写'users' - 不要用
request.url或request.path做字符串匹配——路径可能被重写、带参数、大小写不一致
纯静态 HTML 站点用 window.location.pathname 匹配链接
没有后端时,只能靠 JavaScript 实时比对当前路径和每个 @#@#@#@#@#@#@#@#@#@0,这是屏幕阅读器识别当前页的唯一标准
为什么不能手动在每个 HTML 文件里写 class="active"
看似省事,实际是维护灾难:新增菜单项要改 N 个文件;路径微调(/blog → /articles)漏改一处,高亮就错位;哈希路由(#projects)或查询参数(?ref=nav)会让静态 class 完全失效。
更隐蔽的问题:
- SEO 友好性受损:搜索引擎看到的是 N 份几乎一样的 HTML,但每份只有一个
active类位置不同,容易误判内容结构 - 无法做自动化测试:没法写一个通用脚本校验“所有页面中,只有当前路径对应的菜单有
active类” - 团队协作时冲突概率高:两人同时改不同页面的导航,git merge 极易出错
- 响应式切换(如移动端折叠菜单)需要 JS 控制展开状态,此时 active 类还得同步更新,纯静态根本做不到
复杂点往往藏在路径标准化和无障碍属性上——前者决定高亮准不准,后者决定它对谁真正可用。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











