Apache mod_pagespeed 在 CentOS/Fedora 上的生产级部署与调优

1. 项目概述：为什么在 CentOS/Fedora 上启用 mod_pagespeed 不是“锦上添花”，而是性能刚需

你刚在 CentOS 或 Fedora 云服务器上搭好 Apache，网站跑起来了，但打开 Chrome DevTools 的 Network 面板一看：首页 HTML 280KB、CSS 合并前 7 个文件、JS 里还混着三段未压缩的 jQuery 插件、图片全是原始尺寸直传——首屏加载时间稳稳卡在 3.8 秒。这时候有人告诉你：“装个 mod_pagespeed 就能自动优化”，你第一反应可能是“又一个半吊子自动压缩模块？怕不是把 CSS 压成一行就叫优化”。但我要说：mod_pagespeed 是 Apache 生态里极少数真正理解“前端性能工程全链路”的模块，它不是在做“文本替换”，而是在 HTTP 请求生命周期里嵌入了一整套浏览器级优化引擎。我在为某电商 SaaS 客户做压测时实测过：同一台 2核4G 的阿里云 CentOS 7.9 服务器，未启用时 TTFB 平均 142ms、FCP（首次内容绘制） 2.6s；启用 mod_pagespeed 并完成基础配置后，TTFB 降至 118ms，FCP 直接压到 1.3s，Lighthouse 性能分从 52 跃升至 89。这不是靠改几个参数蒙出来的，而是它原生支持的 40+ 优化规则在真实请求中协同生效的结果——比如它能把 <img src="product.jpg"> 自动重写为 <img src="product.jpg.pagespeed.ic.HASH.jpg" loading="lazy" width="320" height="240"> ，同时后台异步生成 WebP 格式、添加响应式 srcset、注入懒加载属性，整个过程对源码零侵入。它不依赖你懂 Webpack，也不要求你重构 Vue 组件，只要 Apache 在跑，它就在工作。尤其对运维人员或中小团队来说，这是唯一能在不改动业务代码、不增加 CI/CD 复杂度的前提下，系统性提升 Web 性能的方案。关键词 mod_pagespeed、Apache、CentOS、Fedora 不是孤立的技术名词，它们共同指向一个现实场景：你在用最主流的开源 LAMP 栈部署生产服务，而性能瓶颈正卡在“最后一百米”的传输与渲染环节。这篇文章就是带你亲手把这“一百米”铺成高速公路。

2. 核心设计逻辑与方案选型：为什么必须用官方 RPM 包而非源码编译

2.1 mod_pagespeed 的本质不是“插件”，而是“HTTP 中间件”

很多人误以为 mod_pagespeed 是类似 mod_rewrite 的轻量级过滤器，其实它的架构复杂度远超想象。它内部包含三个核心子系统： 解析器（Parser） 、 优化器（Optimizer） 和 缓存代理（Cache Proxy） 。当请求到达 Apache 时，mod_pagespeed 并非简单地对响应体做字符串替换。它会先将 HTML 解析为 DOM 树，再遍历节点识别 <img> 、 <script> 、 <link> 等资源标签；对每个外部资源，它启动独立的 HTTP 客户端发起回源请求（注意：是 Apache 进程内发起，非 shell 调用 curl），获取原始二进制流；接着调用内置的图像处理库（基于 libwebp 和 libjpeg-turbo）进行转码、缩放、质量压缩；最后将优化后的资源写入本地磁盘缓存（默认 /var/cache/mod_pagespeed/ ），并重写 HTML 中的 URL 指向缓存路径。这个过程涉及多线程调度、内存池管理、原子文件锁控制——如果直接从源码编译，你得手动解决所有依赖库的版本兼容问题。我曾在一个 Fedora 38 环境下尝试源码编译 pagespeed-1.13.35.2，卡在了 gtest 1.12 与系统自带的 gcc 13.2.1 的 ABI 不匹配上，折腾两天无果。而官方 RPM 包早已预编译好所有二进制依赖，并通过严格的 ABI 测试验证。

2.2 CentOS 与 Fedora 的包管理差异决定安装路径

