Go适合高并发低延迟服务端，不适合GUI或脚本；net/http可支撑百万级API，但须设Read/WriteTimeout、用json.NewEncoder返回JSON、用sync.WaitGroup和带缓冲channel管控goroutine、微服务通信优先gRPC或HTTP/JSON而非net/rpc。
Go语言适合做需要高并发、低延迟、强稳定性的服务端系统，不适合写图形界面主程序或胶水型脚本。
用 net/http 快速起一个生产可用的 API 服务
不是所有 HTTP 服务都得上框架。标准库 net/http 足够支撑日均百万请求的 RESTful 接口，关键是别踩“阻塞主线程”和“不设超时”的坑。
- 直接用
http.ListenAndServe启动的服务没有读写超时，客户端卡住或网络抖动会导致连接堆积——必须包装成http.Server实例并设置ReadTimeout和WriteTimeout - 路由用
http.HandleFunc没问题，但路径参数（如/user/:id）得自己解析；真要动态路由，不如直接上gin或chi，省去手动strings.Split(r.URL.Path, "/")的易错操作 - 返回 JSON 别用
fmt.Fprintf拼字符串，务必用json.NewEncoder(w).Encode(data)，否则中文乱码、结构嵌套深时容易 panic
并发任务别只靠 go func() {}() 就完事
启动 goroutine 简单，但没管控就等于放任资源泄漏。常见错误是“启了一堆 goroutine，main 函数却提前退出”，或者“channel 不关导致接收方死锁”。
- 批量任务用
sync.WaitGroup配合defer wg.Done()，别在 goroutine 外部调wg.Wait()后再启动新 goroutine - 带结果的并发场景，优先用带缓冲的 channel（如
make(chan Result, 100)），避免发送方因接收方未就绪而阻塞 - 用
context.WithTimeout包裹整个 goroutine 组，而不是只包单个函数调用——超时控制要落在任务入口，不是内部某次http.Get
微服务间通信慎用 net/rpc，优先走 HTTP/JSON 或 gRPC
net/rpc 是 Go 标准库里的 RPC 实现，但默认基于 Gob 编码，跨语言几乎不可用，且不支持流式响应、中间件、重试等现代需求。
立即学习“go语言免费学习笔记（深入）”；
- 内部服务互通，推荐
gRPC-Go+ Protocol Buffers：性能好、IDL 清晰、天然支持 streaming 和拦截器 - 对外暴露接口或与非 Go 服务联调，坚持用
net/http+ JSON，别为了“RPC 感觉”硬套net/rpc导致调试困难 - 如果只是简单状态上报（比如健康检查），用
http.Get轮询比搞一套rpc.Register更轻量、更可观测
真正难的不是写一个能跑的 Go 程序，而是让 goroutine 不泄漏、HTTP 连接不堆积、Context 取消信号能穿透到最底层 I/O。这些细节不会报错，但会在流量高峰时突然放大成雪崩。
