injection.js未被压缩是因为未被vite识别为构建入口；需将其移至public/并配置rollupoptions.input动态注册，使其参与tree-shaking、terser压缩和哈希命名。
Web 可访问资源（web_accessible_resources）里的 JS 文件默认不走 Vite 构建流程，也就没有压缩、TS 编译、哈希命名——这是浏览器扩展开发中最常被忽略的构建断点。
为什么 injection.js 没被压缩？
Vite 的构建图谱只从显式入口（如 main.ts、background.ts）开始分析。而 manifest.json 中 web_accessible_resources 列出的脚本，比如 "src/injection.js"，若未被任何模块 import 或作为 Rollup 输入声明，CRXJS 插件会直接将其当作静态资产拷贝进 dist/，跳过所有构建步骤。
- 现象：构建后
dist/injection.js体积大、无 sourcemap、文件名不变、含未编译 TS 语法 - 根本原因：它没进入 Rollup 的
build.rollupOptions.input - 不是路径写错或插件没启用，是“根本没被识别为要构建的代码”
如何让 injection.js 进入 Vite 构建管线？
核心动作是把它注册为一个 Rollup 输入项，并确保路径可解析。推荐做法：把脚本移到 public/ 下，再在 vite.config.ts 中动态注入输入列表。
- 把
src/injection.js移到public/injection.js（public/下文件默认可被 Vite 直接作为入口处理） - 更新
manifest.json中对应路径为"injection.js"（必须与构建后路径一致） - 在
vite.config.ts中读取 manifest 并追加 input：
build: {
rollupOptions: {
input: {
...manifest.web_accessible_resources
.flatMap(item => item.resources)
.filter(p => p.endsWith('.js'))
.reduce((acc, p) => {
const key = p.replace(/\.js$/, '');
acc[key] = `public/${p}`;
return acc;
}, {} as Record<string string>),
}
}
}</string>
这样 injection.js 就会像 main.ts 一样参与 tree-shaking、Terser 压缩、哈希命名（生成 injection.xxxx.js）。
vite-plugin-compression 对 web_accessible_resources 有效吗？
无效——它只作用于最终输出的 dist/ 文件，且只压缩已存在的产物。如果 injection.js 根本没被构建（仍是原始拷贝），那插件连它的文件都看不到。
- 先确保文件被构建（上一步），
vite-plugin-compression才能对它生成.gz和.br - 注意：Brotli 压缩需服务端配合（如 Nginx 的
gzip_static on+brotli_static on），否则浏览器收不到压缩版本 - 不要在开发模式下启用该插件，它只应在
command === 'build'时激活
容易被忽略的路径一致性陷阱
CRXJS 要求 web_accessible_resources 中的路径必须是相对于 dist/ 的运行时路径。如果你在 vite.config.ts 中把 input 设为 src/injection.js，但没改 manifest，或者用了别名却没重写输出路径，加载时就会 404。
- 最稳方案：脚本放
public/，manifest 写相对路径（如"injection.js"），不依赖别名或重写 - 避免用
resolve.alias混淆构建路径和运行路径 - 构建后务必检查
dist/manifest.json里的resources字段是否匹配实际输出文件名（尤其是哈希变化后）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
