是的，Nginx 开启 HTTP/3 对 CPU 的消耗确实会显著增加。在实际的高并发场景下，处理同等 QPS（每秒查询率）的请求，HTTP/3 的 CPU 负载可能是 HTTP/2 的 2 到 3 倍。

这种高昂的计算成本主要源于 HTTP/3 底层的 QUIC 协议在架构设计上的根本性改变：

1. 运行模式从“内核态”降级到“用户态”
   传统的 TCP 协议已经在互联网上运行了几十年，各大操作系统的内核以及网卡的硬件层面（如 TCP Offload Engine）都对其进行了极致的底层优化，处理 TCP 流量几乎不怎么消耗 CPU。而 QUIC 协议是在用户态（User Space）实现的，Nginx 需要在用户态自行处理复杂的拥塞控制、丢包重传和流控逻辑，这直接导致了 CPU 开销的飙升。
2. 强制且高强度的加密运算
   HTTP/3 强制要求所有连接必须使用 TLS 1.3 进行加密，没有任何明文传输的可能。在用户态频繁进行高强度的加解密运算，极大地消耗了服务器的计算资源。
3. 复杂的连接管理机制
   QUIC 引入了连接迁移、Connection ID 动态更新、无状态重试（Stateless Retry）等机制来保障弱网体验和防范攻击。这些机制虽然提升了网络穿透率和安全性，但也增加了 Nginx 维护连接状态和进行数据包处理的计算负担。

缓解 CPU 压力的优化建议：
如果您决定在生产环境部署 HTTP/3，可以通过以下系统级和 Nginx 层面的配置来缓解 CPU 压力：
开启 UDP 硬件卸载：在 Linux 系统中开启 UDP 的 GRO（通用接收卸载）和 GSO（通用分段卸载）功能（需 Linux ≥ 5.19 内核），并在 Nginx 中配置 quic_gso on;，将部分 UDP 处理工作交由网卡硬件完成。
优化 CPU 亲和性：在 Nginx 配置中开启 worker_cpu_affinity auto; 自动绑定 CPU 核心，并配合 reuseport on; 减少多核之间的锁竞争，充分利用多核性能。
调整系统内核参数：适当增加操作系统的 UDP 读写缓冲区大小（如 net.core.rmem_max 和 net.core.wmem_max），减少因缓冲区不足导致的频繁内存分配与上下文切换。