Why does a Go build that works locally fail in CI when GO111MODULE is enabled?

In Go 1.16 the GO111MODULE variable defaults to on, enabling module‑aware mode even when no go.mod file is present. Locally, a writable go.mod allows go build to succeed because the tool can satisfy dependencies from the existing module file. In a CI environment the go.mod may be read‑only, missing, or the filesystem may prevent updates, causing go build to report an error when a module requirement or checksum would need to be added or updated. This discrepancy leads to a build that works on a developer machine but fails in production pipelines. The goal is to understand how the module mode behaves under these differing conditions and what factors determine whether the build succeeds or fails.

How does GO111MODULE=on affect go build when no go.mod is present? Why does a writable go.mod allow the build to succeed locally while a read‑only or absent go.mod causes failure in CI? What configuration or environment changes can make the behavior consistent across local and CI builds?