企业官网建设流程全解析

如果你正在纠结"要不要搭一个个人博客""到底用什么方案"，我想先分享一个结论：GitHub Pages加Hexo这套组合，至今仍是我见过性价比最高的个人博客方案。我最早也试过租服务器跑动态站的路子，后来被续费、备份、安全补丁这些事反复折腾，最终把博客完全切到了这套静态方案上，跑顺之后日常写字基本只碰两个命令，省下来的精力全花在内容上。这篇文章会把当初踩过的坑和完整的落地流程都讲清楚，从选型逻辑、环境准备、初始化、部署到主题定制和常见问题排查一条线走下来，跟着做基本上一个小时左右就能让自己的博客在公网访问到。

1. 选Hexo与GitHub Pages：静态博客是被低估的长期选项

很多人搭博客的第一直觉是"租一台服务器，装个WordPress或者Typecho"。这条路本身没有错，但你要承担的成本往往被低估了。服务器需要持续续费，数据库要定期备份，PHP和各类插件要盯紧版本和补丁，一旦哪个月忘记续费或者懒得升级插件，轻则数据丢失，重则整站被挂马。我见过不止一个朋友因为这些问题最终放弃了维护，博客死在了半年后某个忘记续费的清晨。

静态博客的底层逻辑完全不同：它本质上是把文章生成成一批静态HTML文件，扔到任何能托管静态文件的地方就能跑。GitHub Pages恰好免费提供这种托管能力，你只要把生成好的文件推到仓库里，Pages会自动发布成公网站点。整个过程没有服务器、没有数据库、没有运维面板，访问速度天然快，因为每个请求都只是在拿一个普通文件，而不是执行一段动态脚本。更重要的是可迁移性：全站就是一堆文件，哪天想换托管平台，打包搬走就行，不存在锁死问题。

在静态博客生成器里，我实际对比过几条主流路线。Jekyll虽然被GitHub Pages原生支持，但依赖Ruby环境，本地编译和依赖管理的体验在Windows上尤其别扭，我折腾过一段时间后就放弃了。Hugo用Go编写，构建速度快到夸张，但主题和插件的生态规模要比Hexo小一圈，社区中文资料也相对少。VuePress更适合写固定结构的文档站，拿来做个人博客总觉得差点意思。Hexo刚好卡在最舒服的位置：基于Node.js，本质就是一个npm包，安装没有任何隐藏依赖；主题和插件数量是静态博客圈里的头部水平；中文教程和踩坑贴多到搜不完。对于一个主要目标是"专注写作"的人来说，这个生态成熟度非常重要。

我最后选Hexo还有一个更现实的理由：工具的复杂度和写作频率通常是反比关系。工具越简单，你越愿意打开编辑器。Hexo的工作流真的可以压缩成一句话：写Markdown，跑一条命令生成，再跑一条命令发布。没有可视化后台要维护，没有插件市场要天天刷，剩下的时间都是内容时间。下面这套流程就是基于这个选型展开的。

2. 环境准备的三件事：Node、Git和SSH钥匙

开始之前先把三样环境备齐：Node.js、Git、SSH密钥。很多人初始化Hexo时报一堆错，回头看八成是这三者中有一样没弄干净。

2.1 Node.js的版本选择和安装验证

我建议直接装Node.js的LTS版本，去官网下载安装包是最省事的方式。装完之后打开命令行，输入node -v能正常打印版本号，就说明环境没问题。这里有个很多人都栽过的坑：电脑上如果有很老的Node，比如12.x以下，跑Hexo 6基本都会报错甚至直接装不上。我个人建议Node至少保持在16以上，现在v18、v20这些LTS版本跑Hexo都很稳，没必要追太新的奇奇怪怪的版本。

2.2 Git安装与身份配置

Git的安装同样是下载稳定版，一路默认就行。装完最好第一时间配置两个全局参数，否则后续的提交记录会带着一个错误的身份：

git config --global user.name "你的用户名" git config --global user.email "你注册GitHub时用的邮箱"

这里有个容易被忽视的细节：GitHub判断一次提交是不是你，靠的就是commit里的邮箱。如果邮箱和GitHub账号对不上，你的提交不会关联到这个账号，头像和贡献墙都显示不出来。等写了十几篇文章再回头改历史，会非常痛苦，所以这一步务必在一开始就配对。

2.3 SSH密钥：本地与GitHub之间的免密通道

