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，虽不影响其他请求，但资源利用率低、超时风险高。

• 对外部 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 取消传播。