浏览器访问 go web 服务器根路径时，handlefunc 被触发两次，实为浏览器自动请求 / 和 /favicon.ico 所致；而 curl 默认不发 favicon 请求，故仅触发一次。
浏览器访问 go web 服务器根路径时，handlefunc 被触发两次，实为浏览器自动请求 / 和 /favicon.ico 所致；而 curl 默认不发 favicon 请求，故仅触发一次。
在 Go 中构建简单 HTTP 服务时，初学者常遇到一个看似诡异的现象：浏览器访问 https://www.php.cn/link/d62bd5e1be9a157e45aed37bd98743c2，日志却打印两行 "hello."，而使用 curl localhost:8000 却只打印一次。这并非 Go 的 Bug，也非路由配置错误，而是现代浏览器的默认行为所致。
根本原因：浏览器会自动发起 favicon 请求
当你在地址栏输入 URL 并回车，主流浏览器（Chrome、Firefox、Safari 等）不仅会请求你指定的路径（如 /），还会额外发起一次对 /favicon.ico 的 GET 请求，试图获取网站图标。由于你的代码中仅注册了 "/" 的处理器，而未显式处理 "/favicon.ico"，该请求仍会被 http.ServeMux 匹配到 "/"（因为 "/favicon.ico" 以 "/" 为前缀），从而再次调用 hello 函数。
✅ 验证方法：在日志中打印请求路径，即可一目了然：
func hello(w http.ResponseWriter, r *http.Request) {
log.Printf("Received request for path: %q", r.URL.Path) // 关键调试日志
io.WriteString(w, "Hello world!")
}运行后访问浏览器，日志将类似：
2024/05/20 10:30:12 Received request for path: "/" 2024/05/20 10:30:12 Received request for path: "/favicon.ico"
? 解决方案有三种，按推荐顺序排列：
-
显式注册 favicon 处理器（推荐）
返回空响应或静态文件，避免干扰主逻辑：mux.HandleFunc("/favicon.ico", func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusNoContent) // 204，明确告知无内容 }) -
路径精确匹配过滤（适合简单计数场景）
在 handler 内部校验路径，仅对根路径执行业务逻辑：func hello(w http.ResponseWriter, r *http.Request) { if r.URL.Path != "/" { return // 忽略 /favicon.ico 等非预期路径 } io.WriteString(w, "Hello world!") log.Println("hello.") // ✅ 此处递增计数器安全可靠 } -
提供真实 favicon（生产环境最佳实践）
将 favicon.ico 放入静态资源目录，并用 http.FileServer 服务：mux.Handle("/favicon.ico", http.StripPrefix("/favicon.ico", http.FileServer(http.Dir("./static/favicon.ico"))))
⚠️ 注意事项：
- 不要依赖 r.Referer() 或 User-Agent 判断是否为 favicon 请求——不可靠且违反 HTTP 语义；
- 若使用第三方路由器（如 Gorilla Mux、Chi），同样需注意其默认通配行为，建议启用严格模式（如 mux.StrictSlash(true)）；
- 计数类逻辑（如访问统计、限流）务必结合路径校验或独立路由，否则将因 favicon 请求导致数据失真。
总结：Go 的 HTTP 路由机制完全正确，问题源于对浏览器行为的理解偏差。通过日志观察请求路径、合理划分路由职责，即可彻底规避“被调用两次”的陷阱，让计数、鉴权、审计等关键逻辑稳定可靠。
