在 go 的 net/http 中，若在 handler 函数内启动新 goroutine 并调用 writeheader，会导致主线程与子 goroutine 竞态写入响应头，触发“multiple response.writeheader calls”错误。根本原因在于 http 服务器会在 handler 返回时自动补发状态码 200，而子 goroutine 又手动调用一次，造成重复。
HTTP 处理器（http.HandlerFunc）的执行模型是每个请求由独立 goroutine 承载，且 net/http 包对响应生命周期有严格约定：
- 若 Handler 函数返回前未调用 WriteHeader()，也未调用 Write()，则服务器会自动发送 200 OK 响应头；
- 若 Handler 已调用 WriteHeader() 或 Write()（后者隐式触发 WriteHeader(200)），则服务器不再干预；
- 但一旦响应头已写出，再次调用 WriteHeader() 就会 panic 并记录 http: multiple response.WriteHeader calls 错误。
在你的代码中，匿名 Handler 函数如下：
func(w http.ResponseWriter, r *http.Request) {
fmt.Println(r.URL)
go HandleIndex(w, r) // ⚠️ 启动并发 goroutine，但自身立即返回
}该函数打印 URL 后立刻启动 HandleIndex 并不等待，随即结束。此时 net/http 认为 Handler 已完成处理，自动写入 200 OK 响应头；与此同时，HandleIndex 在另一 goroutine 中执行 w.WriteHeader(200) —— 两次写入冲突，错误必然发生。
更严重的是：http.ResponseWriter 不是线程安全的，跨 goroutine 使用同一 ResponseWriter 实例不仅会触发 header 冲突，还可能导致响应体写入混乱、数据截断甚至 panic。
✅ 正确做法是：所有响应操作（包括 WriteHeader 和 Write）必须在同一个 Handler goroutine 中完成。如需异步逻辑（例如日志上报、消息队列投递、耗时计算），应确保它们不干扰响应流：
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Println("Handling:", r.URL.Path)
// ✅ 同步写入响应（必须在当前 goroutine）
w.WriteHeader(200)
_, _ = w.Write([]byte("Hello, World!"))
// ✅ 异步任务：启动 goroutine，但绝不操作 w！
go func() {
// 例如：记录访问日志到文件/数据库、发送监控指标等
log.Printf("Async handled: %s from %s", r.URL.Path, r.RemoteAddr)
}()
})
log.Println("Starting Server on :5678...")
log.Fatal(http.ListenAndServe(":5678", nil))
}⚠️ 注意事项：
- 不要将 ResponseWriter 传递给其他 goroutine；
- 不要在 Handler 中 go handle(w, r) —— 这是典型反模式；
- 如需真正异步响应（如长轮询、SSE、WebSocket），应使用专用库（如 gorilla/websocket）或显式管理连接生命周期；
- Chrome 自动请求 /favicon.ico 是另一个常见诱因（你日志中出现两次输出即源于此），可通过添加 favicon 路由或忽略该路径规避干扰测试。
总结：Go 的 net/http 设计强调「Handler 即响应单元」——它必须原子性地完成响应构建。把 WriteHeader 和 Write 放进 goroutine，本质上破坏了这一契约。坚守同步响应 + 异步副作用的分工原则，即可彻底避免此类错误。
