go list 和 IDE 的 Ctrl/Cmd+Click 是唯二靠谱跳转方式；go list -f '{{.Dir}}' fmt 获取真实路径；gopls 需启用 build.experimentalWorkspaceModule；internal 包不可 import 但必须读；gopark 主逻辑在 park_m 和 asm_amd64.s；-gcflags='-S -l' 查汇编；log 或断点验证执行路径；runtime 行为优先查 proc.go 注释和 dlv；关注编译器隐式插入调用。
直接跳转，别翻目录树——go list 和 IDE 的 Ctrl/Cmd+Click 是唯二靠谱路径，其他方式都在浪费时间。
用 go list 查包真实路径，别信 $GOROOT/src
模块启用后，fmt 这类标准库可能被缓存到 $GOCACHE 或 vendor 下，go list -f '{{.Dir}}' fmt 才能拿到当前项目实际加载的源码位置。VS Code 里跳转失败？先检查 gopls 是否启用了 build.experimentalWorkspaceModule，否则它会固执地往 $GOROOT 里钻，而那里早不是你正在跑的版本。
internal 包不能 import，但必须读
像 internal/bytealg、internal/poll 这些包，import 会报错，但它们的源码就在那儿，且常是关键逻辑所在：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
http.ListenAndServe看似简单，真正阻塞在net.Listener.Accept()，而它的实现藏在internal/poll.FD.Accept -
gopark函数体很短，是因为调度主逻辑在park_m和汇编 stub（asm_amd64.s）里，不看注释和汇编根本没法理解 goroutine 挂起过程 - 调试时加
-gcflags='-S'看汇编，但默认输出含大量内联和调试符号；想看清函数本体，得加-l：go tool compile -S -l main.go
验证执行路径，别靠猜
光看代码容易误判控制流，尤其是阻塞逻辑：
立即学习“go语言免费学习笔记（深入）”；
-
srv.Serve(lis)最后调的是lis.Accept()，它是系统调用，不是 Go 循环；没看到for {}不代表没循环，只是封装在底层了 - 加
log.Printf("at %s", debug.PrintStack())或在关键点打断点，比读十遍注释更直观 - 对
runtime相关行为（如 GC 触发、栈分裂），优先查proc.go注释，再配合dlv单步——IDE 跳转在这里基本失效
最易忽略的其实是“谁在调用”：标准库函数常被编译器隐式插入（比如调度检查、栈增长），不看 -gcflags='-S' 输出或 dlv disassemble，根本意识不到那行看似普通的函数调用背后发生了什么。
