本文是服务器环境配置记录，主题为 XAMPP 环境下启用 HTTP/2 协议，与本站易语言 / Lua / 大漠多线程主线教程无关，不影响主线内容的查阅。
前言：一个被忽略的提速项
用 Chrome 或 Edge 内置的 Lighthouse 跑性能测试时，会有一项名为「Modern HTTP」的审计提示，大意是当前站点仍在使用 HTTP/1.1，改用 HTTP/2 或 HTTP/3 预计可缩短数百毫秒的加载时间。
本站此前正是这种情况。多次优化之后，Lighthouse 的性能总分停在 94 分，LCP（最大内容绘制）为 2.7 秒，略微超过 2.5 秒的及格线。而这项被反复提示的协议升级，一直没有被处理。
本文记录在 Windows + XAMPP（Apache 2.4.58）环境下启用 HTTP/2 的完整过程，包括环境检查、配置修改、验证方法，以及一个差点导致前功尽弃的意外发现。
一、为什么 HTTP/2 能带来这么大的提升
HTTP/1.1 的排队问题
HTTP/1.1 的规则是：一个连接在同一时刻只能传输一个文件，传完才能传下一个。
为了不排队，浏览器会同时开 6 条连接。但每条连接都有握手开销，而且队头阻塞的问题依然存在——如果其中一个文件卡住了，后面的就得等。
HTTP/2 的多路复用
HTTP/2 采用多路复用：一条连接上同时传输所有文件，互不阻塞。
这项提升对「小文件很多」的页面效果最明显。本站首页正是这种结构：
9 个 CSS + 3 个 JS + 10 张轮播图 + 字体文件 = 一堆小文件
这类页面在 HTTP/1.1 下排队严重，切换到 HTTP/2 后收益最直接。实测从 Lighthouse 提示看，预计可节省约 500 至 900 毫秒。
前提条件
HTTP/2 在浏览器层面强制要求 HTTPS。本站已启用 SSL（443 端口正常），这个前提满足。
关于 HTTP/3：Apache 官方到 2.4.58 版本仍不支持 HTTP/3，需要第三方补丁模块。XAMPP 环境下不建议折腾，HTTP/2 已经能吃掉大部分收益。
二、环境检查：四条命令摸清现状
动手改配置之前，先用命令确认环境，避免改了不该改的地方。
1. 查看 Apache 版本
C:\xampp\apache\bin\httpd.exe -v
本站输出：
Server version: Apache/2.4.58 (Win64)
Apache Lounge VS17 Server built: Oct 18 2023 13:03:18
HTTP/2 需要 Apache 2.4.17 及以上，2.4.58 完全满足。
2. 检查 mod_http2 是否静态编译
C:\xampp\apache\bin\httpd.exe -l | findstr /i "http2"
本站无任何输出，说明 mod_http2 不是静态编译进 Apache 的，必须通过 LoadModule 动态加载。
3. 确认模块文件存在
dir C:\xampp\apache\modules\mod_http2.so
本站输出显示文件存在，大小 197,120 字节。
4. 确认模块当前是否被注释
findstr /n /i "http2" C:\xampp\apache\conf\httpd.conf
本站输出：
119:#LoadModule http2_module modules/mod_http2.so
154:#LoadModule proxy_http2_module modules/mod_proxy_http2.so
关键发现：第 119 行开头有 #，说明模块处于注释状态，从未加载。这正是 Lighthouse 一直报 HTTP/1.1 的根本原因。
提醒：不要仅凭印象或工具描述判断模块是否已启用，一定要用 findstr 看实际内容。# 开头即为注释，容易看漏。
三、找出虚拟主机配置所在文件
改之前必须先搞清楚：站点配在哪个文件里。如果改错了文件，重启后毫无变化，会白白浪费时间排查。
findstr /s /n /i "511yj.com:443" C:\xampp\apache\conf\*.conf C:\xampp\apache\conf\extra\*.conf
本站输出显示，两个 443 站点（www.511yj.com 与 bbs.511yj.com）都配置在：
C:\xampp\apache\conf\extra\httpd-ssl.conf
既然两个站点在同一文件，直接在主配置里全局声明一次即可覆盖，不必逐站点修改。
四、备份与修改
1. 备份配置文件
copy C:\xampp\apache\conf\httpd.conf C:\xampp\apache\conf\httpd.conf.bak
改服务器配置有导致站点无法启动的风险。备份之后，一旦出问题把 .bak 改回原名重启即可，30 秒内恢复。如果条件允许，做一次系统镜像更稳妥。
2. 修改 httpd.conf
找到第 119 行，把：
#LoadModule http2_module modules/mod_http2.so
改为（去掉开头的 #，并在下方新增一行）：
LoadModule http2_module modules/mod_http2.soProtocols h2 http/1.1
3. 为什么要保留 http/1.1
Protocols h2 http/1.1 的含义是：优先使用 h2，客户端不支持时自动降级到 http/1.1。
保留降级选项非常重要——一些老旧客户端、爬虫、监控服务不支持 HTTP/2，如果没有退路，它们会直接打不开网站。只写 Protocols h2 属于给自己埋雷。
说明：Protocols 写在主配置文件中，对所有未单独声明的虚拟主机生效。如果某个虚拟主机内部自己写了 Protocols，会覆盖全局设置，需要一并检查。
五、重启与验证
1. 重启 Apache
XAMPP Control Panel → Apache 行点击 Stop → 等待状态清空 → 再点击 Start。
不要只点 Restart。协议层的改动有时不会被 Restart 完整应用，用 Stop + Start 更可靠。
2. 浏览器验证
打开站点 → F12 开发者工具 → Network 面板 → 在表头栏（名称 / 状态 / 类型那一栏）右键，勾选 Protocol → 勾选 Disable cache → 刷新页面。
| Protocol 列显示 | 判定 |
|---|---|
h2 |
启用成功 |
http/1.1 |
未生效，需排查 |
本站改造后，Protocol 列全部显示 h2，HTTP/1.1 的提示消失，启用成功。
六、一个意外发现：服务器装了云锁
在查阅 httpd.conf 完整内容时，发现文件末尾有这样一行：
LoadModule agent_apache_filter "C:\Program Files (x86)\YunSuo\YunSuoAgent\x64\agent_apache_filter_2.4.dll"
这是云锁（YunSuo）WAF 的 Apache 过滤模块，正在运行中。
这一点值得记录，原因有两个：
① 它解释了此前的 403 现象。多次用非浏览器方式请求本站域名，全部返回 403，一度以为是服务器配置问题，实际是 WAF 拦截了非浏览器请求。
② 它是本次改动的不确定因素。这类 WAF 模块会介入 Apache 的过滤链，理论上存在干扰 HTTP/2 的可能。本站实测未受影响，但如果按本文操作后 Protocol 仍显示 http/1.1，第一个怀疑对象应该是 WAF 模块，而不是 Apache 配置写错了。
七、排查清单：改完没生效怎么办
按以下顺序排查，可以少走弯路：
| 顺序 | 检查项 | 操作 |
|---|---|---|
| 1 | # 是否真的去掉了 |
findstr /n /i "http2" httpd.conf |
| 2 | 是否彻底重启 | Stop + Start，不用 Restart |
| 3 | 浏览器缓存 | 用无痕窗口，或勾 Disable cache |
| 4 | 改的是不是正在使用的配置文件 | httpd.exe -V | findstr /i "SERVER_CONFIG_FILE" |
| 5 | 虚拟主机里有没有覆盖 | findstr /n /i "Protocols" httpd-ssl.conf |
| 6 | WAF / 安全软件是否干扰 | 临时停用观察（本站为云锁） |
八、启用后的效果与连带影响
实测结果
本站启用 HTTP/2 后，Lighthouse 的「Modern HTTP」审计项消失，Protocol 全部显示为 h2。（此处可补上你实测到的新 LCP 数值与性能总分。）
一个连带的好处：不必再纠结文件数量
这一点值得单独说明。此前为了优化性能，一直有个顾虑：本站首页加载了 9 个 CSS 文件，是否应该合并以减少请求数？
在 HTTP/1.1 下，多一个文件就多一次排队，合并是有意义的。但在 HTTP/2 的多路复用下，多个小文件几乎不产生额外开销，合并的必要性大幅下降。
换句话说：启用 HTTP/2 之后，那些因为「文件太多」而产生的优化焦虑，可以放下了。
九、小结
这一项在整个优化过程中的性价比是最高的：只改了两行配置，重启一次服务，收益却是数百毫秒的加载提速——超过此前所有代码层面的优化总和。
回看整个过程，有两个体会值得记下：
第一，工具反复提示的项，往往不是噪音。「Modern HTTP」这一项被提示了很多次，一直被当作可选项忽略，实际它是这轮收益最大的改动。
第二，改配置前一定要用命令确认现状。本次最关键的发现，就是 mod_http2 那一行其实带着 # 从未生效。如果凭印象认为「模块应该已经启用了」，就会跳过真正的问题所在。
至此，本站服务器层面的性能优化基本做到头了。剩余可挖的空间主要在图片体积与内容本身，那属于另一个话题。
后续：改动是否带来实际变化，需要等待 Google Search Console 中的真实访客数据（核心网页指标）更新，通常需要 28 天。本地 Lighthouse 的模拟数据只能作为参考。
