Nginx的sub_filter不适合导航栏注入，因其仅为纯文本替换、不识别HTML语法边界，易因注释嵌套、多次匹配或gzip压缩导致结构错乱，且无法动态高亮当前路径；可靠方案应下沉至构建时静态生成或用Lua在body_filter_by_lua_block中谨慎替换固定锚点。
静态页面不能直接塞进网关层做结构注入——Nginx/OpenResty 本身不解析 HTML DOM，也不支持像浏览器那样操作 document；所谓“注入”必须靠服务端模板渲染或 Lua 脚本在响应流中字符串替换，且极易破坏 HTML 结构完整性。
为什么 Nginx 的 sub_filter 不适合做导航栏注入
很多人看到 sub_filter 就想用它把 <!--nav--> 替换成完整导航 HTML，但实际踩坑极多：
-
sub_filter是纯文本替换，不识别标签边界——如果导航 HTML 含有<!--或嵌套注释，会提前截断或错位 - 它只作用于响应体（response body），且默认只处理第一个匹配项；开启
sub_filter_once off后，若页面含多个相同占位符，可能重复替换导致结构错乱 - 无法动态匹配当前路径加
class="active"，所有高亮逻辑必须提前写死或依赖后端渲染 - 当启用 gzip 压缩时，
sub_filter默认失效，需额外配置sub_filter_types text/html application/xhtml+xml;并确保压缩前处理
OpenResty 中用 Lua 注入的可行路径
真正可控的方式是用 content_by_lua_block 或 body_filter_by_lua_block 在响应阶段介入，但必须注意边界：
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 用
ngx.ctx缓存已注入标记，避免多次执行导致重复插入 - 推荐在
body_filter_by_lua_block中用string.gsub处理原始响应体，但仅限简单结构——例如只替换一个固定位置的<header></header>，而非整页 DOM 操作 - 若需高亮当前页，必须从
ngx.var.uri或ngx.var.request_uri提取路径，并与导航链接比对；注意尾部斜杠一致性，建议统一用string.gsub(uri, "/$", "") - 不要在 Lua 中拼接大段 HTML 字符串——易引入 XSS 风险，应预编译为模块变量，如
local nav_html = require("nav_template").html
更稳妥的静态化 + 网关协作模式
把结构注入逻辑从网关下沉到构建时，网关只做路由分发和缓存控制，才是长期可维护的方案：
立即学习“前端免费学习笔记（深入）”；
- 用 Hugo/Astro 等 SSG 工具，在构建阶段生成带正确
class="active"的静态 HTML，输出到/opt/huawei/openresty/nginx/html/下指定目录 - 确保所有页面的
<header>存在且唯一，否则前端 JS 加载导航时会失败——这点比网关注入更可靠 - Nginx 配置中明确限定静态资源路径，例如
location / { root /opt/huawei/openresty/nginx/html; try_files $uri $uri/ /index.html; }，避免因路径错配触发"some html not in /opt/huawei/openresty/nginx/html"错误 - 若必须运行时注入（如多租户定制导航），应由独立 Lua 服务（如基于 OpenResty 的
lua-resty-http）异步拉取模板并缓存，而非硬编码在配置里
真正难的不是“怎么注入”，而是“注入之后如何保证语义正确、SEO 可见、路径高亮稳定、后续可维护”。网关层越薄，出问题时定位越快；结构逻辑越早固化在构建产物里，线上越少意外。
