go mod init 可在离线环境成功运行，它仅生成 go.mod 文件且不依赖网络；真正需要联网的是后续的 go mod tidy 或 go build，用于下载依赖、生成 go.sum 和解析 import。
离线环境下无法执行 go mod init 后自动拉取依赖，但模块初始化本身是纯本地操作——只要 Go 二进制可用、项目目录结构合规，go mod init 就能成功生成 go.mod 文件。真正卡住的不是初始化，而是后续依赖解析和构建。
go mod init 能否在无网时运行
可以，且不需要网络。它只读写本地文件，不访问任何远程地址。
-
go mod init github.com/myorg/myapp会在当前目录生成go.mod，内容仅含模块路径和go版本声明 - 如果项目已有
.go文件，go mod init不会尝试解析 import、不下载包、不碰go.sum - 常见误判：执行后报
no required module provides package xxx，这不是init失败，而是你紧接着运行了go build或go list—— 它们才需要依赖解析
离线初始化后立即报 “cannot find module providing package” 怎么办
这是典型路径/模式错配：Go 工具链找不到你要 import 的包，因为它还没被声明为依赖，或模块未启用。
- 确认当前目录下有
go.mod，且go env GO111MODULE输出是on（Go 1.16+ 默认开启，无需手动设） - 检查 import 路径是否拼错，比如写了
github.com/sirupsen/logrus却漏了v1子路径，或用了私有仓库但没配replace - 若依赖来自私有 Git（如
git.mycompany.com/lib/utils），go mod init不会自动处理——必须提前在有网机用go mod edit -replace改成本地路径，再打包带走 - 别指望
go mod tidy在离线机上成功：它会尝试 fetch 远程模块，直接失败。离线环境里，tidy只能用于校验已有go.sum和vendor/是否覆盖全部 import
离线环境下让 go.mod 生效的硬性前提
模块机制本身不依赖网络，但它依赖两个东西：可执行的 go 命令、以及能被工具链定位到的依赖来源。
-
go必须能运行：/usr/local/go/bin/go version有输出，且架构匹配（uname -m与下载包名一致） - 依赖必须“已知”：要么通过
go mod vendor把完整vendor/目录带过来，要么把$GOPATH/pkg/mod缓存整体拷贝，并设GOPROXY=direct GOSUMDB=off - 别忽略
go.sum：即使 vendor 齐全，若go.sum缺失或版本不匹配，go build仍会报checksum mismatch—— 它必须和go.mod一起从有网机同步过来 - 如果项目用了
// +build或条件编译，确保离线机的GOOS/GOARCH与构建目标一致，否则某些包可能被跳过，导致 import 不见
最容易被跳过的点：以为 go mod init 成功就等于项目“能跑了”，其实它只是开了个空头支票；真正让模块落地的，是预打包的 vendor/ 或 pkg/mod 缓存，以及配套的 go.sum 和环境变量设置。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
