Go-SpringPut engineering capabilities into Go
Configuration, dependencies, lifecycle, and infrastructure are assembled through one model, while your business code stays simple, clear, and direct.
Skip to content
Start with the core framework,
Let your next Go service
ConfigurationIoC ContainerLifecycleHTTP ServerStructured LoggingStarter Ecosystem
Less plumbing, more product
Services get complex, business code does not have to
Real Go services are more than handlers. Configuration loading, component initialization, dependency wiring, startup order, and graceful shutdown gradually leak into every project.
Go-Spring gathers those repeated concerns into one consistent application model. You still write plain Go code, but you no longer hand-wire every piece of infrastructure.
Why Go-Spring exists →package main
import "go-spring.org/spring/gs"
func init() {
gs.Provide(&UserService{})
gs.Provide(&UserHandler{})
}
func main() {
gs.Run()
} application started:9090
01
Startup wiringruntime stays direct
02
Unified lifecyclestartup and shutdown stay ordered
One application model
One model for the engineering skeleton of a service
The capabilities work together, instead of living as unrelated tools. Configuration drives assembly, the container manages dependencies, and the application context coordinates the full lifecycle.
01 / CONFIG→
Configuration becomes part of the application
Load files, environment variables, defaults, and property references in one place, then bind them directly to type-safe structs.
server.port: ${PORT:=9090}02 / COMPOSE→
Dependencies stay visible
Register beans, apply conditions, and inject dependencies at startup, instead of scattering service lookup logic through business code.
03 / RUNTIME→
Ordered from startup to shutdown
Runners, servers, and resource cleanup follow one lifecycle, so service startup and graceful shutdown no longer depend on scattered conventions.
Spring inspired, Go designed
Borrow Spring's engineering experience, but do not bring Java into Go
Keep
Mature service organization
- 01Configuration-driven application assembly
- 02Clear component boundaries and dependencies
- 03A manageable full lifecycle
- 04Reusable infrastructure integrations
Drop
Complexity that does not fit Go
- ×Runtime dynamic proxies and scanning
- ×Layers of wrapped abstractions
- ×Black-box magic that hides execution paths
- ×Framework design for its own sake
Ecosystem
Start with the core framework,
extend only when needed
The core stays restrained, while logging, tooling, and infrastructure integrations evolve independently. Bring in only what the current service actually needs.
Ready to build
Let your next Go service
start from a clear engineering skeleton
Start with a minimal runnable application, then gradually add configuration, IoC, HTTP, and common components.