CentOS（尤其是 Stream 版本）和 Fedora 虽同属 Red Hat 家族，但软件生命周期策略截然不同：CentOS Stream 是 RHEL 的上游开发分支，追求稳定性，软件包更新保守；Fedora 则是前沿技术试验田，每六个月发布新版，包版本激进。这就导致同一个 mod_pagespeed 版本，在两个系统上的依赖树可能完全不同。例如，pagespeed-1.13.35.2 在 CentOS 7 上依赖 httpd24u-httpd （来自 IUS 仓库），而在 Fedora 39 上则直接依赖系统默认的 httpd （版本 2.4.58）。若强行跨平台复用 RPM，会出现 libstdc++.so.6(GLIBCXX_3.4.29)(64bit) is needed 这类符号版本错误。因此，我们必须严格遵循“发行版专属渠道”原则：

• CentOS 7/8/Stream ：使用 PageSpeed 官方 YUM 仓库 提供的 .repo 文件，其内含针对各 CentOS 版本的精确构建；
• Fedora ：直接使用 dnf install mod-pagespeed-stable ，因为 Fedora 官方仓库已收录该包（自 Fedora 35 起），且由 Fedora 基础设施团队维护，确保与 httpd 主版本强绑定。

提示：切勿在 CentOS 上 dnf install mod-pagespeed （这是 Fedora 专用命令），也勿在 Fedora 上 yum install mod-pagespeed （yum 已被弃用）。命令错位会导致元数据冲突，甚至破坏 dnf/yum 数据库。

2.3 为什么放弃 Nginx + ngx_pagespeed？Apache 的 MPM 模型更适配

当前社区有声音鼓吹“Nginx 更轻量，应优先选 ngx_pagespeed”。但实际生产中，Apache 的多处理模块（MPM）机制反而让 mod_pagespeed 更稳定。以 CentOS 7 默认的 prefork MPM 为例，每个子进程独占内存空间，mod_pagespeed 的缓存对象（如图像处理后的二进制块）被隔离在单个进程中，避免了多线程环境下的竞态条件。而 Nginx 的 worker_processes auto 模式下，ngx_pagespeed 的共享内存缓存需依赖 shm 区域，一旦 pagespeed FileCachePath 设置不当，极易触发 No space left on device 错误（实为 shm 内存耗尽）。我在某新闻站迁移时做过对比测试：相同 4核8G 服务器，Apache + mod_pagespeed 在 1000 并发下缓存命中率稳定在 92%；Nginx + ngx_pagespeed 在 800 并发时即出现 shm 分配失败，日志刷屏 pagespeed: Failed to allocate shared memory segment 。这不是模块优劣问题，而是架构适配问题——如果你的业务已深度绑定 Apache（如 .htaccess 规则、mod_security 配置、PHP-FPM 集成），强行切换 Web 服务器带来的边际收益，远低于直接优化现有栈的 ROI。

3. 实操部署全流程：从系统准备到生产级配置落地

3.1 系统环境初始化（CentOS 7/8/Stream 与 Fedora 分别处理）

CentOS 系统准备（以 CentOS 7.9 为例）

首先确认 Apache 版本及运行状态：

# 检查是否已安装 httpd（CentOS 7 默认带）
rpm -qa | grep httpd
# 若未安装，则执行
sudo yum install -y httpd
# 启动并设为开机自启
sudo systemctl start httpd
sudo systemctl enable httpd
# 验证端口监听
sudo ss -tlnp | grep :80

关键点在于 禁用 SELinux 的布尔值干扰 。mod_pagespeed 需要读写 /var/cache/mod_pagespeed/ ，而默认 SELinux 策略会阻止 httpd_t 域访问该路径。执行：

# 临时放行（重启失效，用于快速验证）
sudo setsebool -P httpd_can_network_connect 1
sudo setsebool -P httpd_read_user_content 1
# 永久修改文件上下文（推荐）
sudo semanage fcontext -a -t httpd_cache_t "/var/cache/mod_pagespeed(/.*)?"
sudo restorecon -Rv /var/cache/mod_pagespeed

注意： semanage 命令在 CentOS 7 中属于 policycoreutils-python 包，若提示 command not found，请先 sudo yum install -y policycoreutils-python 。

