Go HTTP服务器默认并发安全，每个请求由独立goroutine处理；需避免共享可变状态、阻塞操作、不安全全局资源及goroutine泄漏。
Go HTTP服务器默认就是并发安全的
Go 的 net/http 包启动的服务器天然支持高并发，每个请求由独立 goroutine 处理，不需要手动加锁或启用额外配置。只要你没在 handler 里共享可变状态（比如全局 map、未加锁的 struct 字段），就基本不会因并发出错。
常见误操作是直接在 handler 中修改全局变量：
var counter int
func handler(w http.ResponseWriter, r *http.Request) {
counter++ // ❌ 多个 goroutine 同时写，数据竞争
fmt.Fprintf(w, "count: %d", counter)
}
解决方法很简单：用 sync.Mutex 或更推荐的 sync/atomic（适用于整数计数）：
var counter int64
func handler(w http.ResponseWriter, r *http.Request) {
atomic.AddInt64(&counter, 1) // ✅ 原子操作，无锁安全
fmt.Fprintf(w, "count: %d", atomic.LoadInt64(&counter))
}
避免在 handler 中阻塞整个 goroutine
HTTP handler 运行在独立 goroutine 中，但如果你在里面做同步 IO（如未设 timeout 的 http.Get、数据库查询、大文件读取），会拖慢该 goroutine，虽不影响其他请求，但资源利用率低、超时风险高。
立即学习“go语言免费学习笔记（深入）”；
- 对外部 HTTP 请求，务必设置
context.WithTimeout和自定义http.Client - 数据库操作优先使用带 context 的方法（如
db.QueryRowContext） - 避免用
time.Sleep模拟耗时逻辑；真需要延时应配合select+context.Done()提前退出
示例：带超时的下游调用
func handler(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/data", nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
http.Error(w, err.Error(), http.StatusGatewayTimeout)
return
}
defer resp.Body.Close()
// ...
}
谨慎使用全局连接池和共享资源
像数据库连接（*sql.DB）、Redis 客户端（redis.Client）、HTTP 客户端（*http.Client）这些对象本身是并发安全的，适合全局复用。但要注意：
-
*sql.DB不需要也不应该每次请求 new 一个；它内部已管理连接池 -
http.Client应复用，并配置Transport的MaxIdleConns等参数，否则默认值过小（如 MaxIdleConns=100）可能成为瓶颈 - 自定义缓存（如
map[string]string）必须加锁或改用sync.Map（仅适合读多写少场景）
错误示范：
var cache = make(map[string]string) // ❌ 并发读写 panic
func handler(w http.ResponseWriter, r *http.Request) {
key := r.URL.Query().Get("id")
if val, ok := cache[key]; ok { // 读也需同步
w.Write([]byte(val))
}
}
正确做法之一（简单场景）：
var cache = sync.Map{} // ✅ 并发安全
func handler(w http.ResponseWriter, r *http.Request) {
key := r.URL.Query().Get("id")
if val, ok := cache.Load(key); ok {
w.Write([]byte(val.(string)))
}
}
别盲目增加 goroutine 数量
Go 的网络模型是“一个连接一个 goroutine”，调度器自动管理成千上万 goroutine，但业务层主动起 goroutine 要克制：
- 不要在 handler 里用
go fn()异步处理并立即返回——除非你确保不会访问 response writer、request、或依赖其生命周期的资源 - 若必须异步（如发日志、埋点），请用带缓冲 channel 或 worker pool 控制并发度，防止 goroutine 泛滥导致内存溢出或调度延迟
- 用
runtime.GOMAXPROCS控制并行数已不必要（Go 1.5+ 默认为 CPU 核心数），重点应放在 IO 阻塞控制和资源复用上
最常被忽略的一点：goroutine 泄漏。比如启动一个 goroutine 去监听 channel，但 channel 永远不关闭，该 goroutine 就永远无法退出——尤其在长连接、WebSocket 场景中要格外注意 context 取消传播。