GitHub支持HTTPS和SSH两种仓库地址。HTTPS方式每次push都要输账号密码，虽然可以缓存，但在很多场景下还是会卡到人烦躁。SSH方式只需要配置一次密钥，之后本地到仓库的推送全程免密，这也是我推荐的方式。

生成密钥的命令很简单：

ssh-keygen -t ed25519 -C "你的邮箱"

一路回车会在~/.ssh目录下生成一对文件：id_ed25519是私钥，id_ed25519.pub是公钥。然后打开id_ed25519.pub，把内容复制到GitHub的Settings里的SSH and GPG keys页面，新增一条SSH Key粘贴进去就行。验证是否配置成功：

ssh -T git@github.com

如果看到一段欢迎语，说明链路已经通了。换电脑时的场景我特别提醒一下：新机器上最容易遗忘的就是这步。Git装好了、仓库也克隆下来了，一提交发现没有权限，先检查是不是忘了生成和配SSH密钥。密钥文件属于个人凭据，不要放进任何工程目录里。

3. hexo init之后：目录结构、配置文件和博客骨架

环境备好之后，初始化Hexo其实非常快，但很多人初始化完就开始懵——一堆目录和文件，不知道哪个该改、哪个不该碰。这一节就把骨架彻底拆开讲清楚。

3.1 初始化过程与命令

建议用官方CLI工具来初始化，而不是手动拼接：

npm install -g hexo-cli hexo init blog cd blog npm install

第一行安装的是Hexo的命令行工具，注意这里有个容易混淆的点：hexo-cli是全局的命令入口，而Hexo核心库会作为项目依赖安装到blog目录的node_modules里，两者分工不同。不要手贱全局安装核心库，否则后面项目依赖会乱成一团。hexo init会拉取一套完整博客骨架，npm install把依赖装齐，这时候项目已经可以生成和预览了。

3.2 目录结构：哪些文件需要管，哪些不用管

初始化完成后的目录长这样：

blog/ ├── _config.yml # 站点配置文件 ├── package.json # 依赖清单 ├── scaffolds/ # 文章模板目录 ├── source/ # 博客内容目录（Markdown源文件都在这里） │ ├── _drafts/ # 草稿 │ └── _posts/ # 正式文章 └── themes/ # 主题目录

我的建议是：你日常真正需要操作的只有三个地方——_config.yml、source目录和scaffolds模板。package.json偶尔动一下就够，themes目录在换主题时会用到。最容易被误操作的是后面生成出来的public目录，它是每次构建的产物，hexo clean之后会被完整删除，在里面手工改任何东西都是白费功夫。

3.3 站点配置文件的关键字段

打开根目录的_config.yml，有一批需要认真改的字段。我按优先级列一下：

这里面url和root两个字段是重灾区。如果博客只放在GitHub Pages根路径，url填你最终要访问的地址，比如https://你的用户名.github.io，root保持/就好。但如果以后想部署到子路径或者多级目录，root一旦配不对，主页能打开但所有静态资源的路径全都会错，表现就是样式全乱、图片全挂。初期先把这两个字段和实际部署方式对齐，可以少踩一个很大的坑。

4. GitHub仓库和Pages：让部署链路真正闭合

Hexo生成的是静态文件，但这些文件怎么变成公网可访问的博客，关键在GitHub仓库和Pages的配置上。这里有非常明确的规则，违反一个就可能404半天。

4.1 仓库命名：username.github.io规则

GitHub Pages对个人主页有一套自动映射规则：仓库名必须是你的用户名.github.io这种格式，比如用户名叫somebody，仓库就要叫somebody.github.io。只有这个名字，Pages才会自动把它发布成https://somebody.github.io这个地址。我见过有人建了一个叫blog的普通仓库，然后在Settings里翻半天找不到Pages入口，其实就是卡在这个命名规则上。如果仓库名不是这个格式，Pages功能也能开，但域名会变成你的用户名.github.io/仓库名，访问路径变长不说，后续很麻烦。所以我强烈建议第一步就把仓库名取对。

4.2 开启Pages与部署方式选择

进入仓库的Settings，找到Pages设置项。现在GitHub提供两种发布来源：一种是从分支发布，一种是从GitHub Actions发布。新手最简单的是从分支发布：选择master分支的根目录，保存即可。第一次发布通常需要等待一两分钟，不要一直刷新页面以为失败了。发布完成后，Pages页面顶部会显示你的博客地址，看到绿色勾选状态就说明线上已经生效。

