go模块路径必须是合法url形式（如github.com/user/proj），不能为myapp等别名；init函数禁用db连接等副作用操作，应改用显式setup()函数按依赖顺序初始化。
go mod init 后模块路径怎么选才不踩坑
模块路径不是随便起的别名，它直接决定后续 import 语句能否通过编译、依赖是否被正确解析。选错路径，go build 会报 import "xxx" is a program, not an importable package 或找不到包。
- 必须是合法的 URL 形式（哪怕不托管），例如
github.com/yourname/project或example.com/internal/api，不能是myapp或./src - 如果项目将来要开源或被其他模块引用，路径应与代码托管地址一致；内部项目可用占位域名，但需全员约定
- 执行
go mod init前确保不在GOPATH/src下，否则可能静默退回到 GOPATH 模式——先运行export GO111MODULE=on（Linux/macOS）或set GO111MODULE=on（Windows） - 初始化后立刻检查
go.mod：第一行module后的路径必须和你实际import的路径完全一致，否则构建失败
为什么不能把 db.Connect() 放在 init 函数里
因为 init() 是包加载时隐式触发的临界区，没有错误返回、无法重试、不能控制时机，而数据库连接这类操作天然带副作用和失败可能。
-
init()中 panic 会导致整个程序启动失败，且堆栈不包含业务调用链，日志里只看到runtime.main，排查困难 - 单元测试时无法跳过或 mock 这个连接，导致测试环境必须连真实 DB 或提前设好环境变量
- 多个包都写
db.Connect()到各自init()，顺序不可控，可能 A 包的init尝试用 DB 时，B 包（提供 DB 实例）的init还没跑完，结果 panic - 服务启动时若 DB 不可用，程序直接退出，没法降级或等待重试——这在云环境或 CI/CD 中尤其致命
如何用 Setup 函数实现可测、可控的层级初始化
把初始化逻辑从隐式 init() 拆出来，变成显式调用的 Setup() 函数，是解耦和可维护的关键。每个子模块提供自己的初始化入口，并按依赖顺序串起来。
- 每个包定义统一签名：
func Setup() error，比如config.Setup()加载并校验配置，logger.Setup()初始化日志器，db.Setup()建连并Ping() - 主模块（如
cmd/myapp）在main()开头集中调用：if err := config.Setup(); err != nil { log.Fatal(err) }，再logger.Setup()，最后db.Setup() - 依赖关系靠调用顺序保证，而不是靠 import 顺序或文件名——
db.Setup()必须在config.Setup()之后，因为它需要读取配置里的地址和密码 - 测试时可跳过某步：
db.Setup = func() error { return nil }，或注入 mock 客户端，不用动任何init
多个包之间初始化顺序怎么安全协调
Go 不保证跨包 init() 的精确执行点，所以靠 init() 传递状态（比如 “等 config 包 init 完我再读 Port”）本质是危险的。真正安全的做法是显式依赖 + 接口抽象。
- 避免跨包访问全局变量：
config.Port在config包的init()里赋值，但httpserver包的init()直接读它——此时config的init可能还没执行，读到 0 - 改用函数传参或接口注入：让
httpserver.NewServer(config.Config)接收已初始化好的配置结构体，而不是在内部去“找” config 包的变量 - 对强依赖项（如 DB 客户端），用
sync.Once做惰性初始化，首次使用时才建连，而非启动时硬连——既避免启动卡死，又节省资源 - 如果真要用
init()注册驱动（如database/sql），只限标准库或明确声明“init 安全”的第三方包，且不依赖其他自定义包的状态
Setup() + 明确调用链 + 接口传参，比靠编译器猜顺序靠谱得多。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
