Gin vs Echo vs Fiber vs Chi: Qual Framework HTTP Escolher em Go

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 e o tutorial de API REST com Go antes de decidir.

Comparação rápida: Gin, Echo, Fiber, Chi e net/http

*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.

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.

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 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.

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.

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.

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 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.
• 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.
• Binding e validação: não confie só no framework. Valide contrato de entrada com testes; o guia de JSON em Go 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 e autenticação em APIs Go.

Framework e carreira: o que o mercado brasileiro pede

Nas vagas Go no Brasil, 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), testes de tabela (veja table-driven tests em Go) e deploy em container (veja Go com 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.