企业官网建设流程全解析

折腾了两个晚上，我的Hexo博客终于搭好了。说实话，整个搭建过程里最折磨人的不是代码，而是选择困难症：博客框架、主题、托管平台、评论系统、搜索统计……每一步都有好几个方案摆在面前，看着都合理，选起来又怕后悔。这篇就是这个系列的第一篇，不急着铺开讲完所有教程，先把当时纠结最多的几个选型问题复盘一遍。如果你正准备搭个人博客，正卡在“到底选哪个比较好”的阶段，这篇文章应该能帮你省下不少时间。

先说一下这篇的定位。它不是一篇标准的环境搭建手册，而是一篇“选型笔记”。我会把每个环节里我真正纠结的点、筛选标准、最终决定以及这个决定带来的后续影响都写清楚。很多教程只告诉你“这样做”，不告诉你“为什么要这样做”。但博客这个东西，选型的影响会持续很久，今天偷的懒，以后都会变成维护成本。

1. 框架选型：为什么劝你留在Hexo

1.1 静态博客方案到底怎么挑

很多人一上来就问“哪个框架最强”，我反而先列了一串需求。我的使用场景很明确：用Markdown写文章，生成纯静态网页，不需要数据库和服务器，大部分托管免费，偶尔要换主题、加插件。静态博客生成器天然符合这些需求，剩下的问题只是选哪个。

市面上的主流方案大致有几类。第一类是以Hexo为代表的Node.js生态，特点和优势是历史久、教程多、主题和插件丰富，尤其的中文资料非常多，遇到问题基本一搜就有答案。第二类是以Hugo为代表的Go生态，最突出的优势是构建速度飞快，上千篇文章也能秒级生成，单二进制文件部署，看起来非常清爽。第三类是Jekyll，它被很多代码托管平台默认支持，属于老牌元老，但Ruby环境在部分系统上折腾起来让人头疼。第四类是VuePress、VitePress这类文档型生成器，做知识库和文档站点很顺手，但拿来做个人博客，很多博客专用功能要自己额外凑。第五类是Astro这类新锐框架，组件化、灵活度高，但也需要更多前端功底。

我一开始在Hexo和Hugo之间摇摆了很久。Hugo的“快”是真实存在的，尤其是文章数量上来以后，Hexo每次重新生成都能明显感到等待时间变长。但反过来，我对Hugo的模板语法并不熟，它的主题需要自己去啃模板结构，而Hexo这边插件、主题、问答都更容易找到中文资料。对一个目标是长期写作、而不是研究生成器原理的人来说，Hexo的学习成本确实更低。

所以最后决定理由特别朴素：不是Hexo最强，而是它最不需要我分心。写博客的核心是写，不是折腾框架。前期花一点点时间装好Node环境，后面基本就是在写Markdown、做内容规划，很少需要关心构建原理。我给自己列了一个需求清单，全部打勾之后才下的决定：能够用Markdown写作、生成静态页面、免费托管、自定义域名、有评论和站内搜索、不依赖某一家平台、迁移成本低。逐条对比下来，Hexo是综合满足度最高的一个。

1.2 选了Hexo之后要接受的三件事

选Hexo不全是优点，有些代价需要提前知道，否则后面容易产生“当初怎么选了这个”的错觉。

第一，Node环境在不同系统上体验差异挺大。macOS和Linux还好，Windows上如果环境变量没配对，全局命令经常出现“不是内部或外部命令”的提示。虽然解决方法并不难，但对刚到命令行的小白来说，这是第一道坎。第二，生成速度确实比Hugo慢。文章只有几十篇时感觉不明显，到几百篇之后，每次执行生成命令都要多等几秒。这个速度完全能接受，但如果你追求极致效率，会觉得很难受。第三，插件版本和Node版本会互相影响。装插件时最好看一眼作者是否有维护，否则装上一个长期不更新的插件，很可能在某次升级后突然失效。

这些代价谈不上致命，但一定要有预期。我的建议是：纯内容型选手，Hexo是低门槛的稳妥选择；如果你非常在意构建速度，且愿意花时间研究模板逻辑，Hugo完全值得考虑。选型本来就不存在“唯一正确答案”，只看哪一种更贴近你的使用习惯。

2. 主题选择：比框架更让人纠结的事

2.1 筛选主题的三个标准

框架定了以后，我以为接下来会很轻松，结果打开Hexo主题列表才发现，这才是选择困难症的重灾区。主题实在太多了，从极简到华丽，从清新到硬核，光看预览图就能翻一小时。越往后看越容易犯迷糊，感觉每个主题都差不多，又总觉得下一个会更好。

后来我给自己定了一套筛选流程，无论主题列表里有多少候选，最后只按三个标准来过滤。

