直接调用 http.server.close() 会立即关闭监听 socket 并中断所有活跃请求，导致响应截断、panic 和 io.eof 错误；应改用 shutdown() 实现优雅关闭，它停止新连接并等待现有请求完成，超时后强制终止。
为什么直接调用 http.Server.Close() 会导致请求被中断
直接调用 srv.Close() 会立即关闭监听 socket，新连接被拒绝，但更重要的是——它**不会等待正在处理的请求完成**。底层 net.Listener 的 Close() 调用会触发所有活跃 net.Conn 的读写返回 io.EOF 或 use of closed network connection，导致中间件、handler 内部的 WriteHeader 或 Write panic，或返回不完整响应。
典型错误现象：write tcp 127.0.0.1:8080->127.0.0.1:54321: use of closed network connection；客户端收到截断的 JSON 或空响应；日志里出现 http: Server closed without waiting for connections to finish。
用 http.Server.Shutdown() 替代 Close() 是唯一推荐方式
Shutdown() 是 Go 1.8+ 引入的优雅关闭标准方案，它会：停止接受新连接、等待所有活跃请求完成（包括长连接上的流式响应）、在超时后强制关闭剩余连接。
实操要点：
- 必须传入一个
context.Context，超时由context.WithTimeout控制，而非Shutdown()自身参数 - 不能在 handler 里调用
Shutdown()，应在信号监听或管理命令中触发 - 需确保所有 handler 都遵守 HTTP 协议语义（比如不阻塞在无界 channel 上、不忽略
Request.Context().Done()） - 若使用自定义
http.Transport或反向代理，它们的 idle 连接池需单独处理，Shutdown()不影响它们
示例关键片段：
srv := &http.Server{Addr: ":8080", Handler: myMux}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
// 收到 SIGTERM 后
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT)
<h3>如何让长轮询、流式响应（如 SSE）也受控退出</h3>
<p><code>Shutdown()</code> 默认只等 handler 函数返回，但若 handler 在 for-select 循环中持续写入（如 <code>text/event-stream</code>），它可能永远不退出——因为连接未关闭，<code>ResponseWriter</code> 仍可写。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper"><img
src="https://img.php.cn/upload/skill/000/000/081/179025319165074.jpg" alt="Golang Spf13 Viper" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper" class="overflowclass">Golang Spf13 Viper</a>
<p class="overflowclass">Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4918" title="Golang Spf13 Viper" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<p>正确做法是：在 handler 中监听 <code>Request.Context().Done()</code>，并在该 channel 关闭时主动 break：</p>
<pre class="brush:php;toolbar:false;">func sseHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
flusher, ok := w.(http.Flusher)
if !ok {
http.Error(w, "streaming unsupported", http.StatusInternalServerError)
return
}
for {
select {
case
<p>注意：<code>r.Context()</code> 会在 <code>Shutdown()</code> 开始时被取消，无需额外同步机制。</p>
<h3>常见陷阱：TLS、Graceful Restart 和第三方库兼容性</h3>
<p>使用 <code>http.Server.TLSConfig</code> 时，<code>Shutdown()</code> 行为一致，无需特殊处理；但若用 <code>http.ListenAndServeTLS()</code> 启动，则需改用 <code>srv.Serve(tlsListener)</code> 模式才能控制 listener 生命周期。</p>
<p>Graceful Restart（零停机重启）不是 <code>Shutdown()</code> 的职责，它需要 fork 子进程、传递 fd、协调旧进程退出，应使用 <code>facebookgo/grace</code> 或 <code>cloudflare/graceful</code> 等专用库，而非自行实现。</p>
<p>某些中间件（如旧版 <code>gorilla/handlers.CompressHandler</code>）可能忽略 <code>Request.Context()</code>，导致无法及时响应关闭信号——务必检查所用中间件是否支持 context 取消。</p>
<p>最易被忽略的一点：如果服务启用了 <code>http.Server.IdleTimeout</code>，它会影响 <code>Shutdown()</code> 的等待逻辑——空闲连接会被提前关闭，但活跃请求不受影响；而 <code>ReadTimeout</code>/<code>WriteTimeout</code> 已被弃用，不应设置。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
