go程序实际从runtime.main开始执行，而非func main()；改main签名编译通过但链接失败，因链接器只认零参零返回的main.main符号；init阻塞或panic会导致启动卡住；非package main中的func main()被忽略；main返回后所有goroutine立即终止。

Go 程序根本不会从你写的 func main() 开始执行——它只是 runtime 启动流程中被调用的最后一个用户函数。

为什么改了 func main() 签名，编译不报错但链接失败？

Go 编译器（go tool compile）只检查语法合法性，func main(args []string) 或 func main() int 在语法上完全合法，所以能通过编译。但链接器（cmd/link）在生成可执行文件时，会严格查找符号 main.main，且只认零参数、零返回值的 ABI 约定。

• undefined reference to main.main 是链接阶段的 fatal error，不是 warning
• 常见诱因：C/Python 背景开发者下意识加参数，或想用返回值传退出码
• 正确做法：命令行参数走 os.Args 或 flag 包；退出码用 os.Exit(n)

程序启动卡住，断点打不到 main 第一行，问题在哪？

因为 main 根本还没轮到执行。真实入口是 runtime.main，它必须先完成三件事：全局变量初始化 → 所有 <code>init 函数按依赖顺序执行 → 运行时调度器准备。任一环节阻塞或 panic，进程就停在那里。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

• 典型卡点：init 里同步 HTTP 请求、读未就绪的配置文件、向无缓冲 chan 发送、对 nil map 赋值
• init 函数无法 recover，panic 会直接终止进程，堆栈里甚至不出现 main
• 调试建议：用 go tool compile -S main.go 确认入口是 runtime.main；再用 gdb ./main -ex "b runtime.main" -ex r 单步跟进

package main 以外的 func main() 会被忽略吗？

会被完全忽略——它只是个普通函数，和 func helper() 没区别。Go 构建系统只扫描 package main 下的 func main() 作为入口。

• 放在 package utils 或 package server 里的 func main() 不触发任何错误，但 go run . 会报 no Go files in current directory（如果当前目录没 package main）
• _test.go 文件里写 package main + func main() 会参与构建，导致 multiple main packages 错误
• 多命令场景（如 CLI 和 API）应拆成子目录：cmd/cli/main.go、cmd/api/main.go

main 函数返回后，其他 goroutine 还在跑吗？

不会。只要 main 函数返回，runtime.main 就会调用 exit(0) 终止整个进程，所有正在运行的 goroutine（包括后台定时器、HTTP server、goroutine leak）都会被立即杀死。

• 这不是优雅退出——没有机会执行 defer、close 或清理逻辑
• 若需等待后台任务，必须显式同步：sync.WaitGroup、context.WithTimeout、或阻塞在 select{}
• 最容易被忽略的一点：即使 main 函数体为空，整个初始化链路（所有 init 和运行时准备）仍会完整执行，这决定了冷启动耗时下限

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！