第一个标准是维护活跃度。主题本质上是开源项目，如果作者长时间不更新，一旦新版Hexo发布，或者某个底层依赖发生变化，主题就可能出现兼容问题。没人修的话，后期会非常难受。我一般会点开主题仓库，看最近一次的提交时间是否在一年以内，再看issue区有没有大量未处理的问题报告。第二个标准是移动端表现。现在有相当一部分访问来自手机，很多主题桌面端很漂亮，但把窗口缩小之后，链接挤成一团、字号小得没法看。我会把预览页面直接拖到手机宽度过一遍，再决定要不要继续深入了解。第三个标准是文档完整程度。主题文档决定了后期升级和魔改的难度，一份合格的文档至少要有配置项说明、目录结构说明和常见问题说明。

这三个标准能筛掉一大批“看着好看但养不活”的选项。主题不是越大牌越好，关键要看适不适合自己的写作场景。

2.2 最终选型与魔改尺度

最后留在备选名单里的有两款：一款是走极简路线的老牌主题，一款是比较华丽的双栏主题。我最终选了前者。理由也很实际：它的配置项做得非常成熟，菜单、侧边栏、打赏、评论、统计这些博客常规功能，大部分都可以通过配置文件直接开关，不需要修改源码。主题本身已经维护了很多年，踩坑的人多，遇到问题基本能搜到对应解决方案。

不过默认效果的辨识度确实不高，一眼看上去就是标准的博客脸。这里有一个我特别想提醒的经验：拿到主题之后，先别急着修改源码。正确的魔改顺序应该是，先改主题配置文件，能用配置实现的效果，绝不动代码；改不了的地方，再通过自定义CSS覆盖；最后实在不行，才考虑修改模板。这样做的最大好处是，以后主题升级时，你的改动不会被覆盖，出现问题时也更容易定位。

我按这个顺序调整了首页摘要长度、正文字号、代码块配色和标签页布局。全程没有动主题源码，最后呈现出来的样子，已经和一切默认效果拉开了明显差距。“魔改”并不等于把代码大卸八块，用配置和样式做微调，是性价比最高的方式。

3. 部署与托管：让博客真正能被访问

3.1 托管平台怎么选

博客生成出来以后，还得决定把静态文件放到哪里。这个选择同样磨人，因为没有一个绝对正确的方案，只有适不适合当前阶段。

我在评估时把成本放在很靠前的位置。个人博客没有商业化目的，能省则省。当时看了几条路线。第一是代码托管平台自带静态页面托管，免费、稳定，而且和代码仓库天然集成，Hexo一键推送到远程仓库就能发布。第二是专门的自动化托管平台，连接代码仓库后自动构建、自动发布，自带CDN和HTTPS，配置十分灵活。第三是云服务器，自由度最高，但涉及到服务器运维、安全补丁、续费成本和环境问题，对纯写作的人来说负担偏重。第四是对象存储加CDN，链路简洁、性能好，但按量付费，对免费博客来说不是首选。

考虑到部署链条要足够短，我选了代码托管平台自带静态页面托管。Hexo本身支持配置部署参数，提前填好仓库地址，后面每次写完文章只需执行一条部署命令，不需要额外维护构建环境。如果你希望每次提交代码后，线上博客自动更新，那么选自动化托管平台会更舒服。静态文件的优势是通用性强，以后想从A平台迁移到B平台，成本几乎为零。选型的时候不需要把这条路堵死，先选一条简单路线跑起来更重要。

3.2 自定义域名与HTTPS

静态托管平台默认都会提供一个二级域名，作为博客地址也能用，但长期看，我还是建议绑定自己的域名。一方面是因为好记，方便建立个人品牌；另一方面，未来更换托管平台时，域名可以跟着走，读者只认你的域名，不认平台。

绑定时会涉及两条解析记录：根域名和www子域名。具体配置取决于托管平台的要求，有的用A记录指向一组IP，有的用CNAME记录做别名。我注册好域名后，按平台要求把这些解析记录都加了上去。然后在站点目录的source下放了一个CNAME文件，文件内容就是我希望使用的完整域名。这样做是有讲究的：CNAME文件放在source目录里，每次Hexo生成静态页面时，它都会自动复制到public目录，部署后就能被平台正确读取。以前不少人图省事，直接在public目录里手写CNAME，结果执行清理命令时被一并删除，自定义域名过几天就神秘失效了。

HTTPS方面，主流托管平台基本都能自动签发和维护证书，只需要在后台打开强制HTTPS选项。切换域名时有一个很多人忽略的坑：不仅要在托管平台更新域名设置，还要同步修改Hexo站点配置文件里的url字段。如果只改平台不改配置，RSS订阅和站点地图里生成的文章地址仍然是旧域名，等于站内资源和大门不一致。

3.3 一键部署流程

