sub_filter本身轻量无延迟，真正瓶颈在于配置不当：需确保明文响应、精准匹配、限定类型与作用范围、合理设置缓冲。
sub_filter 本身是流式、内存内完成的轻量替换，只要配置得当，几乎不引入额外延时。真正影响响应速度的，往往不是替换动作本身，而是配套设置不当引发的缓冲等待、重复解压或匹配失败重试。
确保响应走明文路径，避免解压开销
gzip 压缩响应必须先解压才能替换，而 Nginx 默认不自动解压——若强行启用 gunzip on，会增加 CPU 和延迟。更高效的做法是让上游返回明文：
- 在 location 中添加 proxy_set_header Accept-Encoding "";，主动告知后端“我不接受压缩”
- 确认后端实际响应头不含 Content-Encoding: gzip（可用 curl -I 验证）
- 避免同时开启 gzip on 和 sub_filter，二者冲突且无必要
控制匹配粒度，减少无效扫描
sub_filter 是逐块扫描字符串，匹配越宽泛，扫描越久。精准写法能显著降低 CPU 占用：
- 优先匹配带引号和属性名的完整片段，例如：sub_filter 'src="http://cdn.a.com/' 'src="/cdn/';，比只写 'http://cdn.a.com/' 更快更安全
- 避免跨行匹配：确保 HTML/CSS 中 URL 不被换行截断（如后端模板中不要把 href= 拆成多行）
- 不用通配符或模糊前缀；sub_filter 不支持正则，写得越像真实原文，命中越快
限制作用范围，只处理真正需要的响应
全局开启 sub_filter 但未加类型过滤，会导致 Nginx 对所有响应（包括图片、字体、二进制流）都尝试扫描，徒增负担：
- 显式声明 sub_filter_types text/html text/css application/javascript;，不写 * 或留空
- 只在真正需要替换的 location 中启用，例如 location /app/ { ... }，而非笼统的 location / {}
- 对纯静态资源路径（如 /static/、/images/）直接跳过 sub_filter，用 root/alias 原样返回
保持缓冲合理，不放大延迟感知
sub_filter 依赖响应体被完整缓冲才能稳定工作，但过大缓冲反而拖慢首字节时间：
- 保留默认 proxy_buffering on; 即可，无需调大 proxy_buffers
- 避免设置 proxy_buffer_size 128k; 等过大值——多数 HTML 不超过 200KB，缓冲 4×8KB 足够
- 若后端响应极小（如 JSON API），可考虑关闭 buffering（proxy_buffering off;），改用流式替换（此时需接受首处匹配限制）
