Files
hugo-blog/content/posts/my-first-post.md
2026-05-28 22:41:47 +08:00

98 lines
4.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
+++
date = '2026-05-16T23:40:27+08:00'
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. 保留踩坑过程
很多文章只写最终答案,但我觉得踩坑过程同样重要。
比如服务为什么没启动、配置为什么没生效、构建为什么没有生成页面、网络为什么连不上。这些过程可能看起来琐碎,但往往是以后排查问题最有用的部分。
## 博客也是一个长期项目
我对这个博客的期待不是短时间内写很多文章,而是长期慢慢积累。
每次解决一个问题,如果它以后还有可能再次遇到,就值得记录下来;每次搭好一个服务,如果部署步骤有复用价值,也值得整理成文;每次踩了一个坑,如果它能帮未来的自己少浪费一点时间,就不算白写。
技术折腾最怕的是“当时都会,过后全忘”。写博客就是给自己留一条回路:当经验变成文字,它才真正沉淀下来。
## 结语
这篇文章就作为一个开始。
后面我会陆续记录自己的服务器、集群、自托管服务、开发环境和各种折腾过程。内容可能不会总是很正式,但会尽量真实、可验证、可复用。
如果说这个博客有什么目标,那就是:**把每一次折腾变成下一次更快解决问题的经验**。