mod_sed是Apache内置轻量正则引擎，不调用系统sed，仅支持s///、y///等有限命令，不支持跨行、扩展正则、编辑命令及头字段修改，需在Location等上下文中配置，且受8KB响应体限制。
mod_sed 不是 sed，不能直接复用 shell 命令
Apache 的 mod_sed 模块名字容易误导——它**不调用系统 sed 二进制**，也不支持 sed -i、sed -n 或脚本文件（-f）等命令行行为。它是 Apache 内部实现的一套轻量正则处理引擎，语法和能力都受限得多。
常见错误现象：把 sed 's/foo/bar/g' 直接抄进 Apache 配置里，结果 500 错误或完全无效果；或者试图用 /pattern/p 打印匹配行，但 Apache 响应体里什么都没变。
-
mod_sed只支持s///（替换）、y///（字符映射）和少量地址限定（如^、$），不支持d、p、i、a、c等编辑命令 - 不支持扩展正则（
-r/-E），只认基础正则语法（例如[a-z]可用，(?i)或d会报错） - 不能跨行操作：每条规则只作用于单行响应体或请求头，无法像 shell sed 那样用
N合并多行
启用 mod_sed 并配置 Location 匹配范围
必须先确认模块已加载：a2enmod sed（Debian/Ubuntu）或手动在 httpd.conf 中启用 LoadModule sed_module modules/mod_sed.so。未启用时任何 Sed 指令都会导致配置校验失败。
实际修改只发生在明确声明的上下文内，比如：
<Location "/api/v1/>
Sed "s/"status":"ok"/"status":"success"/g"
</Location>
注意几点：
- 指令必须写在
<Location>、<Directory>或<Files>块中，不能放在全局 Server 配置顶层 - 只对响应体（response body）生效；若要改请求头（如
User-Agent），需配合RequestHeader edit，mod_sed本身不处理 headers - 路径匹配区分大小写，且不支持通配符（
*）或正则地址，只能靠LocationMatch配合 PCRE
替换规则中的分隔符与转义陷阱
Apache 的 Sed 指令默认使用 / 作分隔符，但 JSON、URL 或含斜线的路径极易冲突。此时必须换分隔符，且**不能省略开头的分隔符字符**——下面两种写法效果完全不同：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
✅ 正确（用 # 分隔，避免转义）：Sed "s#https://example.com#/proxy#g"
❌ 错误（漏掉开头 #）：Sed "s#https://example.com#/proxy#g" → Apache 解析为 s#https: 开头，后面全被当作文本忽略
另外，反斜线 在 Apache 配置中会被预解析一次，所以想匹配字面量
，得写成 \n；匹配双引号需写成 "（即使在双引号字符串内）。
- 所有正则元字符（
.、^、$、[、+、?）都需按基础正则规则转义，例如匹配字面量点号必须写. - 捕获组
(…)支持，但反向引用只能用、，不能用$1 - 不支持标志位（
/g是唯一隐式支持的，/i或/m会直接报错）
性能与调试：响应体过大时会静默失败
mod_sed 对响应体长度有硬限制，默认仅处理前 8KB（具体取决于 Apache 版本和编译选项）。超出部分不触发替换，也不报错——页面看起来“部分生效”，极难排查。
调试建议：
- 先用
curl -v确认原始响应体结构，再小范围测试规则（例如只匹配一个固定字符串） - 开启
LogLevel sed:trace4（Apache 2.4.37+），日志里能看到每条规则是否命中、处理了哪几行 - 避免在高流量路径上启用复杂正则；替换逻辑越简单（如固定字符串替换），性能损耗越低
- 如果需要改整个 HTML 页面的 class 名或 script 标签，优先考虑前端 JS 或服务端模板，
mod_sed不适合这种场景
真正关键的不是“能不能做”，而是“值不值得用”——它只适合轻量、确定、单行、低延迟的响应微调。一旦涉及结构解析、条件分支或多行上下文，就该换方案了。
