Buenas Prácticas de Reflexión y Generación de Código
Elige la reflexión para frameworks, la generación de código para rutas críticas.
Busca en todas las páginas de la documentación
Elige la reflexión para frameworks, la generación de código para rutas críticas.
Estas reglas convierten los artículos sobre reflexión y generación de código en esta sección en hábitos revisables para equipos de bibliotecas, servicios y plataformas.
pprof y benchmarks para probar que la reflexión es un cuello de botella, no algo asumido.Marshaler/Unmarshaler en tipos calientes probados antes de adoptar un nuevo framework generador de JSON.validate, json, db, personalizado).Tag.Lookup cuando la presencia de la clave sea importante; no confíes solo en Get para detectar claves faltantes.json duplicados y sintaxis de etiquetas inválida.reflect.Type y almacena en caché los planes de campos en sync.Map o en la inicialización del paquete.// Code generated ... DO NOT EDIT a menos que todos los consumidores ejecuten generadores.go generate ./... produce un diff para que la deriva se detecte antes de fusionar.tools.go (etiqueta de compilación tools) e instala esa versión en CI.format.Source para que las comprobaciones de gofmt pasen.testdata/.-benchmem al comparar rutas de JSON/ORM reflectivas con alternativas generadas.reflect.* en perfiles de CPU bajo manejadores de marshal, escaneo y validación.go fix y go test ./....//go:fix inline en shims de reenvío al renombrar o mover símbolos, con Deprecated: en godoc.go fix -diff en repositorios grandes antes de aplicar cambios generalizados.go fix dos veces en ramas de actualización cuando las notas de lanzamiento recomienden pases sinérgicos.No.
Prohibir la reflexión ilimitada por solicitud sin medición.
La inicialización de frameworks y las herramientas de administración están bien.
Cuando los benchmarks y los SLOs demuestren que los serializadores reflectivos o los escaneos de ORM dominan la CPU o las asignaciones.
No antes de que exista evidencia.
Los propietarios de la plataforma o del servicio añaden el paso a la canalización estándar.
El mismo equipo revisa las actualizaciones de la versión del generador.
Commits separados: uno para cambios de tipo escritos a mano, otro solo para la salida de go generate.
Sí.
Patrón común: reflexionar una vez al inicio, generar código para tipos calientes por solicitud.
Acepta el costo de la reflexión para la velocidad en rutas de bajo QPS.
Introduce sqlc/ent o DTOs delgados cuando los perfiles lo exijan.
La deprecación indica a los humanos que migren.
Los shims inline permiten que go fix automatice los sitios de llamada cuando existen funciones de reenvío.
Sí, para enseñar.
El código de producción en el mismo servicio debe seguir las reglas anteriores.
Señálales Reflection Basics, luego esta lista durante la primera revisión de API u ORM.
govet, errcheck, analizadores de etiquetas de struct y comprobaciones de diff de go generate en CI.
Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado de GC Green Tea, modernizadores de go fix - verifica el parche en la compilación), chi (última versión - verifica en la compilación), gin (última versión - verifica en la compilación), echo (última versión - verifica en la compilación), google.golang.org/grpc (última versión - verifica en la compilación), sigs.k8s.io/controller-runtime (última versión - verifica en la compilación), kubebuilder (última versión - verifica en la compilación), tinygo (última versión - verifica los objetivos de la placa en la compilación), wazero (última versión - verifica en la compilación) y golangci-lint (última versión - verifica el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 16 jul 2026