Nginx原生不支持CSS/JS合并，需借助第三方模块（如ngx_http_concat_module）动态合并，或在构建阶段预合并后由Nginx静态托管；后者更推荐，性能好、运维简、兼容性强。
在 Nginx 中，原生并不支持 CSS/JS 合并（即自动将多个文件打包为一个），它本身是反向代理与静态资源服务器，并非构建工具。所谓“合并加速插件”，实际需借助第三方模块（如 ngx_http_concat_module）或在应用层/构建阶段完成合并，Nginx 仅负责高效分发。下面介绍两种主流、稳定、生产可用的实践方式。
方式一：使用 nginx-http-concat 模块（服务端动态合并）
这是由淘宝开源、被广泛验证的 Nginx 第三方模块，支持通过 URL 参数动态合并 CSS/JS，例如：/??style1.css,style2.css,common.css。
- 需重新编译 Nginx 并加载
ngx_http_concat_module（官方已不维护，但 v1.16–v1.22 兼容性良好）； - 在
nginx.conf的location块中启用：
location /static/ {
concat on;
concat_max_files 20;
concat_unique off;
concat_types application/javascript text/css;
}访问 /static/??a.js,b.js,c.css 即可返回合并后的内容（按顺序读取、去重注释、保留末尾分号）。注意：该模块不压缩，建议配合 Gzip 或 Brotli；也不校验文件是否存在，缺失任一资源将返回 404。
方式二：构建时预合并 + Nginx 静态托管（推荐）
更符合现代前端工程实践：在 CI/CD 或本地构建阶段（如 Webpack/Vite/Rollup）完成 CSS/JS 合并与压缩，生成固定文件（如 app.min.css、vendor.chunk.js），再由 Nginx 直接 serve。
立即学习“前端免费学习笔记（深入）”；
- 优势明显：避免运行时开销、兼容所有 Nginx 版本、支持 SourceMap、便于 CDN 缓存和版本控制；
- Nginx 配置只需开启静态服务与缓存：
location /assets/ {
alias /var/www/myapp/dist/assets/;
expires 1y;
add_header Cache-Control "public, immutable";
gzip_static on; # 自动找 .gz 文件
}确保构建输出目录含合并后的资源，并在 HTML 中引用对应路径即可。这是目前最可靠、性能最好、运维最简的方式。
补充：Nginx 层面可做的真实“加速”优化
即便不合并，也可显著提升 CSS/JS 加载效率：
- 启用
gzip_static on，提前用gzip命令压缩好.css.gz、.js.gz； - 配置
expires与Cache-Control，利用浏览器强缓存； - 开启
sendfile on和tcp_nopush on，减少系统调用与网络包数量； - 对小资源（如 icon.css、polyfill.js）考虑内联（inline）到 HTML 中，由后端或构建工具处理，Nginx 不参与。
不推荐的做法
试图用 Lua（OpenResty）在 Nginx 中实时读取、合并、压缩 CSS/JS —— 易引入阻塞、内存泄漏、缓存一致性问题，且违背 Nginx 轻量高效的设计哲学。同理，依赖过时或未审核的第三方模块（如某些 GitHub 上的“nginx-merge-js”）存在安全与维护风险。