Fedora 系统准备（以 Fedora 39 为例）

Fedora 使用 dnf 且默认启用 SELinux，但策略更宽松。重点检查防火墙：

# Fedora 默认使用 firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload
# 确认 httpd 服务状态
sudo systemctl status httpd
# 若未运行，启动
sudo systemctl start httpd

Fedora 的 SELinux 对 mod_pagespeed 友好得多，通常无需额外配置，因其 httpd_cache_t 类型已预定义。但需注意：Fedora 39 的 httpd 默认启用 event MPM （多线程模型），而 mod_pagespeed 官方文档明确建议在 event 模式下启用 ThreadLimit 限制，防止线程数爆炸。我们在后续配置中会处理。

3.2 mod_pagespeed 安装（分发行版精准执行）

CentOS 7/8/Stream 安装步骤

1. 添加官方 YUM 仓库 （必须用 curl 下载， wget 在某些最小化安装中可能未预装）：

sudo curl -o /etc/yum.repos.d/pagespeed.repo https://www.modpagespeed.com/centos/pagespeed.repo
# 验证仓库是否生效
sudo yum repolist | grep pagespeed

2. 安装 mod_pagespeed （自动解决所有依赖）：

# CentOS 7 使用 yum
sudo yum install -y mod-pagespeed-stable
# CentOS 8/Stream 使用 dnf
sudo dnf install -y mod-pagespeed-stable

3. 验证模块加载 ：

# 检查 modules 目录是否存在 pagespeed.load
ls /etc/httpd/conf.modules.d/ | grep pagespeed
# 查看 Apache 加载的模块列表
httpd -M | grep pagespeed
# 应输出： pagespeed_module (shared)

Fedora 安装步骤

Fedora 官方仓库已集成，一步到位：

# 刷新元数据（可选，确保获取最新包）
sudo dnf makecache
# 直接安装
sudo dnf install -y mod-pagespeed-stable
# 验证
httpd -M | grep pagespeed

实操心得：Fedora 安装后， /etc/httpd/conf.d/pagespeed.conf 文件默认存在，但内容为空。这是因为 Fedora 采用“按需启用”策略，需手动编辑该文件填入配置。而 CentOS 的 RPM 包会自动写入基础配置，这是发行版哲学差异导致的细节区别。

3.3 核心配置详解：从 pagespeed.conf 到生产级参数调优

mod_pagespeed 的配置分为两层： 全局配置 （影响所有虚拟主机）和 虚拟主机级配置 （可覆盖全局）。我们先处理全局配置 /etc/httpd/conf.d/pagespeed.conf 。

全局配置（ /etc/httpd/conf.d/pagespeed.conf ）关键参数解析

# 启用模块（必须放在最前）
LoadModule pagespeed_module modules/mod_pagespeed.so

# 启用 Pagespeed（默认为 off，必须显式开启）
ModPagespeed on

# 设置缓存路径（必须可写，且 SELinux 上下文正确）
ModPagespeedFileCachePath "/var/cache/mod_pagespeed/"

# 设置缓存大小上限（单位：字节，此处为 100MB）
ModPagespeedFileCacheSizeKb 102400

# 设置缓存清理阈值（当使用量达 90% 时触发清理）
ModPagespeedFileCacheCleanIntervalMs 3600000

# 启用核心优化规则（必须启用，否则无效果）
ModPagespeedEnableFilters collapse_whitespace,remove_comments,elide_attributes

这里需要重点解释 ModPagespeedEnableFilters 的选择逻辑。 collapse_whitespace （合并空白符）和 remove_comments （移除 HTML 注释）是安全无害的“零风险”规则，几乎不会引发兼容性问题；而 elide_attributes （省略布尔属性的值，如 disabled="disabled" → disabled ）虽能减小体积，但在某些老旧 IE 兼容场景下可能出问题。因此， 生产环境首推保守启用策略：先只开这三个，上线观察 48 小时无异常，再逐步添加 。

虚拟主机级配置（ /etc/httpd/conf.d/vhost.conf ）实战

假设你的站点配置在 /etc/httpd/conf.d/myapp.conf 中，需在 <VirtualHost> 块内添加：

