go mod init 用于声明模块根路径和版本边界，需在项目根目录执行并指定可解析的模块路径；init() 函数仅适用于包级副作用初始化，不可替代显式初始化逻辑。
Go 1.11+ 后，go mod 是唯一推荐的模块管理方式；init() 函数仅用于包级副作用初始化，不能替代模块加载逻辑。
如何正确初始化一个 Go 模块（go mod init 的实际用法）
模块初始化不是“启动项目”的动作，而是为当前目录声明一个模块根路径和版本边界。它不自动拉取依赖，也不影响运行时行为。
- 在项目根目录执行
go mod init example.com/myapp—— 模块路径应是可解析的、未来可能被他人import的 URL 形式（即使不托管） - 如果目录已有
go.mod，重复执行会报错；想重置？先删掉go.mod和go.sum - 模块路径不必对应真实域名，但若将来要发布到公共仓库，必须能被
go get解析（例如github.com/user/repo） -
go mod init不会扫描源码，所以初始go.mod中不会出现require条目；首次go build或go run才会自动写入依赖
init() 函数该在什么场景下使用
init() 是 Go 包加载时自动调用的函数，每个包可有多个，按依赖顺序执行。它不接受参数、无返回值，且不可显式调用。
- 适合做：注册驱动（如
database/sql的_ "github.com/lib/pq"）、预热全局缓存、校验常量约束、设置日志默认格式 - 不适合做：连接数据库、读配置文件、启动 HTTP 服务 —— 这些应放在
main()或显式初始化函数中，否则测试时无法控制时机，且违反依赖可测性 - 多个
init()函数在同一个包内，按源文件字典序执行；不同包间按导入依赖图拓扑排序 - 注意：
init()中 panic 会导致整个程序启动失败，且堆栈不包含业务调用链，排查困难
包结构设计中常见的初始化陷阱
Go 没有“模块初始化钩子”，所有初始化逻辑最终都落到包或 main 中。错误的设计会让代码难以测试、复用和调试。
立即学习“go语言免费学习笔记（深入）”；
- 把配置加载写在
init()里 → 环境变量或文件路径变更时无法重载，单元测试需提前设置环境，耦合严重 - 在
utils/包里放带副作用的init()→ 其他项目 import 该包时意外触发初始化，产生隐蔽依赖 - 用
var _ = initSomething()模拟 init 调用 → 实际上只是声明一个未使用的变量，根本不会执行右边表达式（除非是函数调用赋值给变量） - 期望
go mod tidy自动发现并添加间接依赖 → 它只处理显式 import，未被引用的依赖不会出现在go.mod中
package main
import (
"fmt"
"log"
)
// 错误：在 init 中读文件，测试不可控
func init() {
// data, _ := os.ReadFile("config.json") // 不要这样
}
// 正确：暴露显式初始化函数
type Config struct{ Port int }
var globalConfig Config
func LoadConfig() error {
globalConfig = Config{Port: 8080} // 模拟加载逻辑
return nil
}
func main() {
if err := LoadConfig(); err != nil {
log.Fatal(err)
}
fmt.Println("port:", globalConfig.Port)
}
真正难处理的是跨包初始化顺序与副作用隔离——比如 A 包 init 注册了某个全局 handler，B 包 init 又覆盖了它，这种隐式依赖几乎无法静态分析。最稳妥的方式，始终把初始化逻辑收口到明确的函数，并由 main() 或 DI 容器统一调度。
