go run 用于开发调试，临时编译执行、不生成文件、路径行为不稳定；go build 生成独立二进制，支持交叉编译与静态链接，是生产部署唯一可靠方式。
go run 和 go build 的区别到底在哪
不是“哪个更好”，而是“什么时候该用哪个”——go run 适合快速验证逻辑，go build 才是交付生产环境的唯一路径。
常见错误现象：本地 go run main.go 跑通了，一上服务器执行编译后的二进制就 panic，往往是因为忽略了 go build 默认不包含 CGO_ENABLED=0，导致在 Alpine 镜像里因缺失 libc 而失败。
-
go run是解释式执行：它会临时编译 + 运行，不生成可执行文件，也不校验跨平台兼容性 -
go build -o myapp生成静态链接二进制：默认关闭 cgo（除非显式启用），适合容器部署 - 想交叉编译？必须用
go build，且需提前设置GOOS和GOARCH，比如GOOS=linux GOARCH=arm64 go build -o app-arm64 - 调试时别依赖
go run的日志输出顺序：它可能掩盖 goroutine 调度真实行为，真正压测前务必用go build启动
map 并发读写 panic 怎么定位和修复
错误信息固定是 fatal error: concurrent map writes 或 concurrent map read and map write，但根源常被误判为“用了多个 goroutine”，其实关键在“是否共享同一底层 map 实例”。
典型场景：Web 服务中把 map[string]interface{} 当作请求上下文缓存，不同 handler 并发写入；或微服务里用全局 map 存 token 白名单，没加锁就直写。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 最轻量解法：用
sync.Map替代原生map，但它只适合读多写少，且不支持遍历全部 key - 更通用方案：封装成带
sync.RWMutex的结构体，读用RLock()，写用Lock() - 别在 defer 里 unlock：容易漏写或顺序错乱，建议用辅助函数包裹 lock/unlock 逻辑
- 测试时用
go test -race能直接暴露竞争点，比线上报错早得多
goroutine 泄漏为什么比内存泄漏更难发现
因为泄漏的 goroutine 不占堆内存，pprof heap 看不到，但 runtime.NumGoroutine() 持续上涨、CPU 空转、连接数卡死，往往是它在作祟。
高频泄漏模式：channel 接收端没读、select 默认分支没处理、http handler 里启 goroutine 但没控制生命周期、context 超时没传递到子 goroutine。
- 上线前必加指标：用
expvar.NewInt("goroutines")定期上报runtime.NumGoroutine()，突增即告警 - 查泄漏首选
pprof/goroutine?debug=2，看堆栈里大量 goroutine 停在chan receive或select上 - 所有 goroutine 启动前，必须绑定 context，并在入口处
select { case - 避免在循环里无限制
go func() {}()，改用 worker pool 控制并发数
微服务间调用该选 gRPC 还是 HTTP/JSON
不是“谁更先进”，而是“你的链路里有没有强契约约束和性能敏感点”——gRPC 天然适合内部服务通信，HTTP/JSON 更适合作为对外 API 层。
常见误用：用 gRPC 对接第三方支付回调（对方只支持 POST JSON）、或用 HTTP/JSON 传超大 protobuf 消息（序列化开销翻倍、gzip 压缩率低）。
- 选 gRPC 的硬条件：双方都可控、IDL 统一、需要流式响应（如订单状态推送）、对延迟敏感（平均 RT
- 选 HTTP/JSON 的合理场景：前端直连、需浏览器兼容、要利用 CDN 缓存、调试方便（curl 就能测）
- 混用没问题：内部用 gRPC，对外网关层用 HTTP/JSON 转换，但注意错误码映射——gRPC 的
codes.NotFound别直接转成 HTTP 200 - 别忽略 transport 层细节：gRPC 默认用 HTTP/2，若中间有老版 Nginx（未开启 h2 支持），会静默降级成 HTTP/1.1，导致 stream 失效
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