<VirtualHost *:80>
    ServerName myapp.example.com
    DocumentRoot /var/www/myapp

    # 启用 Pagespeed（继承全局，但可在此覆盖）
    ModPagespeed on

    # 关键：设置此虚拟主机的缓存路径（避免多站点共享缓存冲突）
    ModPagespeedFileCachePath "/var/cache/mod_pagespeed/myapp/"

    # 启用高级图像优化（需额外安装 libwebp）
    ModPagespeedEnableFilters rewrite_images,convert_jpeg_to_webp,convert_png_to_webp

    # 启用 CSS/JS 合并与压缩
    ModPagespeedEnableFilters combine_css,combine_javascript,collapse_whitespace

    # 强制启用延迟加载（对移动端至关重要）
    ModPagespeedEnableFilters lazyload_images

    # 设置页面速度等级（影响优化激进程度）
    ModPagespeedRewriteLevel CoreFilters

    # 关键安全配置：禁止 Pagespeed 重写敏感路径
    ModPagespeedDisallow "*/admin/*"
    ModPagespeedDisallow "*/api/*"
    ModPagespeedDisallow "*/wp-admin/*"  # 若为 WordPress 站点
</VirtualHost>

参数说明：

• ModPagespeedFileCachePath 必须为 绝对路径且唯一 。若多个虚拟主机共用同一路径，缓存键（cache key）可能冲突，导致 A 站点的优化资源被 B 站点错误引用；
• rewrite_images 等规则需依赖系统库。在 CentOS 7 上，需额外安装 libwebp ： sudo yum install -y libwebp ；Fedora 39 默认已含，无需操作；
• ModPagespeedRewriteLevel CoreFilters 是安全基线。 PassThrough 级别禁用所有优化， OptimizeForBandwidth 更激进（如自动内联小 CSS），但可能破坏某些 JS 框架的样式注入逻辑，故不推荐新手直接使用；
• ModPagespeedDisallow 是生命线。我曾遇到客户未加此配置，Pagespeed 将 /api/v1/login 的 JSON 响应误当成 HTML 重写，把 { "status": "success" } 改成 { "status": "success" } （看似没变，实则插入了不可见空格），导致前端 JS JSON.parse() 报错。务必把所有非 HTML 资源路径列入黑名单。

生产级调优：应对高并发与大流量场景

当你的站点日均 UV 超过 10 万，需调整以下参数：

# 增加缓存大小（根据磁盘空间调整，此处设为 2GB）
ModPagespeedFileCacheSizeKb 2097152

# 缩短缓存清理间隔（避免旧资源堆积）
ModPagespeedFileCacheCleanIntervalMs 1800000

# 启用内存缓存（减少磁盘 IO，需 Apache 2.4.32+）
ModPagespeedInMemoryCacheSizeKb 102400

# 限制并发优化请求数（防止单次请求拖垮服务器）
ModPagespeedMaxCombinedCssBytes 204800
ModPagespeedMaxCombinedJsBytes 204800

# 关键：设置 Pagespeed 的线程池大小（仅 Fedora event MPM 需要）
<IfModule mpm_event_module>
    ModPagespeedThreadLimit 4
    ModPagespeedThreads 4
</IfModule>

计算依据： ModPagespeedThreadLimit 应 ≤ Apache 的 ThreadsPerChild 值。在 Fedora 39 的 event MPM 默认配置中， ThreadsPerChild 为 25，因此设为 4 是安全的（留足余量给其他模块）。若你修改过 httpd.conf 中的 ThreadsPerChild ，请同步调整此值。

3.4 验证与监控：如何确认 mod_pagespeed 真正在工作

快速验证（三步法）

1. 检查响应头 ：用 curl 访问首页，看是否返回 X-Mod-Pagespeed 头：

curl -I http://myapp.example.com
# 应看到类似：X-Mod-Pagespeed: 1.13.35.2-0

2. 查看源码变化 ：在浏览器打开首页，右键“查看页面源代码”，搜索 pagespeed 字样。正常应看到类似：

<link rel="stylesheet" href="/styles/main.css.pagespeed.ce.KJH9876543.css">
<img src="/images/logo.png.pagespeed.ic.ABC1234567.png" width="200" height="100">

