mod_substitute 默认不生效是因为未启用且依赖 mod_filter；替换规则需用 s/// 语法并注意编码、分隔符和执行顺序；复杂场景建议用后端模板或 Nginx sub_filter 替代。
mod_substitute 为什么默认不生效
因为 mod_substitute 默认不启用，且必须配合 mod_filter 使用——没加载 mod_filter，AddOutputFilterByType SUBSTITUTE text/html 这类配置会静默失败。Apache 2.4+ 中 mod_filter 通常已编译但未启用，得手动在配置里加 LoadModule filter_module modules/mod_filter.so。另外，SUBSTITUTE 过滤器只对响应体起作用，不处理响应头或二进制内容；如果后端返回 Content-Type: application/json，即使你写了匹配规则，也不会触发替换。
如何写安全又有效的替换规则
用 Substitute 指令时，正则必须用 s/// 语法，结尾要加 i（忽略大小写）或 n（不跨行），否则容易漏匹配或报错 Invalid regex。常见错误是忘记转义斜杠或点号，比如想替换成 CDN 地址：Substitute "s|/static/|https://cdn.example.com/static/|i" —— 这里竖线 | 是分隔符，比用斜杠更安全。还有一点：规则按配置顺序执行，前一条改过的文本可能影响后一条匹配，所以敏感替换（如改 href 属性值）建议放在最后，避免二次污染。
为什么替换后页面乱码或 JS 报错
根本原因是 mod_substitute 默认以字节流方式操作响应体，不感知字符编码。如果页面是 UTF-8 但含中文路径，而正则里用了中文字符（比如 s/旧文案/新文案/i），Apache 可能因编码不一致截断字节，导致后续 HTML 解析失败。解决办法只有两个：
• 强制后端输出明确声明 Content-Type: text/html; charset=utf-8；
• 替换规则全部用 ASCII 字符（URL、ID、class 名等），避开直接匹配中文文本；
• 不要用 s///n 以外的标志，n 表示“单行模式”，防止点号 . 匹配换行符引发意外截断。
替代方案比 mod_substitute 更稳的场景
当你要替换的内容嵌套在 JS 字符串里、或依赖 DOM 结构（比如只换某个 div 内的链接），mod_substitute 就力不从心了——它没有 HTML 解析能力，纯靠正则，极易误伤。这时候不如把逻辑前置：
• 后端模板中统一用配置项控制静态资源域名；
• Nginx 用 sub_filter（性能更好，支持多级缓存穿透）；
• 实在要 Apache 做，可结合 mod_proxy + 外部脚本（如用 Python 写个简单 WSGI 中间件），比硬刚正则靠谱得多。Apache 的 mod_substitute 本质是个轻量修补工具，不是内容重写引擎。
真正麻烦的从来不是写对一条 Substitute 规则，而是确认响应流里每个字节都按你预期被解码、分块、过滤——尤其当有压缩（mod_deflate）、代理（mod_proxy）或缓存模块介入时，顺序和编码边界稍一错，就只剩空白页和 500 日志了。
