文件大小异常大主因是BOM、base64图片嵌入、未压缩HTML或SSR调试信息残留；应检查\uFEFF、data:image/、启用html-minifier关键参数，并确保生产模式构建。
用 fs.writeFileSync 保存 HTML 文件时文件大小异常大？
直接写入字符串内容却生成了远超预期的文件，大概率是编码或换行符问题。Node.js 默认用 UTF-8 编码，但若原始字符串含 BOM、多余空格、未压缩的 HTML 结构，或误用了 Buffer 冗余转换，体积会明显膨胀。
- 检查是否在字符串开头意外拼接了
\uFEFF（UTF-8 BOM），它占 3 字节但不可见 - 确认没把 HTML 字符串转成
Buffer后又 toString() 回字符串再写入——这可能触发二次编码 - 避免用
JSON.stringify(htmlStr)写入，它会加引号和转义，体积翻倍 - 用
fs.writeFileSync('out.html', htmlStr, 'utf8')，显式指定编码，比默认更可控
HTML 文件里嵌了 base64 图片导致体积暴增？
这是最常见也最容易被忽视的“假性大文件”原因：一张 100KB 的 PNG 转成 base64 后约膨胀至 137KB，还失去浏览器缓存能力。一旦页面内嵌多张，体积雪球效应极强。
- 用
file-size或命令行ls -lh out.html确认真实体积，再搜索data:image/定位嵌入点 - 开发阶段可保留 base64 方便调试，但上线前务必替换为相对路径引用
- 若必须内联，优先用 SVG（文本格式）替代 raster 图片；PNG 可先用
svgo或pngquant压缩再转 base64
用 html-minifier-terser 压缩后体积没变小？
不是工具没用，而是默认配置对现代 HTML 收效有限，甚至可能因保留注释或不处理空白而失效。
- 关键参数必须显式开启：
collapseWhitespace: true、removeComments: true、minifyCSS: true、minifyJS: true - 注意
removeRedundantAttributes和removeScriptTypeAttributes这类细节能再省几字节 - 若 HTML 含大量动态插入的
style或script标签，压缩器可能跳过它们——先确保内容是静态字符串再传入 - 别在压缩后又用
prettify格式化，那等于白压
服务端渲染（SSR）输出的 HTML 比本地生成的大很多？
SSR 框架（如 Next.js、Nuxt）默认注入运行时脚本、数据属性、hydration 所需的 JSON、开发模式 sourcemap 链接等，这些在生产构建后应剔除。
立即学习“前端免费学习笔记（深入）”；
- 确认是否在
production模式下构建并启动服务，process.env.NODE_ENV !== 'production'会保留大量调试信息 - 检查
next.config.js或nuxt.config.ts中是否禁用了compress: true（影响 gzip，但不改变原始 HTML 大小） - 服务端返回前用
res.set('Content-Encoding', 'gzip')是传输层优化，不影响磁盘上 .html 文件本身的大小 - 真正要减小落地文件体积，得从 SSR 输出源头控制：删
__NEXT_DATA__中冗余字段、关掉devIndicators、避免在 HTML 中 dump 整个状态树
hexdump -C out.html | head 看前几十字节，一眼定位隐藏字符。 