3. 检查缓存目录 ：确认 /var/cache/mod_pagespeed/ 下有文件生成：

sudo ls -la /var/cache/mod_pagespeed/
# 应看到类似：cache/  files/  generated/  lock/
sudo du -sh /var/cache/mod_pagespeed/
# 初期应有几 MB，随流量增长

深度监控（日志与指标）

启用 Pagespeed 日志（调试阶段必开）：

# 在 pagespeed.conf 中添加
ModPagespeedLogDir "/var/log/pagespeed"
ModPagespeedStatistics on
ModPagespeedMessageBufferSize 100000

然后创建日志目录并赋权：

sudo mkdir -p /var/log/pagespeed
sudo chown apache:apache /var/log/pagespeed
sudo chmod 755 /var/log/pagespeed

重启 Apache 后，访问 http://myapp.example.com/pagespeed_admin （需在 vhost 中显式允许，见下文），即可看到实时统计面板，包含：

• Cache Hit Rate ：缓存命中率，健康值应 > 85%；
• Filter Execution Count ：各优化规则执行次数，可定位瓶颈（如 rewrite_images 执行过多，说明图片未预优化）；
• Latency Breakdown ：各阶段耗时（Parse、Fetch、Optimize、Write），若 Optimize 占比过高，需检查 CPU 负载。

注意： pagespeed_admin 默认只允许 localhost 访问。若需远程查看，需在 vhost 中添加：

<Location /pagespeed_admin>
    Require ip 192.168.1.0/24  # 替换为你的办公网段
    # 或更安全的：Require valid-user（配合 htpasswd）
</Location>

4. 常见问题与排查技巧实录：那些官方文档不会写的坑

4.1 “页面没变化，X-Mod-Pagespeed 头也没出现” —— 五步定位法

这是新手最高频问题。按顺序排查：

实操心得 ：我踩过的最深的坑是第 5 步。某客户在 /etc/httpd/conf.d/ssl.conf 中为 HTTPS 站点配置了 ModPagespeed on ，却忘了在 /etc/httpd/conf.d/httpd-vhosts.conf 的 HTTP 站点中也开启。结果 curl HTTP 站点无响应头，而 curl HTTPS 站点正常。后来发现，他的 DNS 解析将域名指向了 HTTP 端口，导致所有测试都在“关闭状态”下进行。教训是： 永远先确认你测试的是哪个虚拟主机配置 。

4.2 “图片被优化后显示乱码/404” —— 缓存路径与 MIME 类型双校验

现象：HTML 中 <img> 的 src 已变成 .pagespeed.xxx.png ，但浏览器加载该 URL 返回 404 或损坏图片。

根因分析 ：

• 缓存路径权限错误 ： /var/cache/mod_pagespeed/ 目录属主不是 apache 用户，导致 Pagespeed 无法写入优化后的文件；
• MIME 类型未注册 ：Apache 不认识 .pagespeed.* 后缀，返回 text/plain ，浏览器拒绝渲染；
• SELinux 上下文丢失 ：目录被 mv 或 cp 操作后，SELinux 标签重置为 default_t ， httpd_t 进程无权访问。

解决方案 ：

1. 修复权限：

sudo chown -R apache:apache /var/cache/mod_pagespeed/
sudo chmod -R 755 /var/cache/mod_pagespeed/

2. 强制注册 MIME 类型（在 pagespeed.conf 中添加）：

# 告诉 Apache .pagespeed.* 是图片
AddType image/webp .pagespeed.webp
AddType image/jpeg .pagespeed.jpeg
AddType image/png .pagespeed.png
# 通用 fallback
AddType application/octet-stream .pagespeed.*

3. 修复 SELinux（CentOS 7）：

sudo semanage fcontext -a -t httpd_cache_t "/var/cache/mod_pagespeed(/.*)?"
sudo restorecon -Rv /var/cache/mod_pagespeed

4.3 “CPU 使用率飙升至 100%，Apache 响应变慢” —— 优化规则与资源限制联动

当启用 convert_jpeg_to_webp 等图像处理规则时，Pagespeed 会调用 libwebp 的 CPU 密集型编码器。若未设限，单个大图（如 5000x3000 像素）的转码可能占用 1 个 CPU 核心长达 3 秒。

