sublime text 不支持 brotli 压缩，因其定位是文本编辑器而非构建工具；brotli 应集成于 vite/webpack 等构建流程或 nginx 服务端配置，编辑器仅负责编写源码。
Sublime Text 本身不内置 Brotli 压缩能力，也**没有官方或主流社区维护的「Brotli 压缩辅助插件」**——这不是遗漏，而是设计使然：Brotli 是服务端/构建阶段的传输层优化手段，不是编辑器需要实时介入的文本处理功能。
为什么 Sublime Text 不适合做 Brotli 压缩操作
你真正想做的，大概率不是“在编辑器里点一下把当前文件压成 .br”，而是：
- 构建时自动产出 index.html.br 配合 Nginx 静态服务
- 或者本地快速验证某个 HTML/JS 文件用 brotli -q 6 压完有多大
- 又或者希望保存时自动触发压缩（但这是危险且无意义的）
- Sublime Text 的插件生态围绕「编辑行为」展开（如语法高亮、代码跳转、多光标），而非「构建与部署」；它没有进程管理、二进制调用、异步 I/O 的安全沙箱，强行调用
brotli命令容易卡 UI 或权限失败 - 所有靠谱的 Brotli 实践都发生在构建工具（Vite/Webpack）或服务端（Nginx/Apache），编辑器只负责写源码——把压缩逻辑塞进 Sublime，等于让螺丝刀去干车床的活
- 即使有极个别第三方插件尝试封装
brotliCLI 调用，也会因路径、权限、编码、并发等问题频繁崩溃，且无法对接brotli_static on这类服务端关键配置
真正该做的：把 Brotli 移出 Sublime，放进构建流程
如果你正在用 Vite 开发，vite-plugin-compression 就是你需要的「无损、快速、可靠」的 Brotli 实现——它不依赖 Sublime，但能让你在保存 main.js 后，dist/main.js.br 自动就位：
- 安装：
yarn add vite-plugin-compression -D - 配置中明确指定：
algorithm: 'brotliCompress'（不是'gzip'） - 务必设
ext: '.br'和deleteOriginFile: false，否则会删掉原始文件 -
threshold: 1024是合理下限——小于 1KB 的文件压缩后反而更大，Brotli 会跳过
如果非要从 Sublime 触发一次 Brotli 压缩（调试用）
可以临时用 Sublime 的 build system 调用系统 brotli 命令，但仅限单文件、手动触发、且需提前装好命令行工具：
- 先确认终端能跑：
brotli --version（Ubuntu：sudo apt install brotli；macOS：brew install brotli） - 新建 Build System（
Tools → Build System → New Build System…），内容如下：
{
"shell_cmd": "brotli -q 6 -f \"$file\" -o \"$file.br\"",
"selector": "text.html,source.js,source.css",
"working_dir": "$file_path"
}
- 保存为
Brotli.sublime-build，然后按Ctrl+B（Windows/Linux）或Cmd+B（macOS）运行 - ⚠️ 注意：
-f强制覆盖，$file.br必须和原文件同目录，否则 Nginxbrotli_static on找不到 - 别绑定到保存事件——它不是编辑器该管的事，而且失败时不报错，只会静默丢数据
真正容易被忽略的点是：Brotli 是否生效，永远取决于 Nginx 是否返回 content-encoding: br，而不是你本地有没有 .br 文件。Sublime 再怎么折腾，也替代不了那行 brotli_static on; 配置。
