--- title: "Gin vs Echo vs Fiber vs Chi: Qual Framework HTTP Escolher em Go" url: "https://golang.com.br/blog/frameworks-http-go-gin-echo-fiber-chi/" markdown_url: "https://golang.com.br/blog/frameworks-http-go-gin-echo-fiber-chi.MD" description: "Comparação prática dos frameworks HTTP em Go (Gin, Echo, Fiber, Chi e net/http puro): roteamento, middleware, performance, ecossistema e qual escolher no Brasil em 2026." date: "2026-07-06" author: "Golang Brasil" --- # Gin vs Echo vs Fiber vs Chi: Qual Framework HTTP Escolher em Go Comparação prática dos frameworks HTTP em Go (Gin, Echo, Fiber, Chi e net/http puro): roteamento, middleware, performance, ecossistema e qual escolher no Brasil em 2026. A pergunta mais frequente de quem começa uma API em Go no Brasil não é "como faço um hello world". É "qual framework eu uso: Gin, Echo, Fiber ou Chi?". A resposta curta é irritante para quem quer um nome só: **depende**. A resposta longa é mais útil, e é o que este guia faz — comparar os quatro frameworks HTTP mais usados em Go e o próprio `net/http`, com roteamento, middleware, performance, ecossistema e os critérios reais para escolher em 2026. Antes de tudo, uma verdade que muita comparação esconde: **Go não precisa de framework**. A biblioteca padrão já tem um servidor HTTP de produção, com TLS, timeouts, `http.Handler` e, desde o Go 1.22, roteamento com métodos e parâmetros de caminho. Frameworks existem para adicionar ergonomia, convenção e atalho — não para tornar Go usável. Se você está começando, leia o guia de [Go para backend](/aprenda/golang-para-backend/) e o tutorial de [API REST com Go](/aprenda/api-rest-go/) antes de decidir. ## Comparação rápida: Gin, Echo, Fiber, Chi e net/http | Critério | net/http | Gin | Echo | Chi | Fiber | |---|---|---|---|---|---| | Base | standard library | net/http | net/http | net/http | fasthttp | | Compatível com `http.Handler` | sim | parcial (`gin.WrapH`) | parcial (`echo.WrapHandler`) | sim, nativo | não | | Roteamento por métodos e path params | sim (Go 1.22+) | sim | sim | sim | sim | | Agrupamento de rotas (`Group`) | manual | sim | sim | sim (`Route`) | sim | | Binding de JSON / validação | manual | sim (`ShouldBind`) | sim (`Bind`) | manual | sim | | Velocidade (throughput bruto) | alta | muito alta | muito alta | alta | altíssima* | | Curva de aprendizado | baixa | baixa | baixa | baixa | baixa | | Mais parecido com Express/Node | não | um pouco | um pouco | não | sim | *A vantagem de Fiber em throughput vem do `fasthttp`, que evita alocações trocando compatibilidade por velocidade. Em API real com banco de dados, rede e JSON, a diferença costuma desaparecer. ## net/http: a base que já resolve muito O `net/http` é o pacote da biblioteca padrão. Desde o Go 1.22, o `http.ServeMux` ganhou roteamento com método HTTP e parâmetros de caminho, o que reduziu drasticamente a necessidade de um framework para casos comuns. ```go package main import ( "encoding/json" "log" "net/http" "strconv" "time" ) type Usuario struct { ID int `json:"id"` Nome string `json:"nome"` } func main() { mux := http.NewServeMux() mux.HandleFunc("GET /usuarios/{id}", func(w http.ResponseWriter, r *http.Request) { id, err := strconv.Atoi(r.PathValue("id")) if err != nil { http.Error(w, "id inválido", http.StatusBadRequest) return } _ = json.NewEncoder(w).Encode(Usuario{ID: id, Nome: "Diego"}) }) srv := &http.Server{ Addr: ":8080", Handler: mux, ReadHeaderTimeout: 5 * time.Second, } log.Fatal(srv.ListenAndServe()) } ``` **Use `net/http` puro quando:** o projeto é pequeno ou médio, o time valoriza dependência mínima, você quer máximo controle, ou quer aprender os fundamentos antes de adicionar abstrações. É também a base sobre a qual Gin, Echo e Chi rodam. A desvantagem real é ergonomia: validação, binding de JSON, serialização com tratamento de erro e middlewares encadeados exigem mais código manual. Em APIs grandes, isso vira repetição. ## Gin: o mais popular e ergonômico `Gin` é, de longe, o framework mais usado em exemplos, tutoriais e projetos Go no Brasil. Ele roda sobre `net/http`, usa uma radix tree para roteamento rápido e empacota binding de JSON, validação com tags, middleware e grupos de rotas. ```go package main import ( "net/http" "github.com/gin-gonic/gin" ) type Usuario struct { ID int `json:"id" binding:"required"` Nome string `json:"nome" binding:"required,min=2"` } func main() { r := gin.Default() api := r.Group("/api/v1") { api.GET("/usuarios/:id", func(c *gin.Context) { c.JSON(http.StatusOK, gin.H{"id": c.Param("id"), "nome": "Diego"}) }) api.POST("/usuarios", func(c *gin.Context) { var u Usuario if err := c.ShouldBindJSON(&u); err != nil { c.JSON(http.StatusBadRequest, gin.H{"erro": err.Error()}) return } c.JSON(http.StatusCreated, u) }) } _ = r.Run(":8080") } ``` **Use Gin quando:** o time quer produtividade rápida, a equipe já conhece o framework, você precisa de muitos tutoriais em português e quer reutilizar middleware pronto. A série de [API REST com Gin](/aprenda/api-rest-gin-parte1/) cobre o caminho completo desde a primeira rota até deploy. O ponto de atenção do Gin é a dependência do `gin.Context`, que é próprio do framework. Middleware escrito para `http.Handler` precisa de adaptadores (`gin.WrapH`, `gin.WrapF`), e o `gin.Context` é reciclado entre requests — acessar goroutines que sobrevivem ao request exige cópia explícita do contexto. ## Echo: API limpa e tratamento de erros centralizado `Echo` é próximo do Gin em proposta, mas com uma filosofia um pouco diferente: API enxuta, tratamento de erro centralizado via `HTTPErrorHandler` e menos "mágica". Também roda sobre `net/http`. ```go package main import ( "net/http" "strconv" "github.com/labstack/echo/v4" ) func main() { e := echo.New() e.GET("/usuarios/:id", func(c echo.Context) error { id, err := strconv.Atoi(c.Param("id")) if err != nil { return echo.NewHTTPError(http.StatusBadRequest, "id inválido") } return c.JSON(http.StatusOK, map[string]any{"id": id, "nome": "Diego"}) }) e.Start(":8080") } ``` **Use Echo quando:** o time prefere tratamento de erro explícito (cada handler retorna `error`), você quer uma estrutura mais previsível de middlewares, ou já trabalha com o ecossistema Labstack. Em performance e recursos, Echo e Gin são praticamente equivalentes; a escolha costuma ser gosto de time e familiaridade. Assim como Gin, Echo tem seu próprio contexto (`echo.Context`) e exige adaptadores (`echo.WrapHandler`) para reaproveitar middleware do `net/http`. ## Chi: o idiomático, 100% compatível com net/http `Chi` é a escolha favorita de quem quer "Go da forma mais Go possível". Ele roda sobre `net/http` e é totalmente compatível com `http.Handler` e `http.HandlerFunc`. Qualquer middleware escrito para a standard library funciona com Chi sem adaptador. ```go package main import ( "encoding/json" "net/http" "strconv" "github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware" ) func logger(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { next.ServeHTTP(w, r) }) } func main() { r := chi.NewRouter() r.Use(middleware.RequestID) r.Use(middleware.RealIP) r.Use(logger) r.Get("/usuarios/{id}", func(w http.ResponseWriter, r *http.Request) { id, err := strconv.Atoi(chi.URLParam(r, "id")) if err != nil { http.Error(w, "id inválido", http.StatusBadRequest) return } _ = json.NewEncoder(w).Encode(map[string]any{"id": id, "nome": "Diego"}) }) http.ListenAndServe(":8080", r) } ``` **Use Chi quando:** você valoriza compatibilidade total com `net/http`, quer reaproveitar middleware do ecossistema padrão, pretende migrar de `net/http` para um roteador com o menor acoplamento possível, ou segue a filosofia de "dependa do mínimo". É também uma porta de entrada elegante: comece com `net/http`, adicione Chi quando o roteamento ficar complexo. A "desvantagem" do Chi é justamente a virtude: ele faz menos por você. Binding de JSON, validação e respostas padronizadas você escreve (ou compõe com pacotes como `go-playground/validator`). ## Fiber: rápido, mas sobre fasthttp `Fiber` é o framework que mais se parece com Express do Node.js e costuma aparecer no topo de benchmarks de throughput. O motivo é importante: **Fiber não roda sobre `net/http`**, e sim sobre `fasthttp`, um servidor HTTP alternativo com implementação própria. ```go package main import ( "github.com/gofiber/fiber/v2" ) type Usuario struct { ID int `json:"id"` Nome string `json:"nome"` } func main() { app := fiber.New() app.Get("/usuarios/:id", func(c *fiber.Ctx) error { return c.JSON(Usuario{ID: 1, Nome: "Diego"}) }) app.Listen(":8080") } ``` **Use Fiber quando:** você vem do Node.js/Express e quer produtividade familiar, o projeto é um gateway ou proxy de altíssimo tráfego onde o throughput do `fasthttp` realmente importa, e o time entende as limitações. O ponto de atenção é real e merece destaque: por usar `fasthttp`, **Fiber não é compatível com `http.Handler` e `http.HandlerFunc`**. Grande parte do middleware e de bibliotecas do ecossistema Go (OpenTelemetry HTTP, Prometheus, pacotes que esperam `*http.Request` e `http.ResponseWriter`) precisa de adaptação ou não funciona direto. O `fasthttp` também reaproveita structs entre requests, o que exige cuidado ao capturar valores em goroutines que sobrevivem ao request. Para APIs comuns com banco de dados, JSON e chamadas externas, a vantagem de performance do Fiber costuma ser irrelevante diante do custo de integração. ## Performance: o que importa de verdade Benchmarks de "hello world" mostram diferenças grandes entre os frameworks, mas **esse cenário não representa produção**. Em uma API real, o tempo de resposta é dominado por banco de dados, rede, JSON e chamadas externas — não pelo roteador. A diferença entre Gin, Echo e Chi em carga real costuma ficar dentro da margem de ruído. A pergunta certa não é "qual é o mais rápido". É: - o framework adiciona latência mensurável no seu caminho crítico? (raro) - o overhead de alocação importa no seu volume de tráfego? (quase nunca, antes do banco) - a escolha complica observabilidade, middleware e bibliotecas? (esse sim, pesa) Se você quer medir de verdade no seu projeto, o tutorial de [profiling e performance em Go](/tutoriais/go-performance-profiling/) mostra como usar `pprof` para encontrar gargalos reais em vez de apostar em benchmarks alheios. ## Como escolher na prática Use estes critérios em ordem: 1. **Projeto pequeno ou didático:** comece com `net/http` puro. Você aprende a base e evita dependência. Desde o Go 1.22, o roteamento já cobre a maioria dos casos. 2. **Time quer produtividade e muitos exemplos:** Gin é a aposta segura no Brasil. É o mais ensinado, o mais pedido em vagas e o que tem mais material em português. 3. **Valor idiomático e compatibilidade total com `net/http`:** Chi. É o que menos "foge" da standard library e facilita trocar de ideia no futuro. 4. **API limpa com erro centralizado e time já conhece:** Echo. 5. **Altíssimo tráfego, equipe vinda de Express e entende o custo:** Fiber. Para a maioria das APIs backend no Brasil em 2026, **Gin ou Chi (com `net/http` por baixo)** cobrem o caso. Fiber é uma escolha legítima, mas exige maturidade para lidar com o `fasthttp`. ## Cuidados comuns ao adotar um framework - **Timeouts do servidor:** mesmo com framework, configure `ReadHeaderTimeout`, `ReadTimeout` e `WriteTimeout`. Frameworks não substituem isso. Veja [context, timeout e cancelamento em Go](/blog/context-timeout-cancelamento-go/). - **Middleware de observabilidade:** instrumente com OpenTelemetry e Prometheus. Com Chi e `net/http`, o middleware padrão funciona direto; com Gin, Echo e Fiber, use os adaptadores oficiais. Veja [OpenTelemetry em Go](/blog/go-opentelemetry-observabilidade-tracing-metricas/). - **Binding e validação:** não confie só no framework. Valide contrato de entrada com testes; o guia de [JSON em Go](/blog/json-go-encoding-json-v2-streaming-validacao/) mostra como tratar limites, campos desconhecidos e validação. - **Erros centralizados:** padronize respostas de erro com um `HTTPErrorHandler` (Echo) ou middleware (Gin/Chi). Evite misturar formatos por rota. - **Versionamento de rotas:** use `Group("/api/v1")` desde o início. Refatorar depois é caro. - **Middlewares de segurança:** CORS, rate limiting e headers de segurança. Combine com [rate limiting em Go](/blog/rate-limiting-go-api-producao/) e [autenticação em APIs Go](/blog/autenticacao-autorizacao-go-apis/). ## Framework e carreira: o que o mercado brasileiro pede Nas [vagas Go no Brasil](/vagas/), o nome do framework aparece menos do que parece em fóruns. O que aparece é "API REST", "microsserviços", "cloud", "observabilidade", "mensageria" e "banco de dados". Entender um framework popular (Gin) é útil para entrevistas, mas o diferencial é dominar `net/http`, `context`, testes, concorrência e padrões de produção — eles transferem entre qualquer framework. Se você está montando portfólio, construa uma API REST com rotas versionadas, middleware de log com `slog` (veja [logging estruturado em Go](/blog/slog-go-logging-estruturado/)), testes de tabela (veja [table-driven tests em Go](/blog/testes-tabela-go-guia-table-driven-tests/)) e deploy em container (veja [Go com Docker](/aprenda/golang-docker/)). Esse conjunto vale mais do que saber a API de um framework específico. Para comparar como a escolha de stack aparece em outras linguagens, o guia de API REST em Python mostra o mesmo debate de "framework ou biblioteca padrão" no ecossistema Python — FastAPI, Flask e Django cumprem papel parecido ao de Gin, Echo e Chi em Go.