紧急降级方案 ：

1. 立即停用图像转码规则：

# 在 vhost 中注释掉
# ModPagespeedEnableFilters convert_jpeg_to_webp,convert_png_to_webp

2. 重启 Apache： sudo systemctl restart httpd
3. 临时降低图像质量（在 pagespeed.conf 中添加）：

ModPagespeedImageJpegQualityForSmallScreens 75
ModPagespeedImageJpegQualityForLargeScreens 70
ModPagespeedImageWebpQualityForSmallScreens 75

长期治理方案 ：

• 预优化静态资源 ：对 /static/images/ 下的图片，用 cwebp 命令行工具批量转 WebP，然后在 HTML 中直接引用 .webp 文件，Pagespeed 会跳过已优化资源；
• 设置尺寸上限 ：添加规则限制处理图片的最大尺寸：

ModPagespeedImageMaxInlinePixelCount 1000000  # 100 万像素，约 1000x1000
ModPagespeedImageMaxRewritePixelCount 5000000  # 500 万像素，约 2000x2500

• 启用异步处理 （Apache 2.4.32+）：

ModPagespeedFetchFromModPagespeed off  # 禁用同步回源
ModPagespeedUseExperimentalJsMinifier on  # 启用更快的 JS 压缩器

4.4 “HTTPS 站点下资源被标记为 mixed content” —— 协议感知配置

当 Apache 后端是 HTTP，前端有反向代理（如 Nginx）处理 HTTPS 时，Pagespeed 默认生成 http:// 协议的重写 URL，导致浏览器报 Mixed Content 错误。

根本解法 ：强制 Pagespeed 使用 HTTPS 协议生成 URL：

# 在 vhost 的 <VirtualHost *:443> 块中添加
ModPagespeedMapOriginDomain http://localhost https://myapp.example.com
# 或更通用的（适用于所有反向代理场景）
ModPagespeedMapRewriteDomain http://myapp.example.com https://myapp.example.com

原理： MapOriginDomain 告诉 Pagespeed，“当原始 HTML 中的资源是 http://localhost/xxx 时，请重写为 https://myapp.example.com/xxx ”。这比修改应用代码或代理规则更直接。

4.5 “Pagespeed Admin 页面打不开，提示 403 Forbidden” —— 访问控制精细化配置

/pagespeed_admin 默认只允许 127.0.0.1 访问。若需从公司网络访问，不能简单写 Require all granted （极度危险），而应：

安全配置模板 （在 vhost 中）：

<Location /pagespeed_admin>
    # 仅允许特定 IP 段（如公司办公网）
    Require ip 203.0.113.0/24
    # 或使用密码保护（推荐）
    AuthType Basic
    AuthName "Pagespeed Admin Access"
    AuthUserFile "/etc/httpd/.pagespeed-htpasswd"
    Require valid-user
</Location>

生成密码文件：

# 安装 htpasswd（CentOS 7）
sudo yum install -y httpd-tools
# 创建用户（用户名 admin，密码自定义）
sudo htpasswd -c /etc/httpd/.pagespeed-htpasswd admin
# 设置文件权限
sudo chown root:apache /etc/httpd/.pagespeed-htpasswd
sudo chmod 640 /etc/httpd/.pagespeed-htpasswd

提示： .pagespeed-htpasswd 文件必须由 root 创建，且 apache 组可读。若权限不对，Apache 启动时会报 AH01618: user admin not found 。

5. 运维与升级策略：如何让 mod_pagespeed 长期稳定服役

5.1 版本升级：为什么不能 yum update 一刀切

mod_pagespeed 的版本迭代非常谨慎，但重大版本（如 1.13.x → 1.14.x）可能引入不兼容变更。例如，1.14.0 移除了 collapse_whitespace 规则的默认启用，若你依赖此规则且未在配置中显式声明，升级后 HTML 空白将不再被合并。

安全升级流程 ：

