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 中。错误的设计会让代码难以测试、复用和调试。

• 把配置加载写在 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 容器统一调度。