分类
这是「把自己部署到互联网上」系列的第 32 篇。
上一篇，把个人博客通过 Docker 部署起来了：
项目目录有了，代码拉下来了
.env 配好了
Nginx 能转发请求到这一步，博客已经算基本部署成功。
但接着做下来我发现：容器跑起来，不等于博客真的可用，这篇文章主要记录下使用过程中踩到坑的问题，供大家参考下，避免再次踩坑。
查看容器日志，日志里可能会出现 connection refused、ac...
这是「把自己部署到互联网上」系列的第 33 篇。
从第 26 篇到第 32 篇，我把个人博客上线前很关键的一段走完了。
这一段主要解决三个问题：
可信访问这条线包括 HTTPS、SSL 证书、通配符证书和 acme.sh
资源承载这条线包括对象存储、桶策略、JSON 配置和域名访问控制
博客运行这条线包括 Docker 部署、数据库连接、迁移和管理员初始化
写到这里，我的博客开始具备上线条件了。注意，是具备上线条件，后续还要持续完善。
具备上线条件，意味着核心链路已经打通：能访问，能通过 HTTPS 访问，能运行，能存数据，...
这是「把自己部署到互联网上」系列的第 34 篇。
上一篇复盘了从 HTTPS 到对象存储，再到 Docker 部署和数据库初始化。博客具备上线条件后，很快会遇到一个实际维护问题：我想用 Navicat 看一下 Docker 里的数据库，应该怎么连？
这个需求很常见。比如确认表是否创建成功，检查迁移有没有执行，看管理员账号是否初始化，排查某条数据为什么没写进去，导出部分数据，或者临时执行一条 SQL。Navicat、DataGrip、DBeaver 这类工具确实方便。
但前提必须明确：不要为了让数据库工具连上，就直接把数据库端口暴露到公网。
先看 Docker 里...
这是「把自己部署到互联网上」系列的第 35 篇。
上一篇写了 Navicat 如何连接 Docker 里的数据库。
那是博客上线后的维护问题：数据库不能直接暴露公网，但我又需要安全、方便地查看和排查数据。
到这里，博客已经不只是“部署起来”，而是进入上线后的真实使用阶段。
部署前，我主要关心容器能不能启动，Nginx 能不能代理，HTTPS 能不能访问，数据库能不能连接，管理员能不能创建。
真正上线后，问题变得更加具体：
HTTPS 下出现混合内容这是「把自己部署到互联网上」系列的第 36 篇。
从第 31 篇开始，我进入了个人博客真正部署和上线的阶段：用 Docker 部署博客，处理数据库、迁移和管理员初始化，复盘 HTTPS 到对象存储，解决 Navicat 连接 Docker 数据库，又处理了防爬、静态资源和发文问题。
到这里，个人博客这一段可以做一次完整复盘。真正做完后，我确定一件事：博客上线，不是一个单点成功，而是一整条链路跑通。
服务器、Docker、数据库、Nginx、HTTPS、对象存储、后台、发文流程，任何一环没处理好，都会影响最终体验。
看到 docker...
这是「把自己部署到互联网上」系列的第 37 篇。
前面很长一段，我终于把博客从想法推进到了上线：服务器、域名、备案、安全边界、Docker、全局 Nginx、HTTPS、对象存储、数据库迁移、管理员初始化、静态资源和发文流程，都踩过一轮坑。
到这里，按理说可以松一口气。博客(楸木笔记)终于上线了，开心。
但真正打开发布了几篇文章之后，我又有了一个新判断：博客有了，但它还不等于个人品牌，简单说，单一个博客无法支撑起个人品牌。
这个想法有点意思了。因为我前面一直说，博客是程序员个人品牌的基础设施。
当第一次通过自己的域名打开博客页面时，很有成就...
这是「把自己部署到互联网上」系列的第 38 篇。
上一篇我写到，个人博客上线之后，我发现它还不是个人品牌。
博客解决的是内容沉淀问题，适合放技术文章、部署日志、项目复盘、踩坑记录和长期专题。
但一个第一次访问我的人，还需要更快知道：我是谁，我在做什么，写过哪些代表内容，做过哪些项目，为什么值得继续关注。
所以接下来，我要把个人博客延伸成个人品牌入口。
更具体地说，就是做一个个人官网或作品站。
新的问题也随之出现：个人官网框架怎么选？
上面那个问题看起来像技术选型，不能为了高级而高级，只比较谁更火、谁性能更强、谁生态更大。
从我个人来看，更重要的是：哪个框架更...
这是「把自己部署到互联网上」系列的第 39 篇。
上一篇我写了个人官网框架怎么选，先说了几个标准：
这一篇做一下具体对比：Astro、Next.js、Nuxt。
先说结论：这三个框架都能做个人官网和作品站，但适用的场景不一样。
如果脱离场景，很容易变成“谁更强、谁更火、谁生态更大”的争论。
我的需求很明确：如果我要做一个程序员个人官网和作品站，用来连接博客、公众号、GitHub、代表文章和项目展示，哪个更合适？
我的官网不是复杂 Web ...
上一篇，我把 Astro、Next.js、Nuxt 放在一起做了对比。
那篇更偏横向分析：三个框架都能做个人官网，但适合的场景不一样。
真正落到自己的项目上，问题就变成了另一个：我的个人作品站到底需要什么？
我的规划是：第一版选择 Astro。
这个选择不是因为 Astro 一定比 Next.js、Nuxt 更强，也不是因为它更流行。
更直接的原因是，我现在要做的不是一个复杂官网系统，而是个人博客上线后的轻量入口。
这一阶段真正重要的是博客：服务器、域名、备案、安全、Docker、Nginx、HTTPS、对象存储，这些工作都是为了把个人博客从 0 到 1 跑起来。
作品站不是替...
上一篇，我写了为什么个人作品站最终选择 Astro。
框架确定以后，真正难的问题才出现：个人官网首页到底该写什么？
页面可以搭，组件可以写，甚至用 AI 很快就能生成一个看起来不错的首页。
但首页上的概要内容，不能只靠模板。
你是谁，在做什么，希望别人第一眼记住什么，访问者下一步应该去哪里，这些问题必须自己想清楚。
很多程序员有个人网站，但别人看完还是不知道他是谁。
页面可能很漂亮，技术栈也很多，项目卡片不少，但访问者只留下一个模糊印象：这个人好像是程序员。
对个人品牌来说，这还不够。
我这次做个人官网，边界很明确。它不是一个很重的官网系统，不替代博客，也不是为了包装一个很大的个人品牌项...