1. 订阅变更日志 ：关注 PageSpeed GitHub Releases ，重点阅读 Breaking Changes 部分；
2. 在测试环境验证 ：
   • 备份当前配置： sudo cp /etc/httpd/conf.d/pagespeed.conf /etc/httpd/conf.d/pagespeed.conf.bak ；
   • 执行升级： sudo yum update mod-pagespeed-stable （CentOS）或 sudo dnf update mod-pagespeed-stable （Fedora）；
   • 重启 Apache 并检查 httpd -t ；
   • 用 curl -I 验证响应头是否正常；
3. 灰度发布 ：在生产环境，先对 10% 的流量（通过负载均衡权重）启用新版本，监控 24 小时无异常，再全量。

5.2 缓存清理：何时该清，何时不该清

/var/cache/mod_pagespeed/ 不是“越干净越好”。Pagespeed 的缓存是内容寻址的（Content-Addressable），文件名中的 HASH 值由原始资源内容生成。这意味着：

• 若你更新了 style.css ，Pagespeed 会自动生成新 HASH 的缓存文件，旧文件自动失效；
• 但若你修改了 HTML 结构（如新增 <div class="new-section"> ），而该 div 引用的图片未变，Pagespeed 仍会复用旧图片缓存，保证一致性。

必须清理缓存的场景 ：

• 修改了 ModPagespeedEnableFilters ，新增了 inline_css 等规则，需让旧 HTML 重新解析；
• 发现缓存目录占用磁盘超 95%，且 ModPagespeedFileCacheCleanIntervalMs 未生效（日志中无 Cleaning cache 记录）；
• 升级 Pagespeed 后，页面出现样式错乱，怀疑缓存污染。

清理命令 （安全无害）：

# 停止 Apache（避免清理时写入冲突）
sudo systemctl stop httpd
# 清理所有缓存（保留目录结构）
sudo rm -rf /var/cache/mod_pagespeed/*
# 重启
sudo systemctl start httpd

注意：不要用 rm -rf /var/cache/mod_pagespeed （删除整个目录），因为 SELinux 上下文会丢失，需重新 restorecon 。 rm -rf /var/cache/mod_pagespeed/* 只删内容，保留目录，上下文不变。

5.3 故障应急：当 Pagespeed 导致服务不可用时的秒级回滚

任何模块都可能成为单点故障。必须建立 30 秒内恢复的应急通道：

Step 1：配置开关文件
创建 /etc/httpd/conf.d/pagespeed-switch.conf ：

# 默认关闭（生产环境初始状态）
ModPagespeed off

并在主 pagespeed.conf 末尾添加：

# 引入开关文件
Include conf.d/pagespeed-switch.conf

Step 2：编写一键启停脚本
/usr/local/bin/toggle-pagespeed.sh ：

#!/bin/bash
SWITCH_FILE="/etc/httpd/conf.d/pagespeed-switch.conf"
if grep -q "ModPagespeed on" "$SWITCH_FILE"; then
    sudo sed -i 's/ModPagespeed on/ModPagespeed off/' "$SWITCH_FILE"
    echo "Pagespeed disabled"
else
    sudo sed -i 's/ModPagespeed off/ModPagespeed on/' "$SWITCH_FILE"
    echo "Pagespeed enabled"
fi
sudo systemctl reload httpd

赋予执行权限： sudo chmod +x /usr/local/bin/toggle-pagespeed.sh

Step 3：故障时执行
当监控告警 Pagespeed 导致 500 错误时，SSH 登录后执行：

sudo /usr/local/bin/toggle-pagespeed.sh
# 等待 2 秒，验证
curl -I http://myapp.example.com | grep "X-Mod-Pagespeed"
# 若无输出，说明已关闭，服务应立即恢复

整个过程不超过 15 秒。这是我在线上救火的标准动作，比重启 Apache 更快，且不影响其他模块。

6. 性能对比与价值再评估：mod_pagespeed 在现代 Web 架构中的不可替代性

6.1 与 Cloudflare Auto Minify 的对比：边缘优化 vs 源站优化

很多团队会问：“既然 Cloudflare 有 Auto Minify，为什么还要在源站装 mod_pagespeed？” 这是个好问题。二者定位根本不同：

实测案例 ：某教育平台在 Cloudflare 开启 Auto Minify 后，HTML 体积从