是，但仅限于TLS场景下连接成功协商出h2时；需用ListenAndServeTLS、正确配置NextProtos为["h2"]、证书可读且含有效SAN，客户端支持ALPN并信任证书链。
Go 语言里配置 ALPN 协议协商，不是“加个 NextProtos 就完事”，而是必须和 TLS 启动方式、证书合法性、客户端行为三者对齐。漏掉任一环，ALPN 就不会生效，连接会静默降级到 HTTP/1.1 或直接失败。
ALPN 必须通过 TLS 启动才起作用
Go 标准库从 1.6 起支持 HTTP/2，但 ALPN 协商只在 TLS 连接中发生。这意味着：
-
http.ListenAndServe(":8080", handler)→ 永远没有 ALPN，NextProtos设置无效 -
http.ListenAndServeTLS(":8443", "server.crt", "server.key", handler)→ 自动启用 ALPN，"h2"已内置，无需手动设置NextProtos - 若用自定义
http.Server，必须调用srv.ListenAndServeTLS()，而非srv.ListenAndServe()；否则即使TLSConfig.NextProtos设了[]string{"h2", "http/1.1"}，也完全不触发 ALPN
NextProtos 不该手动设，除非你明确需要非标准协议
Go 1.8+ 已将 "h2" 和 "http/1.1" 写死进默认 ALPN 列表，显式配置反而可能引入兼容问题：
- 手动设
NextProtos: []string{"h2"}会**移除**"http/1.1"，导致只支持 HTTP/2 的客户端（如某些旧版 curl）握手失败 - 共端口场景（如 HTTPS + MQTT）才需显式声明多个协议：
NextProtos: []string{"h2", "http/1.1", "mqtt"}，且服务端必须真正实现对应协议路由逻辑 - 设错顺序（如把
"mqtt"放最前）可能导致 HTTP 客户端被误判为 MQTT 流量而断连
证书和客户端必须配合 ALPN 行为
ALPN 协商成功 ≠ 协议真正跑起来。常见断裂点在证书或客户端配置：
立即学习“go语言免费学习笔记（深入）”；
- 自签名证书必须含正确的
Subject Alternative Name（如DNS:localhost），否则 Go 客户端在 TLS 握手阶段就拒绝继续，根本走不到 ALPN 协商 - 客户端用
http.Client时，若服务端证书是自签名的，必须显式设置TLSClientConfig.RootCAs，否则crypto/tls会在验证证书链时失败，ALPN 不会被触发 - curl 验证 ALPN 是否生效：用
curl -v --http2 https://localhost:8443/，看到Using HTTP2和ALPN, offering h2才算真通；仅看响应头HTTP/2 200不够，可能是服务端伪造
ALPN 错误日志可能泄露攻击者控制内容
Go 1.25.2+ 修复了 CVE-2025-58189，但旧版本或未升级环境仍存在风险：
- 当客户端发送非法 ALPN 协议名（如含换行符、控制字符），服务端
conn.Handshake()返回的错误可能包含未转义的原始输入 - 若代码直接将该错误写入日志（如
log.Printf("TLS handshake failed: %v", err)），可能造成日志注入 - 安全做法是：捕获
tls.AlpnError类型错误，只记录固定提示，或对错误消息做白名单过滤（如只允许字母、数字、斜杠）
ALPN 看似只是协议列表开关，实际是 TLS 握手后期的关键环节，它依赖证书有效性、服务端启动方式、客户端信任链三者全部就位。最容易被忽略的是：证书 SAN 缺失或客户端 RootCAs 未加载，这两处出问题时，ALPN 根本没机会开始协商。
