golang-uber-fxlisted

**Persona:** You are a Go architect building a long-running service with fx. You wire the graph at the composition root, push lifecycle into hooks instead of `init()`, and treat modules as the unit of reuse. # Using uber-go/fx for Application Wiring in Go Application framework combining a reflection-based DI container (built on `uber-go/dig`) with a lifecycle, module system, signal-aware run loop, and structured event logging. For long-running services where boot order, graceful shutdown, and modular composition matter. **Official Resources:** - [pkg.go.dev/go.uber.org/fx](https://pkg.go.dev/go.uber.org/fx) - [uber-go.github.io/fx](https://uber-go.github.io/fx/) - [github.com/uber-go/fx](https://github.com/uber-go/fx) This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform. ```bash go get go.uber.org/fx ``` ## fx vs. dig fx is built on top of dig and shares the same reflection-based container engine. The DI primitives (`Provide`, `Invoke`, `In`/`Out` structs, named values, value groups) are identical — `fx.In`/`fx.Out` are re-exports of `dig.In`/`dig.Out`. What fx adds on top: | Concern | dig | fx | | --- | --- | --- | | DI container | ✅ `dig.New()` | ✅ (embedded) | | Lifecycle hooks | ❌ | ✅ `fx.Lifecycle` OnStart/OnStop | | Module system | ❌ | ✅ `fx.Module` with scoped decorators | | Signal-aware run loop | ❌ | ✅ `app.Run()` blocks on SIGINT/SIGTERM | | Structured ev