部署的目标是让自己不用记住一串复杂命令。我提前设定好一条命令链：清缓存、生成静态文件、推送到远程仓库。一句话就是“清理、生成、发布”。

配置主要分三步。第一步，安装部署插件。在Hexo中，这个插件负责把生成的静态目录推送到远程仓库。第二步，在站点根目录的配置文件里设置部署参数，包括部署方式为git、远程仓库地址、目标分支。第三步，确认远程仓库地址和托管平台要求的一致，很多平台要求使用main分支或专门的发布分支。第一次配置时，最容易把仓库地址和协议搞混。建议直接用HTTPS地址，省去额外配置SSH密钥的环节。

npm install hexo-deployer-git --save

然后在站点配置文件里填写类似下面的内容：

deploy: type: git repo: https://example.com/yourname/your-blog.git branch: main

如果连这条命令都嫌麻烦，可以用自动化构建。把博客源码放到代码仓库，在托管平台的自动化流程里配置一个构建任务：安装依赖、执行生成、发布产物目录。我后来就把手动部署改成了自动部署。每次写完文章，提交源码，远程就自动更新线上博客。表面上看省下的操作很有限，但实际体验完全不同，不用再记任何部署命令。

需要注意，自动化构建同样依赖部署插件，并不是有了自动化流程就可以跳过插件安装。自动化的作用是把“执行命令”这个动作交给平台，而不是取消部署动作本身。

4. 配套功能：评论、搜索、统计，又是一轮选择题

4.1 评论系统：数据放在哪里才是关键

博客搭好后，自然会希望有人互动。静态博客没有自带评论后台，所以评论方案绕不开。常见的路线大致有三条，每一条的取舍都很明显。

一种是基于代码仓库Issues的方案。核心思路是把每篇文章的评论区，映射到代码仓库的一个Issue。读者用代码平台账号登录后就能评论，评论内容以Markdown形式保存在Issue里，不需要单独搭服务器，数据完全由自己控制。缺点是评论者必须要有代码平台账号，对非技术访客来说存在一定门槛。另一种是第三方评论SaaS服务。注册后在页面里嵌入一段脚本就能用，支持微信、QQ、邮箱等多种登录方式，对普通访客友好。但数据托管在第三方服务上，一旦平台调整或停服，评论数据就面临风险。最后一种是自建评论后端，需要服务器和数据库，稳定性和可控性最强，但维护成本很高。对于个人博客来说，日活可能只有个位数，单独为评论准备一台服务器实在奢侈。

我最终选了基于代码仓库Issue的方案，因为我的读者主要是开发者和写作者，拥有一个代码平台账号并不是很高的门槛。同时我给自己留了退路：如果以后读者群体扩大，还可以接入第三方SaaS服务。评论系统在Hexo里属于可替换模块，不会影响博客整体结构，选错了也能随时调整。

4.2 搜索、统计与其也插件的取舍

除了评论，还有一堆配套功能可以做：站内搜索、访问统计、RSS订阅、站点地图、分享按钮、文章置顶、字数统计……每一个功能背后都有对应插件，也很容易陷入“别人有的我也要有”的心态。

站内搜索，我选了本地生成索引的方案。原理是在博客构建时生成一个搜索索引文件，页面上通过本地脚本匹配关键词，不调用外部搜索服务，也不存在把访问数据交给第三方的问题。劣势很直接：文章多了以后索引文件会变大，加载速度会稍慢。对个人博客来讲，几百篇文章完全可接受，没必要为了极端情况引入复杂的搜索服务。

访问统计没有选那些功能复杂的流量分析工具，而是用了一个极简计数脚本。页面刷新就能看到访问量，够用就行。准确度不需要吹毛求疵，博客的主要目的是记录和输出，统计只是辅助参考。RSS订阅和站点地图sitemap，我会建议安装。sitemap能帮助搜索引擎更快发现新文章，RSS则给老派读者保留一个纯粹的订阅通道。两个插件占用的资源都很小，性价比很高。

到了这一轮，我的决策原则已经完全清晰：优先选不依赖第三方服务的、维护频率高的、配置简单的。功能宁缺毋滥，每多一个插件，就多一份加载成本，也多一个潜在的兼容问题。

5. 搭建过程实录：从零到第一篇能访问的文章

5.1 环境准备与初始化

光说不练假把式。现在把搭建过程完整过一遍，照着做也能跑起来。

第一步，确认Node环境。打开终端，输入node -v和npm -v，如果提示命令不存在，就需要先安装Node.js。版本不用追新，选择官方长期支持版即可，太新的版本偶尔会让一些老插件水土不服。第二步，安装Hexo命令行工具，执行npm install -g hexo-cli。安装完成后，输入hexo -v应该能看到版本信息。第三步，初始化站点。在准备放博客的目录下，执行初始化命令，然后进入目录安装依赖。

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