4.3 本地一键部署配置

虽然可以把构建生成的public目录手动拖进仓库，但这种操作方式太过原始。更推荐安装官方部署插件，让Hexo自己完成后台工作：

npm install hexo-deployer-git --save

然后在_config.yml里补上部署配置：

deploy: type: git repo: git@github.com:你的用户名/你的用户名.github.io.git branch: master

注意repo地址我建议用SSH格式（就是git@github.com:...这种），如果用HTTPS格式，每次部署都需要重新验证账号，体验很差。配置完以后，发布博客就是一条命令的事：

hexo clean && hexo g && hexo d

clean清理缓存，generate生成静态文件，deploy推送到GitHub仓库并触发Pages更新。这套手动流程对刚起步的人完全够用，而且能让你理解每一环发生了什么。

如果你更希望"只要push源代码，博客自己部署"，GitHub Actions自动化是更好的选择。需要在仓库里新建一个workflow文件，示例配置如下：

name: Deploy Blog on: push: branches: [master] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm install - run: npx hexo generate - uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public publish_branch: gh-pages

这个方案下，你需要把Pages的Source切到GitHub Actions，然后每次推送博客源文件，Actions会在云端自动安装依赖、生成站点并部署。好处是本地不用再跑hexo d，坏处是对新手来说调试成本高一些。我的建议很简单：第一周先用手动部署把整个链路跑熟，等流程理解了再切换到自动化，不要一步到位。

5. 主题装好只是开始：配置与定制的关键决策

Hexo默认主题非常朴素，基本上没人会直接用。选对主题、配好主题，博客的观感才能有质的提升。这也是整个过程中最让人兴奋也最容易踩坑的一段。

5.1 主流主题选择和对比

目前社区里活跃度高、文档健全的几款主题，我实际用过之后可以给一个简单对比：

选主题这件事，我不建议盯着热门榜反复横跳。主题只是呈现层，真正宝贵的是内容。选一个看起来顺眼、文档能看懂的，然后用足够长的时间去熟悉它，比每两周换一款主题有意义得多。我自己的博客从NexT换到Butterfly，最后还是回到NexT，原因就是折腾少、专注写作。如果你时间有限，直接选NexT大概率不会后悔。

5.2 主题安装与配置覆盖关系

大多数主题的安装方式是克隆到本地。以我用的主题为例，在博客根目录执行：

git clone 主题仓库地址 themes/主题名

然后在站点_config.yml里把theme字段改成主题名，重新生成就能看到效果。这时候你会接触到两套配置文件：站点根目录的_config.yml负责全局参数，而主题目录下的_config.yml负责主题自己的外观参数。很多小白在这里会晕，不知道某个配置该改在哪一边。简单的判断标准是：和SEO、站点信息、部署相关的是站点配置；和布局、颜色、组件开关相关的是主题配置。

有一个关键经验我必须单独说：直接改themes/主题名/_config.yml虽然能生效，但一旦主题更新、你拉取新版本，所有改动都会被覆盖。更稳的做法是找一份主题配置的副本放在站点根目录，或者至少把改动记录下来形成自己的配置文件，每次升级完再重新应用。这听起来是小事，但真有人因为没做这一步，升级一次主题后博客外观彻底变了，又花了一整晚调整。

5.3 常用定制点

主题装好后，最常改的几个地方其实很固定：导航菜单、侧边栏头像、社交链接、站点图标favicon。这些大多在主题配置里都有对应字段，填上即可。更进阶的定制是给博客加功能模块，我实测过比较实用的三个：本地搜索、访问统计和内容复制保护（可选）。本地搜索需要安装hexo-generator-searchdb插件，然后在主题配置里开启local_search，这样站内搜索不用依赖任何第三方服务；访问统计我用的不蒜子，一段脚本引入即可，轻量无侵入；至于评论系统，可选的方案很多，但多数依赖第三方服务，我倾向于建议新手先不折腾，用邮箱和社交链接代替，等博客有了一定访客量再加也不迟。

6. 从hexo new到push：一篇博文的完整生命线

写作是博客的核心，这个章节我们把一篇新文章从创建到上线的完整流程走一遍，你会发现整个流程熟练之后两分钟就能完成。

6.1 创建文章与Front-matter

创建一篇新文章的命令是：

hexo new "文章标题"

