尬住了，Go HTTP/3 又又被搁置了！

原创于 2025-10-27 13:43:39 发布 · 932 阅读

CC 4.0 BY-SA版权

文章标签：

Go HTTP/3 的推进，可以说是 "起了个大早，赶了个晚集"。2019 年就有人提议，2025 年提案又被搁置，这个过程确实有点魔幻。但换个角度想，这也是 Go 一贯的风格：稳字当头，又或是 ”less is more“。至于什么时候能在标准库中用上 HTTP/3，就看 Go 核心团队的魄力和资源分配了。

2024 年，Go 核心团队成员 @neild 提交了一个新提案 #70914[1]，打算在 x/net/http3 中添加 HTTP/3 的实验性实现。

图片

本以为这次也算是正式启动了。能有些苗头。结果万万没想到，这个提案能又被半路搁置了！

图片

要知道，这已经不是 Go HTTP/3 第一次 "跳票" 了。

背景：多年的苦等

说起来挺无奈的，Go 社区对 HTTP/3 的呼声由来已久。早在 2019 年 5 月，社区就开了 Issue #32204[2] 来追踪 HTTP/3 在标准库中的实现进度。那时候 HTTP/3 还只是 IETF 的草案，大家也能理解官方的谨慎态度。

图片

但是现在都 2025 年了！HTTP/3 早在 2022 年 6 月就被 IETF 正式发布为提议标准(RFC 9114)了，主流浏览器的支持率已经超过 95%，全球前 1000 万网站中也有 34%支持了 HTTP/3。

图片

简单来说，HTTP/3 已经不是什么"新鲜玩意儿"了，它是实打实的生产级协议。可 Go 官方在标准库层面，依然没有动静。

提案内容：看似稳妥的方案

我们来看看 @neild 这次提出的方案到底是什么。

这个提案的思路其实挺保守的，和之前被接受的 QUIC 提案 #58547[3] 基本一致：

先在 x/net/internal/http3 中实验性开发
等 API 稳定后，再移到 x/net/http3 供外部测试
最后提交正式的 API 审查提案

这个策略看起来很稳妥对吧？先内部折腾，等成熟了再放出来。照理说应该问题不大。

但是很无奈的是，就是这么个稳妥的方案，也被搁置了！也是绝了。

社区讨论：无奈与不解

在 Issue #32204 的讨论中，我们能看到社区对这个问题的长期关注。

主要包含以下几种态度/想法：

1、时间线： 2020 年，Brad Fitzpatrick 就在评论中提到过，Go 团队在观望 HTTP/3 的成熟度。现在 5 年过去了，HTTP/3 早就从草案变成了正式标准，主流语言和框架也都有了成熟实现。

2、生态问题：目前想在 Go 中使用 HTTP/3，只能依赖第三方库 quic-go[4]。这个库做得确实不错，实现了完整的 QUIC 和 HTTP/3 支持：

复制

package main

import (
    "github.com/quic-go/quic-go/http3"
    "log"
    "net/http"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello, HTTP/3!"))
    })

    // 启动 HTTP/3 服务器
    log.Fatal(http3.ListenAndServeQUIC(
        "0.0.0.0:8443",
        "/path/to/cert.pem",
        "/path/to/key.pem",
        mux,
    ))
}

但问题在于:

第三方库的维护周期和 Go 官方不一致
没有标准库的背书，企业级项目用起来总是有顾虑
API 设计上无法和 net/http 无缝集成

3、多语言对比：隔壁 Rust、C++、Java、C# 等语言，人家早就把 HTTP/3 支持做进标准库或官方库了。Go 作为云原生时代的代表语言，在网络协议支持上反而显得保守，这确实让人有点心里不平衡。

为什么又又被搁置？

那问题来了，为什么一个看起来如此合理的提案，会被搁置呢？

根据 Go 团队的处理风格，我推测可能有这么几个原因：

1. API 设计的复杂性

HTTP/3 基于 QUIC 协议，和传统的 TCP 有本质区别。要让它和现有的 net/http 优雅地集成，不是简单加几个接口就能搞定的。

举个例子，HTTP/3 的连接是基于 UDP 的，这意味着：

TLS 握手方式不同(使用 QUIC 的 TLS 1.3)
连接迁移特性需要特殊处理
流控机制完全不同

这些都需要在 API 设计上仔细考虑。

2. 向后兼容的压力

Go 一直以向后兼容闻名，这是好事，但也带来了设计上的约束。HTTP/3 的 API 怎么设计，既要考虑现有 net/http 用户的习惯，又要支持 HTTP/3 的新特性，这是个难题。

看看在 Go1.24 加入的 HTTP 版本选择 API te'xing #67814[5] 就知道了：

复制

type Protocol uint64

const (
    HTTP1 Protocol = (1 << iota)
    HTTP2
    // HTTP3 还没有...
)

// Server 可以选择支持的协议
s := &http.Server{}
s.Protocols = HTTP1 | HTTP2

// Transport 也可以选择
tr := &http.Transport{}
tr.Protocols = HTTP1 | HTTP2