初始化完成后，目录里会出现source、themes、public、scaffolds等文件夹。平时只需要关注source/_posts，文章都写在这里。scaffolds里放的是模板，通过命令行创建文章时会自动套用。这时执行新建文章命令，打开新生成的Markdown文件，替换成自己的内容，就完成了第一篇文章的雏形。

这个阶段我踩过的一个坑是：在一个已经存在Git仓库的目录下直接初始化博客，容易把旧的项目元数据混进新博客里，后续提交、部署都会变得很混乱。建议每个博客使用一个全新的独立文件夹，不要和其他项目混放。

5.2 配置文件里的关键参数

站点根目录的配置文件是整个博客的总控制台，很多选型结果最终都会沉淀在这里。

第一项是站点信息，包括站点标题、副标题、描述、作者和语言。尤其语言要改成zh-CN，否则主题菜单、日期格式仍然是英文。第二项是URL，这里填最终打算使用的完整域名。这个字段会直接影响RSS和站点地图生成的文章链接，千万不能随便填。第三项是主题设置，theme字段要和下载的主题文件夹名称保持一致，否则主题不会生效。第四项是部署配置，把前面托管环节确定的仓库地址和分支填进去。

需要注意，站点根目录和主题目录下各有一个配置文件。站点配置管大方向，主题配置管具体样式。新手经常把两者混到一起，改了主题配置之后发现没反应，其实是文件路径搞错了。如果某次修改不生效，先冷静看看自己正在编辑的是哪个配置文件。

5.3 本地预览与写作流程

配置好之后，先不急着部署，本地预览确认效果。终端运行本地服务命令，然后浏览器打开localhost:4000，看到的博客就是最终上线时的大致样子。任何主题或样式改动，都可以先在本地检查一遍，再决定是否部署。

我的写作流程一般是：先新建文章，然后打开Markdown文件写正文。正文里不需要关心HTML，只需要遵循Markdown语法。插图时，我会先把图片放进source/images目录，再在文章里用相对路径引用。标签和分类写在文章开头的Front Matter区域，Hexo会自动处理归类。写完后本地预览一眼，确认格式没有问题，最后执行部署命令。

一个小技巧：新建文章时如果还没想好正式标题，可以先用一个临时标题。重要的是Header里的文章标题字段，文件名后期改掉也不会影响显示。这个细节能避免很多“文章标题改了，文件名却乱成一锅粥”的尴尬。

6. 常见问题排查与避坑实录

6.1 依赖安装与版本问题

搭建过程中，最常遇到的黑屏时刻基本都集中在环境依赖上。我整理了一张速查表，这些坑基本覆盖了新手会遇到的大部分情况。

尤其是Node版本，很多老主题和老插件长期停留在旧API上，一换新版本就报错。这往往不是配置错误，而是生态更新速度没跟上。处理方式不是硬刚，而是把Node固定在长期支持版本上，减少变量。

6.2 样式与路径问题

第二个高频问题集中在主题和路径上。经常出现的情况是：本地预览一切正常，部署到线上之后样式全部丢失，图片也裂了一大片。

原因基本可以锁定在两个位置。第一，root路径。站点配置里的root默认是/。如果部署到子目录，就要把root改成子目录路径，否则CSS、JS和图片都找不到正确位置。第二，图片引用路径。如果Markdown里用了绝对路径，一旦换域名或换部署目录，所有图片都会失效。我习惯把图片统一放在source/images，用相对路径引用。修改主题后不生效，一般先执行清理命令清掉旧的生成文件，再重新生成，否则旧缓存会和新样式互相干扰。

6.3 部署与域名问题

最后是部署和域名。执行部署命令时偶尔会报错，常见提示包括远程仓库地址错误、认证失败、分支冲突。排查顺序是：先确认部署配置里的仓库地址和分支是否正确；再确认电脑能否正常访问代码托管平台；最后确认平台要求的分支名。一旦认证方式变了，比如从用户名密码登录改成需要令牌，部署命令可能瞬间失效。这不算代码问题，但足够让人原地困惑很久。

另一个坑是部署到托管平台的同时绑定了自定义域名，但CNAME文件丢了，导致域名被重置。解决方式前面说过，把CNAME文件放在source目录，让它随着每次生成自动发布。如果改过域名，还要记得全局替换旧域名为新域名，再重新生成部署。否则旧文章里的链接会继续指向旧地址，严重影响使用体验。

写到这里，我的选择困难症算是基本治好了。回想前两天，我纠结的其实不是选项本身，而是总想选一个“永远正确”的方案。后来发现没有任何方案能永远正确。博客这个东西，内容才是核心，平台和主题都是可以随时换的。先让最简单的版本跑起来，持续写上几篇文章，你会比盯着各种榜单比较时更清楚自己真正需要什么。希望这个系列的开篇，能让正在纠结的人少走几步弯路。