这个命令会在source/_posts目录下生成一个Markdown文件，并且根据scaffolds/post.md模板自动填入基础Front-matter。生成的初始内容一般只有title和date两个字段，实际写作时通常要补上更多元信息。我常用的最小模板长这样：

--- title: 文章标题 date: 2024-01-01 10:00:00 tags: - 写作 - 博客 categories: 技术 cover: /img/cover.webp ---

这里有个容易翻车的地方：id、tags这类字段对格式极其敏感，差一个冒号或者缩进，整篇文章就可能渲染不了。好在Hexo生成时会把具体错误打印在终端里，写好之后先本地预览，看到报错顺着提示修就行，比纯靠肉眼找错误舒服太多。

6.2 写作、本地预览与调试

写作本身直接用Markdown语法就行，标题、列表、代码块、引用这些基础语法用熟已经覆盖绝大多数场景。写完一段之后，强烈建议先本地跑预览：

hexo s

然后浏览器访问localhost:4000，改一行、刷新一下就能看到效果，比推到线上再回看效率高一个数量级。需要调整端口时用hexo s -p 5000，比如4000被其他程序占了的时候。本地预览阶段我发现一个常见现象：文章里的图片路径有问题，本地能显示，但部署到GitHub Pages后就裂了。这个问题的根源多半是图片路径写成了本地绝对路径。如果你希望文章里可以引用本地图片，最简单的办法是在站点_config.yml里开启post_asset_folder: true，这样每次创建文章时会生成一个同名资源文件夹，图片放进去用相对路径引用即可。

6.3 发布流程与多设备同步

本地预览满意后，发布就是那条三板斧命令：

hexo clean && hexo g && hexo d

clean很重要，我建议不要跳过，尤其是改过主题配置或调整过站点配置之后。不清缓存有时会继续部署旧的静态文件，让你怀疑自己改了没用。发布成功后，刷新线上地址，新文章就出现了，从创建到上线全程用不了几分钟。

说到多设备写作，这是博客维护里很现实的话题。如果只有一台电脑，博客源文件只在本地，一旦电脑出问题，全部文章数据可能一起遭殃。我的做法是把整个博客目录放进一个私有Git仓库（不是username.github.io那个公开仓库，而是另一个私有的源文件仓库），每次写完提交推上去。换电脑时git clone下来，跑一次npm install，所有环境就齐了。这个习惯的成本极低，收益却是"再也不怕电脑丢失"。

7. 淌过的坑与长期维护建议

最后这部分是实战中积累下来的高频问题和维护经验，每一个我都亲自踩过或排查过，直接按症状、原因和解决办法列出来。

7.1 高频问题排查

这里再单独展开一个容易被人忽略的点：如果你绑定了自己的域名，CNAME文件要放到博客根目录的source文件夹里，而不是直接放到本地生成目录的public里。因为public是清理重建的，放在里面的CNAME每次都会消失，放在source里才会在每次生成时被自动复制到产物目录并推送到线上。

7.2 长期维护建议

博客上线只是开始，真正考验人的是怎么坚持写下去。我的几条实操建议是：

草稿模式要充分利用。写到一半的文章不要急着发布，放到source/_drafts目录，需要时用hexo server --draft做本地预览，写完了再正式发布。这个机制能显著降低写作的心理压力，不会因为"没写完就发布"而放弃更新。

分类和标签要提前定好规则。一篇文章建议只归一个主分类，标签控制在三到五个，避免越写越乱。很多博客写了半年后首页一团乱麻，问题不是文章质量，而是元信息从一开始就没有规范。

依赖升级要克制且定期。不必每个月追新版本，但也不要几年不升。我一般半年左右执行一次npm update hexo和相关插件，升级前会完整备份一遍源文件。静态博客最大的安全感是内容不依赖任何平台服务，但前提是你别把依赖升级这件事拖到出了安全问题才想起来。

还有很重要的一点：任何对主题、配置文件的大改，都先跑hexo clean && hexo g做一次完整生成，确认本地没问题再部署。别嫌多一条命令，很多时候线上那点诡异问题，就是省了这一步造成的。

博客这个东西，工具再花哨，最终拼的还是内容和坚持。Hexo加GitHub Pages的好处，就是它把基础设施的复杂度压到了极低，让你把有限的精力全放在打字上面。希望这篇流程能帮你少走点弯路，早点把第一篇文章发布出去。如果你搭建过程中在某个具体环节卡住了，回头按这个顺序排查一遍，大概率就能找到问题在哪。