Go命令报command not found的根本原因是PATH未正确配置，需将/usr/local/go/bin等Go二进制目录添加至shell配置文件（如macOS的~/.zshrc或Linux的~/.bashrc），并执行source命令重载配置，同时确认shell类型与配置文件匹配。
Go 1.21+ 安装后 go 命令仍报 command not found？
不是 PATH 没配对，而是 shell 启动文件没重载。macOS 上用 zsh 默认读 ~/.zshrc，但新终端可能继承旧环境；Linux bash 用户常漏掉 source ~/.bashrc。确认安装路径（如 /usr/local/go/bin）已写入对应配置文件后，直接运行 source ~/.zshrc 或 source ~/.bashrc，再测 go version。
常见错误现象：which go 返回空，但 /usr/local/go/bin/go 确实存在；或 go env GOROOT 显示路径正确，go 却不可执行。
- 检查当前 shell 类型：运行
echo $SHELL - 确认写入的是该 shell 的初始化文件（zsh →
~/.zshrc，bash →~/.bashrc） - 避免在
~/.profile中写 PATH 后不重启登录会话（尤其 GUI 终端）
用 runtime/pprof 抓 CPU 占用高点，但 profile 文件为空？
默认情况下 pprof.StartCPUProfile 只对当前 goroutine 生效，且需手动调用 StopCPUProfile 才写入数据。如果程序启动即退出、或未显式停止，文件就是空的。
典型使用场景：调试 CLI 工具中某段耗时逻辑，不想改主流程，只临时加 profiling。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须成对调用：
pprof.StartCPUProfile(f)和defer pprof.StopCPUProfile()（注意 defer 在函数返回时才触发） - 文件打开要用
os.Create，不能用os.OpenFile以os.O_WRONLY模式——后者在无内容时可能创建 0 字节文件 - CPU profile 需要至少 50ms 采样时间，短于这个阈值很可能无数据；可在关键逻辑前后加
time.Sleep(100 * time.Millisecond)测试
想用 go tool pprof 分析火焰图，但提示 failed to fetch any profiles？
这不是 pprof 工具问题，而是 profile 数据格式或路径不对。Go 1.21+ 默认生成的是 protocol buffer 格式（profile.proto），老版本 pprof 或非 Go 工具可能不识别；同时，go tool pprof 默认尝试从 HTTP 接口拉取，而非读本地文件。
正确做法是明确指定输入源类型：
- 分析本地文件：
go tool pprof -http=:8080 your_binary cpu.pprof（注意顺序：工具在前，二进制在前，profile 文件在后） - 若 profile 是从
net/http/pprof接口导出的，确保 URL 带完整路径，例如：go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 - 火焰图依赖
dot（Graphviz），macOS 用brew install graphviz，Ubuntu 用apt install graphviz，缺了会 fallback 到文本视图
自定义脚本里混用 pprof.Lookup("goroutine") 和 WriteTo，结果堆栈缺失？
pprof.Lookup("goroutine").WriteTo 默认只输出 summary（即 goroutine 数量），不是完整堆栈。要获取所有 goroutine 的调用栈，必须传 1 作为第二个参数。
这个参数容易被忽略，因为文档里写的是 debug，实际含义是“是否输出完整栈帧”：
-
WriteTo(w, 0)→ 只输出统计行（如 “1234 goroutines”） -
WriteTo(w, 1)→ 输出全部 goroutine 的 stack trace（含 runtime 包调用） - 若只想看用户代码栈，后续可用
grep -v "runtime/"过滤，但别在 WriteTo 阶段丢掉数据
性能影响很小，但少传一个参数就白跑了整个采集流程。
