gops 不是性能画像工具，而是进程发现与控制代理；它不生成 profile 文件，真正做 CPU/heap/trace 分析的是 pprof 或 go tool trace。
gops 不是“性能画像”工具，它本身不生成 profile 文件，也不做采样分析；它是个进程发现与控制代理，真正做 CPU/heap/trace 分析的是 pprof 或 go tool trace。想用 gops 查内存、看栈、触发 GC，必须先在程序里嵌入 agent.Listen()，否则 gops 列出来的进程里根本看不到你的程序。
为什么 gops list 看不到我的 Go 进程？
最常见原因是没启动 gops agent。gops list 只能发现两类进程：一是显式调用了 agent.Listen() 的，二是 Go 1.20+ 编译的二进制（含内置 runtime/pprof HTTP handler，但默认不监听端口，且 gops 不自动识别这类进程）。
- 确认你已 import
"github.com/google/gops/agent"并调用了agent.Listen() - 不要用
go run启动——它会编译临时二进制，退出后 agent 文件残留且 PID 失效；改用go build && ./myapp - 检查
GOPS_CONFIG_DIR目录（默认~/.config/gops）下是否有对应 PID 文件，内容是否为有效端口号 - 若设置了
Addr: "0.0.0.0:8848"，确保防火墙没拦住该端口，且netstat -tuln | grep 8848能看到 LISTEN
gops stack 和 pprof goroutine 有什么区别？
gops stack 直接连接 agent 端口，返回当前所有 goroutine 的完整堆栈（含状态、等待原因、运行时长），响应快、无采样开销，适合快速排查死锁或 goroutine 泄漏；而 pprof 的 /debug/pprof/goroutine?debug=2 是 HTTP 接口返回的文本格式堆栈，内容结构类似，但依赖你手动暴露 net/http/pprof，且默认只返回正在运行/可运行的 goroutine（?debug=2 才全量）。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
-
gops stack不需要 HTTP server，纯 TCP，适合无 web 框架的 CLI 工具或 daemon -
pprof的 goroutine profile 可被go tool pprof解析并生成火焰图，gops stack输出只是原始文本 - 两者都反映“此刻快照”，都不做历史聚合——真要查 goroutine 增长趋势，得靠定期抓取 + diff
gops memstats 为什么和 runtime.ReadMemStats() 结果不一致？
gops memstats 底层调用的就是 runtime.ReadMemStats()，但它是通过 agent RPC 远程读取，中间有序列化/网络传输延迟；而你在代码里直接调用 ReadMemStats() 是瞬时内存拷贝。差异通常在 PauseNs、NumGC 等计数器上体现为 ±1 次 GC 的偏移，尤其当进程刚完成一次 GC 时。
- 别拿
gops memstats做精确内存对比，它适合观察趋势（比如HeapAlloc是否持续上涨） - 若发现
gops memstats显示HeapInuse很大但pprof heap里没大对象，大概率是sync.Pool或未释放的 mmap 区域——memstats统计的是 runtime 管理的堆，不含mmap直接分配的大块内存 -
gops memstats不包含pprof heap的采样信息（如分配位置、调用栈），定位泄漏还得靠go tool pprof -http=:8080 binary http://localhost:6060/debug/pprof/heap
gops，而是理解它只负责“连上去看”，不负责“分析为什么”。你得自己判断：看到一堆阻塞在 chan receive 的 goroutine，是逻辑卡死，还是 channel 容量设太小？HeapAlloc 持续涨，是缓存没淘汰，还是对象逃逸到了堆？这些没法靠工具自动告诉你。 
