Node 22 环境下 Hexo 部署样式丢失与生成失败的踩坑指南
如果你最近在 Windows 环境下升级了 Node.js v22，并且在使用 Hexo 搭建博客时发现：
- 本地预览正常，但线上 GitHub Pages 样式全乱（404 找不到 CSS）。
- 执行
hexo g后，public/css目录下空空如也，完全没有生成style.css。 - 执行
hexo d时报错Exit Code 1，提示在 “Copying files” 阶段强行退出。
那么恭喜你，你撞上了 Node v22 与 Hexo 插件生态之间极其隐蔽的异步流冲突。本文将记录这一路排查的心路历程，并给出目前的终极解决方案。
1. 现象分析：消失的 CSS
问题的爆发点在于 Hexo 的样式渲染器（如 hexo-renderer-stylus）。
在 Node 22 中，由于底层 V8 引擎对异步处理和文件流（fs）的内核改动，导致这些基于古老 Bluebird 承诺库的插件在处理磁盘 IO 时会发生静默崩溃。
具体表现为：
当你运行 hexo g 时，控制台看起来风平浪静，但实际上 Stylus 渲染进程在读取 .styl 文件时已经悄悄锁死了。Hexo 框架为了保证流程不中断，会直接“跳过”出错的 CSS 编译环节。结果就是 public 文件夹虽然生成了，但最重要的样式表文件却不见了。
2. 为什么官方部署插件会失效？
不仅是生成阶段，部署阶段的 hexo-deployer-git 也是重灾区。
该插件在执行 hexo d 时，会尝试将 public 目录的文件拷贝到 .deploy_git 临时目录。在 Node 22 环境下，这个“拷贝文件”的动作会触发 Node 内核的流阻塞，导致进程直接抛出 TypeError 或 Exit Code 1 强行自杀。
这也是为什么很多同学发现无论怎么重装插件，部署依然卡死在第一步的原因。
3. 解决方案：一套组合拳
在没法立刻让插件作者更新代代码的前提下，我们采用了“底层绕后”的策略：
第一步：强制清除缓存（疏通管道）
Hexo 的缓存文件 db.json 极易在崩溃时记录错误的文件指纹。在尝试任何操作前，必须执行：
1 | npx hexo clean |
第二步：编写自动化部署脚本 deploy.bat（核心方案）
既然官方插件在 Node 22 下“水土不服”，我们干脆放弃插件，回归原生 Git。
我们在博客根目录创建了一个名为 deploy.bat 的批处理文件，逻辑如下：
- 自动 Clean & Generate：确保每次都是从零开始编译。
- 加入“死活检查”机制：在推送前，脚本会自动检查
public\css\style.css是否存在。如果没有生成，脚本会立即拦截报错，而不是把坏掉的包传上去。 - 原生 Git 推送：直接进入
public目录，利用系统自带的 Git 命令进行强行推送（git push -f），彻底绕过 Node 插件的 Bug。
提示：这个脚本已经在我的仓库中上线，以后改完文章直接双击运行它，一键搞定生成+部署。
4. 终极建议：回归稳定
虽然 deploy.bat 解决了部署问题，但环境的隐患依然存在。
强烈建议：
如果你追求极致的开发体验，请使用 Node.js v20 (LTS)。
Node 20 是目前 Hexo 生态支持度最高、最稳定的“黄金版本”。你可以使用 nvm-windows 工具轻松实现版本切换：
1 | nvm install 20.18.0 |
结语
技术之路就是不断拆解问题、降维打击的过程。当自动化的插件不再可靠，回归底层的命令行往往是最强力的武器。
愿你的博客永远样式整齐，部署丝滑。