局域网内无法访问公网代理时，goproxy 必须设为 direct；需配合 go111module=on、goprivate 排除私有域名，并优先使用 go mod vendor 固化依赖，或自建内网 goproxy 服务缓存公共模块。
局域网内无法访问公网代理时，GOPROXY 必须设为 direct
局域网开发常见于企业内网、隔离环境或安全审计严格场景，此时外部镜像源（如 https://goproxy.cn）根本不可达。强行配置会导致 go mod download 卡死、go get 报 no such host 或超时错误。
正确做法是显式禁用所有远程代理：
- 执行
go env -w GOPROXY=direct—— 这会跳过所有代理，直接尝试拉取原始模块地址（如https://github.com/golang/net） - 同时确保
GO111MODULE=on（Go 1.16+ 默认开启，但老脚本或 CI 可能关着，需确认） - 若项目依赖私有 Git 仓库（如
git.corp.internal/netutils），还需加go env -w GOPRIVATE=*.corp.internal，否则 go 仍会尝试走 proxy 校验 checksum
没有公网时，go mod vendor 是唯一可靠依赖管理方式
当 GOPROXY=direct 且代码仓库本身也无法从局域网访问（比如 GitHub 私有库未同步到内网 Git Server），go mod download 会直接失败。此时必须提前在有网机器上完成依赖固化：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在可联网机器上进入项目根目录，运行
go mod vendor—— 它会把所有依赖复制到项目下的vendor/目录 - 把整个项目（含
vendor/）打包拷贝进局域网机器 - 在局域网机器上设置
go env -w GOFLAGS=-mod=vendor，强制 go 命令只读vendor/，完全忽略go.mod中的 remote 路径 - 注意：
vendor/不会自动更新，后续新增依赖必须回到外网机器重新go mod vendor并同步
自建局域网 Go Proxy 需要 goproxy 服务 + 缓存策略
如果团队规模较大、频繁构建、且允许部署轻量服务，可搭一个内网 goproxy 实例。它不是简单反向代理，而是要缓存模块并支持校验：
- 下载官方
goproxy二进制（goproxy.io提供 macOS/Linux/Windows 版），或用go install github.com/goproxyio/goproxy@latest（需先在外网机器装好） - 启动命令示例：
goproxy -modules="https://goproxy.cn" -cache-dir="/data/goproxy-cache"，其中-modules指定上游镜像（仅用于首次拉取，之后全走本地缓存） - 局域网机器配置
go env -w GOPROXY=http://192.168.1.100:8080,direct（替换为实际 IP 和端口） - 关键限制：该 proxy 无法缓存私有模块（如
git.corp.internal/*），这些仍需靠GOPRIVATE+ 直连 Git Server 解决
go build 失败但没报错模块名？先检查 go.sum 校验和是否匹配
局域网环境下，go.sum 里的哈希值可能因网络中断或 vendor 同步不全而失效，导致 go build 静默失败或报 vague 错误（如 “invalid version”）。这不是语法问题，而是校验环节被卡住：
- 运行
go mod verify看是否提示某模块 checksum mismatch - 若确认依赖来源可信（比如已人工核对 vendor 内代码），可临时绕过：
go build -mod=readonly或删掉go.sum后重新go mod download（仅限外网环境） - 长期方案：所有 CI 构建机统一用
go env -w GOSUMDB=off（不推荐生产，但内网调试阶段可接受）
局域网搭建最易被忽略的点不是“怎么配”，而是“谁来维护 vendor 更新节奏”和“私有模块的 Git 访问权限是否真通”。这两项出问题，再好的 proxy 也救不了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
