gin 默认不处理 /favicon.ico 请求，需用 favicon 中间件或 staticfs 暴露图标文件，并建议通过 gin_mode=release 或自定义日志过滤避免日志刷屏。
Gin 默认不处理 /favicon.ico 请求，浏览器会自动发起该请求，若未配置，日志里就会刷屏 GET /favicon.ico 404 —— 这不是 bug，是预期行为，但必须主动干预。
用 favicon 中间件拦截并返回图标文件
最直接的方式是引入第三方中间件 github.com/thinkerou/favicon，它会在收到 /favicon.ico 请求时直接读取本地文件并返回，不走路由逻辑。
- 安装：
go get github.com/thinkerou/favicon - 确保图标文件存在，比如
./static/favicon.ico（路径需与favicon.New()参数一致） - 注意：该中间件只响应
GET /favicon.ico，不处理其他路径或扩展名（如.png），也不支持多尺寸图标 - 示例代码中传入的路径是相对路径，运行时以当前工作目录为基准，不是以
main.go所在目录为准
gin.StaticFS 挂载静态目录更灵活
如果你已有 static/ 目录存放各类资源（CSS、JS、图标等），直接用 gin.StaticFS 暴露整个目录，比单独配 favicon 中间件更统一、更可控。
- 注册方式：
r.StaticFS("/static", http.Dir("./static")) - 然后在 HTML 的
里写：<link rel="icon" href="/static/favicon.ico" type="image/x-icon"> - 这样你还能顺便托管
/static/apple-touch-icon.png、/static/site.webmanifest等现代图标资源 - 注意：如果没配
StaticFS，又没用中间件，浏览器仍会 fallback 到根路径请求/favicon.ico，继续 404
忽略 /favicon.ico 日志避免干扰
即使你用了中间件或静态服务，开发阶段仍可能看到大量 GET /favicon.ico 请求打到 Gin 日志里——这不是错误，但会淹没真正有用的调试信息。
- Gin 本身没有“关闭某路径日志”的开关，所以得靠外围手段
- 推荐做法：启动时加环境变量
GIN_MODE=release，它会关闭 debug 日志中的详细请求记录（包括 favicon 请求） - 或者手动过滤日志输出：重写
gin.LoggerWithWriter，对c.Request.URL.Path == "/favicon.ico"跳过打印 - 切勿在 Nginx 层用
log_not_found off来掩盖问题——那只是藏起了症状，没解决图标缺失本质
真正容易被忽略的是：浏览器对 favicon 的请求行为不可控，它总会在首次加载页面时发一次 /favicon.ico，且不带缓存头；哪怕你 HTML 里写了 <link rel="icon" href="/static/xxx.png">，它仍可能先 GET 根路径图标。所以服务端必须对 /favicon.ico 有明确响应策略，不能依赖前端声明。
