What does `go build -tags integration` change for a file whose header is `//go:build integration`?

## What the flag does `go build -tags a,b,c` adds the identifiers `a`, `b` and `c` to the set of build tags that are true while the go command evaluates build constraints. The same flag exists on `go test`, `go vet`, `go list` and the other build-flag commands, and it must be given consistently: a package built with one tag set and inspected with another is a different build. That is the whole feature. There is no registry of legal tags, no declaration, and no error for a name nothing uses — which is exactly why a typo is invisible. `-tags integratoin` succeeds and quietly builds the untagged configuration. ## Tags have no values A build tag is present or absent. There is no `-tags mode=fast`, no way to compare a tag inside an expression, and no way to read one at runtime from Go code. Engineers arriving from languages with a preprocessor look for the value form and there is not one. When a tagged build needs different data — an address, a limit, a feature switch — the data goes in the constrained file as an ordinary declaration: ``` //go:build integration package storage const backendAddr = "127.0.0.1:9000" ``` and the file with the opposite constraint declares the same constant differently. The rest of the package just uses `backendAddr` and never knows which file supplied it. ## The paired-file pattern Because exclusion removes declarations rather than disabling them, a single tagged file usually needs a partner: - `storage_integration.go` with `//go:build integration` - `storage_default.go` with `//go:build !integration` Both declare the same names. Whichever way the flag goes, exactly one is in the build, so there is never a duplicate definition and never an undefined one. If you write only the tagged half, the untagged build fails to compile the moment another file references what it defines — which is at least a loud failure. The quieter and worse case is a tagged file nothing else references: it drops out of the default build and stops being compiled, vetted or type-checked at all. ## Tags are global to the build The tag set is not scoped to your module. Every package compiled for this build, dependencies included, sees the same set. Two consequences follow. First, a tag name is effectively part of a public contract for a library: if a library documents an `integration` tag and your application uses the same word for something else, you get both behaviours at once. Prefer a distinctive name over a generic one for anything published. Second, adding a tag can *remove* files as well as add them, because a dependency may carry `//go:build !yourtag` files; a tag is a boolean input to every constraint in the build, not an additive flag. ## Choosing between a tag and a runtime switch A build tag is the right tool when the difference must not exist in the binary: code that must not link on a platform, an implementation that pulls in a heavy dependency, a file that only makes sense against a live external system. It is the wrong tool for anything that a user might want to change without rebuilding, and it is expensive in a subtler way — every additional tag doubles the number of configurations that would have to be compiled to prove the tree still builds. Most codebases can afford one or two meaningful tags; a codebase with six has combinations nobody has ever compiled. ## Reading the result rather than assuming it Because a mistyped or forgotten tag is silent, verify rather than assume: `go list -f '{{.GoFiles}}' -tags integration ./...` prints the files that are actually in the build for that tag set, and the same command without the flag prints the default set. The difference between the two is the exact effect of the flag, which is far more convincing than reading constraint lines by eye.