What do the netgo and osusergo build tags do when cgo stays enabled?

## The problem these tags solve There are two separate things people want from `CGO_ENABLED=0`. One is a *self-contained artifact*: a single file with no libc dependency. The other is *predictable lookup behaviour*: hostname and user resolution that does the same thing on a laptop, in CI and in production, because it is Go code compiled into the binary rather than whatever the host's C library decides to do. Sometimes you cannot have the first. A dependency binds a C library, or the platform requires it, and cgo must stay on. `netgo` and `osusergo` let you take the second half anyway. ## What each tag selects The standard library ships two implementations of a small number of things, guarded by build constraints: - **`netgo`** — the `net` package has a hostname resolver written entirely in Go and a path that calls into the host C library. Without the tag and with cgo available, the decision between them is made at run time from the host's configuration. Building with `-tags netgo` fixes the choice at build time: the Go resolver, always. - **`osusergo`** — `os/user` has a pure-Go implementation that parses `/etc/passwd` and `/etc/group`, and a cgo one that calls the C library's password-database functions. `-tags osusergo` selects the Go one. Usage is ordinary `go build` tag syntax: ``` go build -tags netgo,osusergo -o app . ``` There are counterpart tags in the other direction (`netcgo` forces the C path), which is worth knowing mainly so you recognise one in someone else's build script. ## The limitation that trips people up A build tag does not turn cgo off. If *anything* in the dependency graph still uses cgo, the Go linker still hands off to the system C toolchain and you still get a dynamically linked executable that names an ELF interpreter and lists shared libraries. `file` and `ldd` will say so. That binary is still coupled to the C library it was linked against, so it still fails to start on a host with a different one. In other words: `netgo`/`osusergo` fix *which code runs*. They do not fix *what the binary needs at load time*. Teams that add `-tags netgo` hoping for a portable artifact and then find the same startup failure in production have conflated the two. The converse is also worth stating: if nothing in the build uses cgo, you did not need the tags — `CGO_ENABLED=0` already selects the same implementations and gives you the static link as well. The tags are the tool for the mixed case, not the default. ## When you actually reach for them - A service must link a C library for one feature, but its hostname lookups must behave identically everywhere. `-tags netgo` makes the resolver a property of the build rather than of the host. - You want to *remove a variable* while debugging a resolution difference between two environments: rebuild with `-tags netgo`, run the same code again, and see whether the difference survives. That A/B is often faster than reading configuration files on both hosts. - A container-style environment has no complete `/etc/passwd` and `os/user` behaves oddly; `osusergo` at least makes the behaviour the same in every environment, so you can reason about it. ## What to say about the cost Selecting the Go implementations has the same downside as disabling cgo altogether: the Go resolver understands the ordinary configuration sources but cannot load the C library's pluggable name-service modules, so names that only exist behind one of those stop resolving. The tag is not free — it is the same behavioural trade, taken deliberately, in a build that still needs cgo for other reasons. ## Checklist for an interview answer 1. They are build tags, passed with `-tags`. 2. Each pins one standard-library package to its pure-Go implementation. 3. They matter only when cgo is enabled — with `CGO_ENABLED=0` you already have those implementations. 4. They do not make the binary static, and `ldd` is how you prove that to a colleague who thinks otherwise.