Go程序入口是runtime.main而非main函数，它先执行全局变量初始化、init函数（按包导入和字典序）、运行时准备，再调用用户main；main必须在main包中且无参数无返回值，否则编译或链接失败。
Go 程序的入口不是 main 函数本身，而是运行时初始化流程
Go 没有传统意义上的“从 main 开始执行”——main 函数是被 Go 运行时（runtime）调用的，而 runtime 会在真正进入 main 前完成一系列初始化：包括全局变量初始化、init 函数执行、垃圾回收器启动、goroutine 调度器准备等。
这意味着即使你写了空的 main 函数，程序仍会经历完整启动开销；且若某个 init 函数 panic，程序会在到达 main 前就退出，错误栈里甚至不会出现 main。
-
init函数按包导入顺序和文件字典序执行，同一包内多个init也严格有序 - 所有包级变量初始化表达式，在对应包的
init函数之前求值 - 跨包依赖时，被依赖包的
init一定先于依赖包执行（例如fmt的init在你自己的main包init之前）
为什么 func main() 必须在 main 包中且无参数、无返回值
这是链接器（cmd/link）和运行时约定的硬性要求。Go 编译器会检查：main 包中是否存在签名完全匹配的函数 func main()。不满足则报错 function main is undeclared in the main package，哪怕你写成 func main(args []string) 或 func main() int 都不行。
- 带参数或返回值的
main不会被识别为程序入口，编译通过但链接失败 - 非
main包里的func main()完全无效，只是个普通函数 - Go 不支持类似 C 的
int main(int argc, char *argv[])，命令行参数需通过os.Args获取
runtime.main 是真实入口，它如何调度到你的 main 函数
真正被操作系统加载后第一条执行的 Go 代码，是运行时内部的 runtime.main 函数（定义在 src/runtime/proc.go）。它由汇编启动代码调用，负责设置主线程（m）、主 goroutine（g），然后 defer 一个对用户 main 的调用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
你可以用 go tool compile -S main.go 查看汇编输出，会发现最终跳转目标是 runtime.main，而不是你的 main.main。
-
runtime.main启动后，会先执行所有init，再调用用户包的main.main - 你的
main函数执行完后，runtime.main会调用exit(0)终止进程；若mainpanic，它会捕获并打印堆栈后退出 - 无法绕过
runtime.main直接控制启动流程——比如想在main前做系统级 setup，只能塞进init，但要注意副作用和并发安全
调试时看不到 main 第一行？可能是 init 卡住了
如果程序启动后没反应、gdb/lldb 断不到你 main 的第一行，优先检查所有 init 函数：它们可能在做阻塞 I/O、死锁 channel、无限循环，或触发了未处理的 panic（比如 nil map 写入）。
用 go run -gcflags="-l" -ldflags="-linkmode=external" main.go 可禁用内联并启用外部链接器，配合 strace 观察系统调用，能快速定位卡在哪个初始化阶段。
-
go build -gcflags="-m -m"可查看变量是否被内联或逃逸，间接辅助判断init中对象构造开销 - 避免在
init里做任何需要环境（如读配置文件、连数据库）的操作——这些应推迟到main中显式处理 - 多个
init之间共享状态极易出竞态，Go 的init是单线程同步执行的，但一旦启动 goroutine 就脱离保护
main 只是冰山露出水面的一角；真正容易出问题的地方，往往藏在你看不见的 init 和 runtime.main 之间。 
