go中同一文件多个init函数按源码出现顺序执行，不可互相调用；跨包按导入依赖拓扑序执行，main包init最后运行；init内panic导致程序立即终止，不可recover。
同一个文件里多个 init 函数怎么执行？
Go 里一个文件可以写多个 init 函数，它们按**源码出现顺序**依次执行，不是按字母或声明顺序。这点容易被忽略，尤其当人眼扫代码时误以为“后面定义的会后跑”。
常见错误现象：panic: runtime error: invalid memory address，实际是因为某个 init 里用了还没初始化的包级变量，而那个变量在另一个 init 里才赋值。
- 同一文件中，
init函数之间不能互相调用（语法报错） - 如果依赖关系明显（比如 A 初始化要读 B 的值），就把 B 的初始化逻辑提前写在前面
- 不推荐靠多
init拆分逻辑——可读性差，调试困难；真要分步，改用普通函数 + 显式调用更可控
不同包之间的 init 执行顺序怎么确定？
Go 编译器按**导入依赖图的拓扑序**执行 init：先执行被依赖包的 init，再执行当前包的。也就是说，import "net/http" 的包，一定在 net/http 自己的 init 跑完之后，才轮到自己包里的 init。
使用场景：想在程序启动时注册自定义 HTTP handler 或配置日志，默认 init 就是自然入口；但要注意，如果两个包互相 import（循环依赖），编译直接失败，根本不会走到 init 阶段。
-
main包的init总是最后执行（因为它不被其他包 import） - 标准库如
fmt、net的init会在你第一次 import 它们时触发，且只触发一次 - 如果你在
init里启动 goroutine 或打开文件，得确认依赖包是否已完成初始化（比如os.Args已就绪，但flag.Parse()还没调，别指望命令行参数）
init 里 panic 会导致什么？
只要任意一个 init 函数 panic，整个程序立即终止，输出 panic 信息后退出，连 main 都不会进入。这不是“异常捕获能兜住”的情况，是启动阶段硬失败。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
常见错误现象：本地跑得好好的，部署到容器里就 crash，查日志只看到 panic: failed to load config —— 很可能 init 里读了不存在的配置文件路径，而该路径在容器里并不存在。
-
defer在init中无效，无法 recover panic - 不要在
init里做不可逆操作（比如删库、发请求），出错没法回滚 - 调试时可以用
go build -gcflags="-m" main.go看编译器是否内联或优化掉某些 init 行为（极少见，但存在）
什么时候不该用 init？
当初始化逻辑需要参数、需要错误返回、或者可能失败但你想重试/降级时，init 就不合适。它签名固定为 func()，没入参，没返回值，失败即终结。
性能影响不大，但兼容性和可测试性会变差：单元测试很难单独跑某个包的初始化逻辑，也没法 mock 全局状态。
- 替代方案：提供一个
Setup()或MustInit()函数，在main开头显式调用 - 如果只是注册驱动（如
database/sql），用init没问题；但要是加载 YAML 配置，建议挪到main里，并检查err - 跨平台路径拼接（比如
filepath.Join("conf", "app.yaml")）别放在init，因为工作目录可能未定，相对路径行为不确定
真正难处理的，是那些隐式依赖——你以为 A 包的 init 已经跑完，结果它内部又 lazy 初始化了某全局对象，而那个对象的首次访问发生在你的 init 之后。这种时序陷阱，光看代码很难发现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
