答案是新建干净目录再执行hexo init。Hexo初始化要求目录为空，若存在.git、node_modules等文件会报ENOTEMPTY错误；推荐mkdir myblog && cd myblog后运行hexo init，避免强行清理导致配置冲突。
Hexo 初始化失败：hexo init 报错 ENOTEMPTY 怎么办
当前目录非空时，hexo init 会直接拒绝执行，不是权限或网络问题，而是 Hexo 的硬性保护机制。常见于你在一个已有 Git 仓库或项目目录里直接运行命令。
- 先确认当前路径是否为空：
ls -a（macOS/Linux）或dir /a（Windows），重点看有没有隐藏的.git、node_modules或package.json - 不要强行删
.git后重试——Hexo 初始化会新建自己的.git，但残留的旧配置可能干扰后续部署 - 最稳妥做法：新建干净目录，比如
mkdir myblog && cd myblog，再跑hexo init - 如果必须复用现有目录，用
hexo init --debug查看具体卡在哪一步，有时是npm install阶段因已有package-lock.json冲突，此时可先rm -f package-lock.json node_modules再试
VSCode 中编辑 Markdown 时预览不更新，hexo server 也没反应
这不是 VSCode 插件问题，而是 Hexo 默认监听机制对文件系统事件不敏感，尤其在 WSL、Docker 或某些 NFS 挂载路径下容易失效。
- 启动服务时务必加
--watch参数：hexo server --watch（默认已启用，但显式写出更可靠） - 检查
_config.yml中的skip_render是否误配了**/*.md，这会导致 Hexo 跳过渲染 Markdown 文件 - VSCode 的自动保存（
files.autoSave）设为onFocusChange或onWindowChange时，可能因保存时机晚于 Hexo 监听触发点而漏掉变更；建议改设为onDelay（延迟 1s）或干脆手动Ctrl+S - 若用主题带自定义 layout，确保
source/_posts/下文件名符合YYYY-MM-DD-title.md格式，否则 Hexo 会跳过解析——连hexo g都不会报错，但页面就是不出现
部署到 GitHub Pages 时提示 ERROR Deployer not found: git
这个错误和 Git 是否安装无关，而是 Hexo 的 deployer 插件未安装或配置错位。即使全局装了 hexo-deployer-git，也必须在博客根目录下单独安装。
- 执行
npm install hexo-deployer-git --save（注意是--save，不是-g） - 检查
_config.yml中deploy区块是否顶格写（YAML 对缩进极其敏感）：deploy: type: git repo: https://github.com/username/username.github.io.git branch: main
- GitHub 新建仓库名必须严格为
username.github.io（username 是你的 GitHub ID），且repo地址中的分支名要和仓库实际默认分支一致（现在大多是main，不是master） - 如果用了 SSH 链接（
git@github.com:...），需确认本地~/.ssh/config已配好密钥，且ssh -T git@github.com能通
自动化发布脚本里 hexo clean && hexo g && hexo d 执行一半就停住
串联命令用 && 本身没问题，但 hexo d 在交互式环境下会等待输入（比如首次推送时问你是否信任 host），导致脚本卡死。CI/CD 或定时任务里必须禁用交互。
- 加
--no-interactive参数：hexo d --no-interactive - Git 提交信息不能留空，否则
hexo d会 hang 住；在_config.yml里显式设message: "Site updated at $(date)"（注意单引号包裹，避免 shell 解析） - 如果用 GitHub Actions，记得在
steps里把NODE_ENV设为production，否则某些主题插件可能跳过压缩或 CDN 处理 -
hexo clean不是必需步骤——它只删public/和.deploy_git/，但hexo g本身就会覆盖public/；频繁执行反而增加 CI 时间，除非你明确需要清掉旧缓存
