Busque em todas as páginas da documentação
O Go pode ter como alvo o WebAssembly sem cgo: o caminho do navegador usa GOOS=js GOARCH=wasm com syscall/js, e o caminho do servidor/edge usa GOOS=wasip1 GOARCH=wasm para hosts WASI.
cgo é indisponível em alvos wasm, então a interoperação muda para pontes JavaScript, importações WASI ou TinyGo para compilações restritas.
WebAssembly é uma alternativa portátil ao cgo nativo quando você implanta em navegadores, runtimes de edge ou plugins com sandbox.
Pipelines de build completos, ajuste de tamanho e comparações de host estão na seção WebAssembly & TinyGo - esta página orienta leitores de cgo sobre quando mudar.
Cartão de receita de referência rápida - pronto para copiar e colar.
# wasm do navegador (syscall/js)
GOOS=js GOARCH=wasm go build -o app.wasm ./cmd/app
# WASI preview1 (servidores, wazero, wasmtime)
GOOS=wasip1 GOARCH=wasm go build -o app.wasm ./cmd/appQuando usar isso:
.wasm com WASI em vez de libc.CGO_ENABLED=0 é obrigatório e syscalls nativas não estão disponíveis.Um programa WASI mínimo que escreve na saída padrão (sem cgo, sem syscall/js).
// cmd/hello/main.go
package main
import "fmt"
func main() {
fmt.Println("hello wasi")
}GOOS=wasip1 GOARCH=wasm go build -o hello.wasm ./cmd/hello
wasmtime hello.wasmO que isso demonstra:
fmt padrão funciona em wasip1 via importações WASI vinculadas pelo runtime wasm do Go.//go:build !wasm.wasmtime, wazero, Spin, etc.), não ./hello.wasm diretamente.syscall/js expõe valores JavaScript e callbacks para GOOS=js; não é usado em wasip1.| Preocupação | cgo Nativo | Go wasm |
|---|---|---|
| Bibliotecas C | Link .so/.a | Não disponível; use portas wasm ou hosts |
| DOM do Navegador | Não aplicável | Callbacks syscall/js |
| I/O de Arquivo | libc / x/sys | Arquivos WASI ou ponte JS fs |
| Tamanho do Binário | Nativo ELF/Mach-O | Módulo .wasm (gc wasm é maior que TinyGo) |
| Threads | Threads do SO | Threading wasm limitado; verifique o suporte do host |
| Caminho | Build | Host | Mergulho Profundo |
|---|---|---|---|
| Navegador | GOOS=js GOARCH=wasm | Navegador + wasm_exec.js | syscall/js Go no Navegador |
| Servidor WASI | GOOS=wasip1 GOARCH=wasm | wasmtime, wazero | Compilando com GOOS=wasip1 |
| TinyGo MCU | tinygo build -target=… | Placa ou wasm | TinyGo para microcontroladores |
//go:build !js && !wasm
package plugin
// implementação nativa apenas para cgo//go:build js || wasm
package plugin
// stub seguro para wasm ou implementação pura GoDivida pacotes para que o código de interoperação não puxe import "C" para compilações wasm.
wasm_exec.js - Erros de carregamento. Correção: Siga a wiki wasm do Go para configurar seu bundler.net completo em js/wasm - Restrito por sandboxes de host. Correção: Use pontes fetch/WebSocket documentadas para syscall/js.wasip1 e js - Conjuntos de syscalls diferentes. Correção: Separe pacotes main ou tags de build explícitas por alvo.| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| Serviço cgo nativo | Precisa de SDK C em servidores Linux | O alvo é navegador ou host apenas wasm |
Ponte syscall/js | APIs DOM e do navegador necessárias | Tarefas em lote WASI sem interface gráfica |
| TinyGo wasm | Restrições de tamanho e MCU dominam | Você precisa de recursos completos de genéricos/runtime |
| Módulo wasm Rust/C++ | A equipe já envia wasm lá | Loja apenas Go quer um idioma |
| RPC para sidecar nativo | Bibliotecas C pesadas permanecem no Linux | O sandbox Wasm é obrigatório |
Não - compilações WebAssembly são puramente Go com syscalls específicas do alvo.
Planeje a interoperação sem import "C".
js tem como alvo navegadores com syscall/js.
wasip1 tem como alvo runtimes WASI com importações semelhantes a POSIX, não o DOM.
Veja WebAssembly & TinyGo neste site - ordem da seção 38 no manifesto do guia Go.
Comece com Go em WebAssembly.
Versões recentes melhoraram o runtime wasm e o comportamento da memória.
Leia Melhorias no runtime wasm do Go 1.26 para detalhes fixados neste guia.
Microcontroladores, módulos sub-megabytes e wasm embarcado.
Use gc wasm quando precisar de compatibilidade total com stdlib e hosts de classe desktop.
Sim - wazero é um runtime wasm puramente Go adequado para embarcar.
Veja Runtimes de host WASI.
Use valores de função e callbacks syscall/js.
Mantenha os limites estreitos para evitar vazar goroutines entre eventos JS.
WASI define importações de sistema de arquivos e ambiente; hosts os mapeiam para recursos reais ou virtuais.
As capacidades variam de acordo com a configuração do host.
Sim - lógica de negócios em pacotes puramente Go com pontos de entrada de plataforma marcados.
Mantenha o cgo isolado atrás de //go:build cgo && !wasm.
Não - a integração nativa do SO no Linux/macOS/Windows ainda precisa de cgo ou x/sys.
Wasm é uma superfície de implantação adicional.
Binários gc wasm geralmente têm dezenas de MB descomprimidos antes do gzip.
TinyGo visa ordens de magnitude menores quando o subconjunto de linguagem é aceitável.
wasmtime, wazero e Spin aparecem na seção dedicada.
Verifique as versões em build por pinos de manifesto para tinygo e wazero.
Versões da Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, modernizadores go fix - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 18 de jul. de 2026