Go html/template 怎么高亮当前导航：传入 CurrentPath 的最小写法

服务端页面有五个菜单时，最容易出现的不是布局问题，而是“当前页到底该让哪一项亮起来”。把判断写进每一份模板，新增一个路由就要改好几处；把路径和菜单数据放在一起，模板只负责渲染，导航状态就稳定得多。

导航高亮为什么总会散成多份条件判断

一个常见写法是在首页、订单页、设置页各放一段 {{if ...}}。开始只有两个菜单时看不出问题，等“账单”“团队”“通知”陆续加入，标签、链接和高亮规则就不再同步。真正需要共享的是页面状态，而不是复制那条 class 判断。

这里的目标很小：页面数据里有当前路径，菜单项里有路径和名称；模板遍历菜单时，只有路径相等的链接带上 is-active。CSS 不需要知道业务路由，Go 代码也不用拼接 HTML。

先定义页面数据和菜单项

用结构体把这两类信息摆到同一个位置。菜单数据可以来自固定切片、配置文件或数据库，但在进入模板前最好已经整理成这一层的形状。

type NavItem struct {
	Label string
	Path  string
}

type PageData struct {
	CurrentPath string
	NavItems    []NavItem
}

var mainNav = []NavItem{
	{Label: "概览", Path: "/"},
	{Label: "订单", Path: "/orders"},
	{Label: "设置", Path: "/settings"},
}

当请求 /orders 到来时，路由层构造 PageData{CurrentPath: "/orders", NavItems: mainNav}。把 CurrentPath 放在页面数据而不是全局变量里，多个请求同时到来时也不会互相覆盖状态。

最小配方：用 active 函数只产出一个布尔结果

模板中的条件不必复杂。把路径比较收进一个小函数，模板就只表达“当前项是否激活”。这里不要把用户输入直接变成 class 或模板片段，active 的返回值始终是布尔值。

func active(current, itemPath string) bool {
	return current == itemPath
}

func newNavTemplate() *template.Template {
	return template.Must(
		template.New("nav").
			Funcs(template.FuncMap{"active": active}).
			Parse(navHTML),
	)
}

Funcs 的调用顺序很重要：模板要在解析时认识 active，所以先注册函数映射，再解析模板文本。若项目有公共布局，也可以让这段注册逻辑只出现一次，再为各页面复用同一个基础模板。

模板和 CSS 各自只做一件事

模板循环菜单并按结果附加 class；CSS 只负责视觉状态。这样设计后，改主题颜色不会触碰 Go 代码，调整路由也不必改样式表。

{{define "nav"}}

{{end}}

.nav-link {
  color: #667085;
  border-bottom: 2px solid transparent;
  text-decoration: none;
}

.nav-link.is-active {
  color: #175cd3;
  border-bottom-color: currentColor;
  font-weight: 600;
}

模板的 range 会把当前元素作为点号上下文，因此当前路径要通过 $.CurrentPath 回到根数据。很多人第一次写时漏掉 $，结果拿不到页面级字段；这不是 CSS 没生效，而是模板作用域变了。

路径相等不一定等于产品语义相等

/orders 与 /orders/42 是否应高亮同一个菜单，是产品规则，不是模板语法问题。简单后台页面可以坚持完全相等；详情页较多时，建议在路由层直接传 ActiveNav: "orders"，模板比较稳定的菜单键，而不是用字符串前缀猜测。

给路径判断补一组很小的测试

函数只有一行，也值得把主页、同路径和不同路径放进用例。菜单从 / 开始时尤其容易出现“所有链接都像首页子路径”的错误，所以不要在没有规则的前提下自行扩展匹配。

func TestActive(t *testing.T) {
	cases := []struct {
		current string
		item    string
		want    bool
	}{
		{"/orders", "/orders", true},
		{"/orders", "/settings", false},
		{"/orders/42", "/orders", false},
	}

	for _, tc := range cases {
		if got := active(tc.current, tc.item); got != tc.want {
			t.Fatalf("active(%q, %q) = %v", tc.current, tc.item, got)
		}
	}
}

如果详情页应归到订单菜单，就修改页面数据的组装规则，并把对应样例补进测试；别在 active 里悄悄塞进越来越多的例外。

延伸问答

为什么 HTML 页面不用 text/template？

html/template 会按 HTML 上下文处理数据输出，适合生成网页。除非你确实要输出纯文本，否则不要为了少写几个字符换到不带 HTML 语义的包。

能否直接在模板里比较两个字符串？

可以使用模板提供的比较能力，但把高亮规则收进 active 后，复杂度和测试位置更清楚；以后改为菜单键比较时，模板无需大改。

多级导航怎么处理？

为菜单项增加 Key、ParentKey 或层级数据，在进入模板前完成激活链计算。模板负责显示层级，不负责推断路由归属。

外部链接也能用这个结构吗？

可以，但外部链接通常不参与当前路径高亮。为 NavItem 增加 External 标记，并在模板中补充安全的链接属性即可。

把高亮规则收回到数据层

导航的视觉状态不该散落在每个页面。路由层提供清楚的当前状态，模板做循环与条件，CSS 呈现 is-active，这条边界既适合三项小菜单，也能平滑扩展到带权限和详情页的后台。