你好，我是吴培泽。
第一篇文章聊了这个公众号的定位和初衷，今天想聊聊它的”硬件基础”——互联网笔记（wupeize.com）这个站点是怎么从零开始，一步步走到能访问的。
从买域名、买服务器，到研究了一大堆技术工具，最终回到 WordPress——整个过程用了大概三周。这篇是上半部分，核心是两件事：基础设施准备和技术选型思考。
一、为什么非得自己建站？
这个问题我想过很多遍。
公众号能写、知乎能写、Notion 也能写，为什么非要自己买域名、买服务器、走一遍备案流程？
原因有三：
1. 数据的归属感。 内容写在别人平台上，哪天账号没了、政策变了，几年的积累可能就没了。自己的网站，数据库在自己手里，心里踏实。
2. 品牌的积累。 wupeize.com 是我名字的全拼，它就是一个长期的、可积累的数字资产。十年后这个域名还在，内容也还在。
3. 学习的意义。 作为一个工程师，如果连自己的个人站点都没有完整搭建过，总觉得说不过去。亲自走一遍，才叫真的懂。
二、第一步：买域名
域名是在阿里云万网买的。搜索”wupeize”，.com 后缀还能注册，果断拿下。
价格是 55 元一年，续费同价。不算贵，但那种”这个名字真的属于我了”的感觉，还是挺奇妙的。
几个小细节：
买完域名要实名认证——上传身份证正反面，系统自动识别信息，审核大概 10 分钟通过。这一步没什么难度，但一定要做，不实名域名会被禁止解析。
另外，.com 后缀目前仍然是个人博客的首选。.dev、.tech、.blog 这些新后缀看起来挺酷，但在 SEO 权重和用户认知上，.com 依然是最稳妥的选择。
三、第二步：买云服务器（ECS）
域名搞定了，接下来需要一个放网站文件的地方——云服务器。
我选的是阿里云 ECS，配置是 经济型 e 实例（2核2G + 3M带宽），价格 99 元/年。对于个人博客来说，这个配置完全够用。
选配置的几个考量：
- 地域：选国内（我选的华东），国内访问延迟低，代价是域名必须备案
- 操作系统：这个我纠结了一下——最终没有用 Alibaba Cloud Linux 3，而是选择了 Amazon Linux 2023
- 公网 IP：必须勾选”分配公网 IPv4 地址”，不然网站没法从外网访问
关于操作系统，多说几句。
我最初确实打算用 Alibaba Cloud Linux 3，毕竟是阿里云官方推荐的镜像，兼容 CentOS 生态，理论上应该没什么问题。但在准备环境的时候，我搜了一下 nginx：
dnf list | grep nginx输出里除了官方的 nginx.x86_64、nginx-mod-*，还有一个 aa_nginx——来自 alinux3-plus 仓库。
我当时的第一反应是有点疑惑的：aa_ 这个前缀不常见，而且它和官方 nginx 并存。后来我查了一下，aa_nginx 是 OpenAnolis（龙蜥社区）的一个正当项目——Anolis Accelerated NGINX，基于 Intel QAT 和 DLB 做性能加速，有明确的来源和用途。它的加速能力来自 Intel 官方提供的 QAT 模块，龙蜥社区做的是集成和打包，不是自己魔改 nginx 核心。
它没有问题。Tengine 也是类似逻辑下的产物——都是社区在 nginx 基础上做的扩展。
但这件事让我意识到：Alibaba Cloud Linux 3 的附加仓库里有一些我不熟悉的社区扩展包，虽然它们都是正当的，但增加了我的认知成本。 而且我的个人站点也用不上 Intel QAT 硬件加速——那是给特定硬件和高并发场景准备的。
而 Amazon Linux 2023 我用得很熟——包管理、目录结构、生态都比较简单直接。对于一个个人站点来说，熟悉感本身就是一种可靠性。
所以最终，我选择了 Amazon Linux 2023。
当然，这完全是我的个人偏好。Alibaba Cloud Linux 3 是一个优秀的系统，aa_nginx 也是一个正经的社区项目。只是对于我自己的站点，我更愿意用一个自己完全熟悉的系统。
阿里云官方镜像市场没有 Amazon Linux 2023，所以我选择自己制作镜像并导入。具体过程我会单独写一篇文章来记录。
⚠️ 第一个坑来了：安全组。
买完服务器第一件事不是装软件，而是去配置安全组。安全组相当于服务器的防火墙，必须放行 80（HTTP）、443（HTTPS）、22（SSH） 这三个端口，否则网站死活打不开。
我在这里卡了 2 个小时，各种排查——Nginx 装好了、服务启动了、防火墙也关了，就是访问不了。最后才反应过来是阿里云控制台的安全组没配置。端口一开，瞬间通了。
四、第三步：备案——最考验耐心的一步
这是国内建站绕不开的一步。只要服务器在国内，域名就必须备案。
流程大概是：
- 在阿里云备案系统提交信息，填写网站名称、内容类型、负责人信息等
- 阿里云初审（约 1 天）——会打电话核实身份和网站用途
- 初审通过后，手机会收到工信部的验证码，必须在 24 小时内完成短信核验，否则退回
- 管局审核（3-12 个工作日不等）
我前后等了大概 12 天。这个过程中其实做不了什么，就是等。
⚠️ 第二个坑：短信验证码有时限。
初审通过后要留意手机短信，验证码 24 小时有效。如果没注意到短信，超时了备案会被退回，重新排队，白白浪费几天时间。
⚠️ 第三个坑：备案期间不要解析域名。
备案完成前，域名不能指向国内服务器的 IP，否则管局审核可能不通过。我的做法是等到备案通过那一刻，再去域名控制台添加解析记录。
一个小经验：等待备案期间，可以用服务器的 IP 地址直接访问网站调试，不耽误本地的开发进度。
五、技术选型：我研究了 12 款工具
网站的基础设施准备好了，接下来是一个更关键的问题：用什么工具来建这个博客？
我花了两周时间，系统性地调研了市面上的主流方案。这张清单是这样的：
Hugo
Hugo 是 Go 语言写的，公认的”速度之王”，几千篇文章生成不到 1 秒。主题生态丰富，配置灵活。但它的模板语法比较独特，学习曲线不算平缓，而且主题多归多，真正精致、符合审美的并不好找。
Hexo
Hexo 是 Node.js 生态里最流行的静态博客框架，中文社区非常活跃。NexT 主题很成熟，文档友好。但生成速度会随文章数量增长而变慢，Node.js 的版本依赖偶尔会遇到兼容问题。
VuePress / VitePress
VuePress 和 VitePress 是 Vue 生态的文档生成器。VitePress 基于 Vite，速度很快。但它们的定位是技术文档而非博客，博客相关的插件和主题生态不如 Hexo 成熟。
Docusaurus
Docusaurus 是 Facebook 出品的文档站点生成器，UI 很现代。但设计目标很明确——技术文档，hack 成博客用总有一种”用螺丝刀当撬棍”的别扭感。
MkDocs / GitBook
MkDocs 和 GitBook 偏向项目文档。MkDocs 的 Material 主题很漂亮，GitBook 的交互体验很好，但文章组织方式和博客天然不太匹配。
Docsify
Docsify 运行时动态渲染 Markdown，不需要编译。想法很酷，但 SEO 是硬伤，首屏需要加载整个内容，对个人博客不太友好。
Gatsby
Gatsby 是 React 生态的明星，功能极其强大，能对接各种数据源。但构建速度是痛点，几百篇文章可能要构建好几分钟，GraphQL 的学习门槛也不低。杀鸡用牛刀，而且牛刀还不轻。
Jekyll
Jekyll 是静态博客的”老前辈”，GitHub Pages 原生支持。Ruby 生态，插件丰富。但 Ruby 的环境配置在 Windows 上不太友好，Liquid 模板引擎用起来不如现代方案顺手。
Gridea
Gridea 有 GUI 客户端，不需要命令行，对非技术人员很友好。但自由度相应受限，主题生态不大，高级定制比较困难。
一圈看下来，每个工具都有自己的闪光点，但我也逐渐清楚了一件事：我需要的不只是一个”写文章然后发布”的工具。
静态工具的工作流很顺——打开编辑器、写 Markdown、提交、生成、发布。但我想要的不止这些：
- 文章的交叉引用，我不想手动维护链接，改一个标题还要全局搜索替换
- 分类和标签，我希望可以随时调整，今天归到”AI”，明天想归到”大模型”，能批量处理
- 很多碎片化思考只有两三百字，还没形成完整文章，我需要一个地方先放着
- 我想按多个维度筛选文章，比如”技术领域 + 写作状态 + 难度等级”
这些需求总结起来就是一句话：我要的不是一个”写文章的工具”，而是一个能让我持续管理内容的地方。
六、一个重要的插曲：我其实深度用过 MkDocs + Material
有一件事我必须老实交代——上面说的那些工具里，我不仅仅是”看了看文档”的程度。
MkDocs + Material 主题，我实际用了大概一个季度，写过差不多 30 多篇内容。
当时选择它的原因很充分：
- Material 主题的 UI 设计太舒服了，尤其是暗色模式，视觉体验吊打很多博客主题
- 搜索功能开箱即用，而且是真正的全文搜索，对找笔记特别友好
- 插件生态很实用（mkdocs-git-revision-date-localized-plugin 显示最后更新时间，mkdocs-minify-plugin 压缩静态资源）
- 部署极其简单，
mkdocs build生成静态文件，丢到服务器或 GitHub Pages 就能访问 - 目录结构天然支持”知识库”式的组织方式，和我想整理的内容结构很契合
那段时间我用它来写技术笔记和项目文档，体验确实不错。但也正是在实际使用中，我逐渐发现了一些不够用的地方：
1. 博客属性太弱
MkDocs 的本质是”文档站点”，不是”博客”。它没有原生的按时间归档、没有标签云、没有分类索引、没有 RSS 订阅。虽然有 blog 插件（material 主题后来支持的），但那更像是”在文档站点里加了一个博客模块”，而不是”一个真正意义上的博客”。我需要的是以时间线和分类为核心的博客体验，而不是以目录层级为核心的文档浏览。
2. 文章索引能力有限
在 MkDocs 里，一篇文章只能属于一个目录位置。但现实中的知识是有多重属性的——一篇文章可能同时属于”AI”和”安全”，另一篇可能既讲”Kubernetes”又讲”DevOps”。MkDocs 的标签插件（mkdocs-tags）能解决一部分问题，但交互体验上还是不够流畅。
3. 碎片化内容的处理
我用 MkDocs 写笔记时有个习惯：先把零散的、未成型的想法写成草稿放在一个目录里，等成熟了再整理成正式文章。但 MkDocs 是”编译即发布”，没有”草稿/已发布”的状态管理。需要自己用 draft 前缀或者放在 _drafts 目录里手动控制，不够优雅。
4. 前端定制的门槛
Material 主题已经非常精致了，但一旦你想要的改动超出了主题提供的配置选项——比如想调整文章列表的展示方式、想在首页加一个特定的内容聚合——就涉及到修改主题模板或者写 CSS。MkDocs 使用 Jinja2 模板，我对这个模版引擎并不熟悉，每次改点什么都要查半天文档，投入产出比不高。
5. 写作与浏览的割裂感
mkdocs serve 的本地预览确实很快，但是它在编辑的时候需要手动刷新浏览器才能看到变化，缺少类似 WordPress 古腾堡编辑器那种”所见即所得”的沉浸感。对于写长文来说，体验不够连贯。
正是因为在 MkDocs + Material 上投入了足够多的使用时间，我才意识到：
它是一款优秀的文档工具，但不是一款理想的博客工具。
如果我的目标是写技术文档、API 说明、项目手册，MkDocs + Material 毫无疑问是第一梯队的选择。但我的目标是写博客——以文章为单位、以时间线为轴、以分类和标签为索引、以持续输出为核心——两者的侧重点完全不同。
离开它的时候其实挺不舍的。Material 主题的设计审美真的很好。但工具选型这件事，有时候不是因为”它不够好”，而是因为”它不适合当前的目标”。
七、我也想过用 Laravel 自己撸一个
MkDocs 放下之后，脑子里又冒出了另一个念头：
“要不，用 Laravel 自己写一个？”
说实话，这个想法挺有诱惑力的：
- 完全掌控——分类体系按自己的想法来，文章、笔记、碎片、书摘每种内容类型有不同的字段和展示方式
- 功能按需迭代——今天加”知识图谱”，明天做”阅读统计”，后天接 AI 摘要接口，一个 Laravel 项目可以陪你玩好几年
- 顺便练手——用自己熟悉的框架写一个长期使用的项目，既是练习也是作品
但我最终说服了自己不这么做。
第一，时间成本。 用 Laravel 做一个博客不难，但要做到”有完整后台、编辑器、分类管理、搜索、缓存、SEO、评论、统计、备份……”——这就不是一个”写一个博客”的项目了，是一个小型 CMS。这些功能 WordPress 已经有了，而且打磨了 20 年。我用 Laravel 重新实现一遍，并没有创造新的价值。
第二，维护成本。 自己写的代码自己维护。框架升级了要适配，依赖包有漏洞要更新，服务器环境变了要调整。而 WordPress 的维护是”点一下更新按钮”——社区帮你把活都干了。
第三，内容与代码的优先级。 我问过自己很多次：“我的核心产出是代码，还是内容？” 答案是内容。如果我用 Laravel 自己写，前期一两个月都在写代码、调样式、改功能，写文章的时间被严重挤压。
第四，WordPress 也是用 PHP 写的。 真的遇到 WordPress 搞不定的需求，我完全可以用 PHP 写一个插件来实现。它只是帮我承担了 80% 的通用工作，让我只需要处理那 20% 的特殊需求。
想明白这些之后，Laravel 的念头就放下了。
自己写代码的快感是真实的，但它不是我现在最需要的东西。 我需要的是一个稳定可靠的内容平台，让我能持续输出，而不是一个永远在施工中的个人项目。
八、为什么最终选择了 WordPress？
说实话，我自己也犹豫了很久——WordPress 在很多技术人眼里已经”不酷”了。
但我想明白了一个道理：工具的价值在于它能帮你完成什么，而不在于它本身有多酷。
选择 WordPress 有几个非常实际的原因：
1. 我需要在站点里跑一些动态程序
这是最关键的一条，也是静态博客天然做不到的。
我计划在互联网笔记上放一些在线小工具，比如：
- IP 归属地检测：输入 IP，返回归属地、运营商等信息
- DNS 解析查询：输入域名，返回 A 记录、CNAME、MX 等解析结果
- 内容封面生成：输入标题，自动生成文章封面图的 PHP 程序
这些功能不是”写一篇文章”就能实现的，它们需要服务端逻辑——接收请求、调用接口或执行程序、返回结果。静态博客生成的是纯 HTML 文件，没有后端，做不了这些事。
WordPress 运行在 PHP 上，有完整的后端能力。我可以用 PHP 写一个插件或一个自定义页面模板，把这些工具挂上去。这是静态博客从根本上无法满足的需求。
2. 在内容管理这件事上，它比静态工具强得多
分类、标签、自定义文章类型、自定义字段——这些在静态工具里需要写代码或 hack 才能实现的功能，在 WordPress 里是原生能力。文章状态（草稿/已发布/待修订）、多维度归档、按条件筛选，开箱即用。
3. 修改和调整的成本极低
在静态工具里改一个全局配置，可能要修改配置文件、调整主题模板、重新生成所有页面。在 WordPress 里，后台点几下鼠标就完成了。对于写作为主的技术博客来说，这意味着可以随时优化内容结构，而不需要投入额外的工程时间。
4. 插件生态解决 80% 的需求
搜索、缓存加速、SEO 优化、表单、统计——装一个插件就解决了。只要控制好插件数量，”即插即用”的效率是静态工具难以比拟的。
5. 内置的编辑体验
古腾堡编辑器的块编辑体验，加上修订历史和自动保存，很适合写长文章。在手机或平板上想快速记一个想法时，打开 WordPress 后台就能写，不需要开终端、不需要 pull 代码。
6. 数据和展示是分离的
文章存在数据库里，前端展示方式可以随时更换主题而不影响内容。这意味着我不会被某款工具绑定——未来想换设计，换个主题就行了，所有内容完好无损。
选型定了，接下来就是动手部署。下一篇我会详细记录 WordPress 在阿里云 ECS 上的完整安装、配置和优化过程，包括 Nginx 配置、PHP 调优、数据库创建、SSL 证书配置、以及我踩过的那些坑。
如果你也在纠结用什么工具建站，希望这篇对你有帮助。我们下一篇见。