From ce2986fa93f57873e1fa4aaa1ad9d51a2a2f5ba9 Mon Sep 17 00:00:00 2001
From: luochen570 <1160510664@qq.com>
Date: Thu, 28 May 2026 22:41:47 +0800
Subject: [PATCH] publish first blog post

---
 content/posts/my-first-post.md | 96 +++++++++++++++++++++++++++++++++-
 1 file changed, 94 insertions(+), 2 deletions(-)

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