前言
你好，我是洛尘。
这是这个 Hugo 博客真正意义上的第一篇文章。它不是某个复杂系统的部署教程，也不是一次故障复盘，而是一个简单的开场：我想给自己留一个长期记录技术折腾、系统建设和个人思考的地方。
过去我做过不少零散的事情：搭服务器、维护自建服务、折腾 Kubernetes、配置 VPN、写自动化脚本、部署各种工具，也经常在不同机器之间迁移环境。很多问题当时解决了，但如果没有记录，过一段时间再回头看，细节就会变得模糊。
所以这个博客的目的很明确：把折腾过的东西沉淀下来。
为什么要自己搭博客
选择 Hugo 这类静态博客，主要是因为它足够简单、稳定，也很适合长期维护。
相比把内容写在某个平台上，自建博客有几个明显好处：
- 内容归自己管：Markdown 文件在自己的 Git 仓库里，迁移和备份都方便。
- 部署链路简单：Hugo 构建成静态文件后，用 Caddy 直接托管即可。
- 性能和稳定性好：静态页面没有数据库依赖，也不需要复杂运行时。
- 适合技术记录：命令、配置、拓扑、踩坑过程都能完整保存。
博客本身也是我的一部分基础设施：源码进 Git，静态文件部署到服务器，访问入口由 Caddy 提供。它不只是一个页面，更像是我个人知识库对外可见的一层。
我会写些什么
这个博客后续大概率会围绕这些方向展开：
| 方向 | 内容 |
|---|---|
| Linux 与服务器运维 | 系统配置、服务部署、故障处理、性能排查 |
| Kubernetes / k3s | 集群搭建、应用部署、网络与存储、日常维护 |
| 自托管服务 | Gitea、Hugo、监控、网关、反向代理等 |
| 网络与 VPN | Tailscale、内网访问、跨机器互联、安全访问 |
| 开发环境 | Zsh、终端工具、编辑器、dotfiles、自动化脚本 |
| 折腾记录 | 一些不一定标准但真实有效的实践经验 |
我不打算把文章写成“完美教程”。更想保留的是实际操作中的上下文：为什么这么做、踩了什么坑、最后怎么验证成功。
因为真实环境里的问题往往不是“复制一条命令”就能解决的。很多时候，真正有价值的是排查路径和取舍过程。
我的记录原则
为了让这些文章以后还能看懂，我希望尽量遵循几个原则。
1. 写清楚背景
同样一个命令，在不同场景下意义可能完全不同。比如是单机部署，还是集群部署；是公网访问，还是只在内网访问；是临时测试，还是长期运行。
所以文章开头尽量交代清楚：我在什么环境下、为了解决什么问题、用了什么方案。
2. 不只贴命令，也解释原因
命令本身很容易复制，但参数背后的原因更重要。尤其是一些服务端配置，如果只记录“怎么写”，以后再看可能已经忘了为什么当时要这么写。
我希望每篇技术文章至少回答三个问题：
- 这个配置解决什么问题？
- 为什么选择这种方式？
- 怎么确认它真的生效？
3. 注意隐私和安全
博客会公开访问，所以真实公网 IP、密钥、Token、内部敏感信息都不会直接出现在文章里。需要示例时会使用 x.x.x.x、tskey-auth-xxxxx 之类的占位符。
技术记录应该可复现，但不应该把自己的基础设施暴露出去。
4. 保留踩坑过程
很多文章只写最终答案，但我觉得踩坑过程同样重要。
比如服务为什么没启动、配置为什么没生效、构建为什么没有生成页面、网络为什么连不上。这些过程可能看起来琐碎，但往往是以后排查问题最有用的部分。
博客也是一个长期项目
我对这个博客的期待不是短时间内写很多文章，而是长期慢慢积累。
每次解决一个问题，如果它以后还有可能再次遇到，就值得记录下来；每次搭好一个服务，如果部署步骤有复用价值，也值得整理成文；每次踩了一个坑，如果它能帮未来的自己少浪费一点时间，就不算白写。
技术折腾最怕的是“当时都会，过后全忘”。写博客就是给自己留一条回路：当经验变成文字，它才真正沉淀下来。
结语
这篇文章就作为一个开始。
后面我会陆续记录自己的服务器、集群、自托管服务、开发环境和各种折腾过程。内容可能不会总是很正式，但会尽量真实、可验证、可复用。
如果说这个博客有什么目标，那就是：把每一次折腾变成下一次更快解决问题的经验。