这是「把自己部署到互联网上」系列的第 44 篇。
写到这一篇，整个系列已经接近尾声。
从第一篇《2026年了，程序员还有必要搭建个人博客吗？》开始，
我一路写了服务器、域名、备案、安全、Docker、Nginx、HTTPS、对象存储、个人博客上线，再到后面的 Astro 选型、首页设计、作品集整理和 AI 辅助搭建作品站。
从单篇文章看，这些内容像是一篇篇技术笔记；
连起来看，它们完成的是一条路径：
从 0 到 1 搭建个人博客，再把博客、文章、项目整理成一个轻量个人品牌入口。
这篇不再聊技术了，做一次阶段复盘。
回头看这一阶段走到了哪里，完成了哪些事，最关键的问题是什么，以及这套流程以后该如何复用。
先说结论：
- 这一阶段真正做重的是个人博客
- 官网和作品站只是博客之后的轻量升级
- 服务器、域名、备案、Docker、Nginx、HTTPS、对象存储，都是围绕博客上线展开的
个人官网不是另起一个大工程，而是把前面已经做过的事情整理成更清晰的入口。
六个阶段
如果按阶段划分，这一轮大概走了六步。
阶段1： 从想法到服务器
最初的想法，我只是想搭一个自己的博客。
但真正开始做以后，发现第一步不是写代码，而是准备服务器环境：买服务器、登录系统、确认环境、创建普通用户、配置 SSH。
这些基础环境配置，决定了后面能不能稳定部署。
阶段2： 从服务器到域名入口
博客不能只停留在 IP 访问。所以我又买了域名，走了实名认证和备案，处理了域名解析。
这一阶段让我的博客从“本地能跑”变成“别人能通过正式入口访问”。
阶段3： 从能访问到安全可控
服务暴露在公网之后，安全就成了必须考虑的事情了。
我进一步处理了 防火墙、安全组、root 登录、数据库端口、fail2ban 等问题。
这一阶段让我意识到，即使个人再小的项目也会面对安全问题。
阶段4： 从开发环境到生产环境架构部署
我考虑过 Conda 和 Docker 哪个更适合生产环境，也纠结过 Nginx 到底装在哪里。
最后选择 Docker 管理生产环境， Docker Compose 加全局 Nginx 的方式管理应用。
这一阶段，从“能跑”转向“可复现、可维护”。
阶段5： 从部署成功到上线完整
博客能启动还不够，还要处理 SSL 证书、对象存储、数据库迁移、管理员初始化、静态资源访问。
这些细节处理让博客运行更稳健。
阶段6：从博客到轻量个人主页入口
博客上线后，我发现它解决了内容沉淀，但没有完全解决别人如何快速认识我的问题。
于是我开始做个人官网和作品站，把首页、代表文章、代表项目、博客、公众号和 GitHub 整理成一个入口。
到这里，这一阶段，「把自己部署到互联网上」整个合集才算形成了第一版闭环。
五个成果
如果把这一合集成果提取出来，大致有五件事。
成果1：跑通了个人博客从 0 到 1 的上线链路
这不是单纯把博客程序跑起来，而是从服务器、域名、备案、部署、安全、证书、资源管理到数据库初始化，完整走了一遍。
成果2：建立了一个长期内容阵地
博客上线以后，不仅会把内容发在第三方平台，也会发在自己的博客上。
公众号依很然重要，但博客开始承担归档、专题整理、搜索和长期访问的角色。
成果3：梳理了一套个人服务器部署思路
从 Conda 到 Docker，从多个 Nginx 容器到全局 Nginx，从开放端口到安全组和防火墙，理清了适合当自己的服务器的部署方式。
成果4：把实战过程写成了系列文章。
如果只是部署博客应用，这些经验很快会散。写成文章合集后，就变成了可以复盘、搜索、分享，也可以进入作品集的内容资产。
成果5：做了一个轻量版个人官网入口
当文章和项目越来越多，需要一个入口把它们串起来。
首页、文章入口、项目入口、关于我，让别人更容易理解 楸木 是谁，做了哪些东西，研究方向是什么。
五个问题
整个合集走下来，最值得反思的，不是具体命令，而是遇到的几个问题及问题处理过程。
问题1：上线是不是只等于项目能跑？
做之前，把上线理解成项目启动成功。做之后我发现，上线至少包括服务器稳定、域名可访问、HTTPS 正常、数据库可连接、静态资源能加载、端口和权限可控、后续可以维护和迁移。
项目能跑只是第一步，真正上线是整条链路能工作。
问题2：个人小型服务器要不要认真做安全？
先说答案：要。
哪怕只是个人博客，只要放到公网，就会被扫描。
不要长期用 root 裸奔，不要随便开放数据库端口，不要只依赖应用本身安全。
防火墙、安全组、SSH、fail2ban 这些基础动作不复杂，提前做一下，就能大大提升服务器安全。
问题3：生产环境怎么管理项目依赖？
Conda 很适合本地和一些 Python 环境管理场景。
但对我的个人博客部署来说，Docker 更适合长期维护。
它能把运行环境固化下来，也更利于迁移和复现。
这个不是绝对，大家可基于自己的业务场景进行取舍。
问题4：Nginx 怎么管理多个项目入口？
一开始，要按照以前的风格，为每个项目都起一个 Nginx 容器。
但项目变多以后，域名、证书、配置、端口都会分散。
所以我调整成一个全局 Nginx 统一管理多个项目入口。
这个也不是绝对，大家可基于自己的业务场景进行规划。
问题5：博客上线后，为什么还需要个人官网？
博客解决内容沉淀，但不一定解决第一理解。
陌生人第一次打开博客，可能不知道从哪里开始看，也不知道哪些文章最有代表性。
所以我用 AI 打造了一个轻量官网入口。解释项目、链接其他应用入口。
小结：
做完这一轮，我考虑问题的方式也变得系统化了。
一开始我只想简单搭一个博客，后来发现博客背后需要服务器、域名、备案、部署、安全、证书和资源管理。
这些东西加起来，才像一个长期技术阵地。
以前我更关心命令怎么执行，现在更关心为什么这么选
为什么 Docker 而不是 Conda，为什么全局 Nginx，为什么作品站选择 Astro。
取舍本身比单个步骤更值得复盘。
以前我觉得做完就结束，现在更明确：写下来才沉淀。如果只做不记录下来，很快就忘记了；
以前我容易把官网想成展示页面，现在更愿意把它看成理解入口
它负责把博客、文章、项目和 GitHub 组织起来，让别人更快理解我。
如果以后再做类似项目，我会复用这套方法。
先做真实项目，再谈展示
不要一开始就做复杂个人官网
真实项目是内容和作品的来源
基础设施先打稳。
服务器、域名、安全、HTTPS、部署方式，基础打得好，项目运行的更久远
每个技术选择都记录理由
不要只记录命令，要记录为什么这么选，为什么放弃另一个方案。这些内容以后会变成决策型文章。
踩坑要及时写下来。备案问题、服务器扫描、数据库初始化、对象存储访问，当时很烦，写下来就是经验。
文章和项目要互相连接。
项目证明你做过，文章证明你想过，官网负责把它们组织起来。
三者连接起来，相辅相成，才会形成个人品牌基础设施。
它开始变成一个程序员自己的长期技术阵地。
下一篇，也就是这个系列的收官篇，我会继续写：做完个人作品站后，我对程序员个人品牌有了新的理解。
整个技术链路已经复盘完了，最后一篇我想回到程序员本身：为什么做完这一切以后，我反而觉得个人品牌不是包装，而是长期技术阵地的可见化。
本文由 楸木 原创，转载请注明出处。
这篇文章暂未开放评论。