直接用brotli命令压缩HTML无效，因仅生成.br文件而未配置服务器响应Content-Encoding: br头；浏览器只在HTTPS下通过Accept-Encoding: br协商并依赖服务端（如Nginx需编译ngx_brotli模块+启用brotli_static on）返回压缩响应，否则.br文件不被使用。
为什么直接用 brotli 命令压缩 HTML 文件往往没效果
因为单纯执行 brotli -q 11 index.html 只生成 index.html.br，但浏览器根本不会自动请求或解压它——HTTP 层不参与，纯文件操作等于白干。关键不在“能不能压”，而在“压完怎么让浏览器用上”。
- 浏览器只在发起请求时通过
Accept-Encoding: br告诉服务器自己支持 Brotli - 服务器必须识别这个头，并且有对应
.br文件（或能实时压缩），才能返回带Content-Encoding: br的响应 - 如果服务端没配，哪怕你本地压出 100 个
.br文件，Nginx/Apache 默认也完全无视它们
Nginx 启用 Brotli 静态文件服务的硬性前提
官方 Nginx 不带 Brotli 支持，必须手动加模块。别信“改个配置就行”的说法——ngx_brotli 是第三方模块，不编译进去就不存在 brotli_static on 这个指令。
- 先确认当前 Nginx 编译参数：
nginx -V 2>&1 | grep -o with-compat，没输出说明不支持动态模块加载 - 若要动态加载，必须用
--with-compat重编 Nginx，再make modules编出ngx_http_brotli_static_module.so -
load_module /etc/nginx/modules/ngx_http_brotli_static_module.so;必须放在events块之前，放错位置会导致启动失败 - 启用后还要配
location块显式开启：brotli_static on;+add_header Vary Accept-Encoding;
Webpack/Vite 构建时生成 .br 文件的实操要点
构建工具生成 .br 是为了配合服务端静态压缩策略，不是替代它。常见错误是只配了插件却忘了告诉服务器去读这些文件。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- Vite 用户：装
vite-plugin-compression，设algorithm: 'brotliCompress'，它会为每个.html、.js、.css输出对应.br - Webpack 用户：用
compression-webpack-plugin，注意algorithm: 'brotliCompress'和test: /\.(js|css|html|svg)$/要覆盖 HTML - 生成的
.br文件必须和原文件同目录、同名（如index.html+index.html.br），否则 Nginx 的brotli_static on找不到 - 别漏掉
gzip_static on和brotli_static on共存——Brotli 优先，fallback 到 gzip
验证 Brotli 是否真正生效的唯一可靠方式
看响应头，不是看文件是否存在，也不是看 Nginx 日志有没有报错。
立即学习“前端免费学习笔记（深入）”；
- 用 Chrome DevTools → Network → 刷页面 → 点开任意 HTML 请求 → Headers → 检查
Response Headers里是否有Content-Encoding: br - 同时确认
Content-Length明显小于未压缩版本（比如从 12KB 降到 8KB） - 如果只有
Content-Encoding: gzip，说明客户端发了br但服务端没响应，或客户端其实没发（比如用了 HTTP 而非 HTTPS） - HTTPS 是硬性要求：
Accept-Encoding: br在 HTTP 下几乎不会出现，现代浏览器只在 TLS 连接中协商 Brotli
