搭一个个人网站，说难不难，说简单也没那么简单。难的不是写几行 HTML，而是想清楚：这东西要跑在哪里，怎么更新，出了问题怎么办。
我折腾了一段时间，最后定下来的方案是：Hugo 生成静态页面，托管在共享主机上，源文件放在家里的 NAS 上，通过 GitHub Actions 自动构建部署。听起来有点绕，但每一层都有它的理由。
为什么选静态网站
最开始我也考虑过 WordPress 之类的动态方案。但转念一想，一个个人网站需要数据库吗？需要服务端渲染吗？内容不多，更新也不频繁，纯静态 HTML 完全够用，而且更快、更安全、更省钱。Hugo 是目前构建速度最快的静态网站生成器之一，整站构建只需要不到一秒。
为什么用 NAS 做源文件存储
源文件放在 NAS 上，有几个好处：本地网络访问速度快，实时预览毫无延迟；数据在自己手里，不依赖任何云服务；NAS 上跑着 Hugo 的 Docker 容器，改完文件刷新浏览器就能看到效果，跟本地开发体验一样。
为什么引入 GitHub
最开始我是手动把构建好的文件上传到主机，每次改动都要打开 FTP 工具，选文件，上传，确认。麻烦不说，还容易漏文件。
后来把源文件纳入 Git 管理，推送到 GitHub 私有仓库，再配置 GitHub Actions：每次提交自动触发构建，构建完通过 FTP 上传到主机。现在的流程是：改文件 → NAS 预览确认 → git commit → 30 秒后网站自动更新。手动操作降到了最低。
Git 还带来了一个额外收益：完整的改动历史。哪次改了什么，改坏了能回退，不用靠记忆。
这套方案的代价
当然不是没有成本。NAS 要常开，主机要续费，GitHub 需要维护。遇到问题要自己排查，比如 Cloudflare 的某个优化功能曾经悄悄把我的 JavaScript 延迟执行，排查了好一会儿才找到原因。
但整体来说，这套架构对我来说是合适的——它足够轻，足够可控，每一层都能理解，出了问题知道去哪里找。
一个人的网站，不需要很复杂。但值得认真对待。
Building a personal website isn’t exactly hard, but it’s not trivial either. The challenge isn’t writing a few lines of HTML — it’s figuring out where the thing actually lives, how you update it, and what happens when something breaks.
After some experimentation, I settled on this stack: Hugo for static site generation, hosted on a shared server, with source files on a home NAS, deployed automatically via GitHub Actions. It sounds like a lot of moving parts, but each layer earns its place.
Why Static
I considered WordPress and similar dynamic setups at first. But honestly — does a personal site need a database? Server-side rendering? The content is modest, updates are infrequent, and plain static HTML is faster, more secure, and cheaper to run. Hugo is one of the fastest static site generators around; the entire site builds in under a second.
Why NAS for Source Files
Keeping source files on a home NAS made sense for a few reasons: local network access means instant preview with zero latency; the data stays in my hands without depending on any cloud service; and a Hugo Docker container running on the NAS means editing a file and refreshing the browser gives immediate feedback — the same experience as local development.
Why GitHub
Early on, I was manually uploading built files to the host via FTP. Every change meant opening an FTP client, selecting files, uploading, verifying. Tedious, and easy to miss something.
Eventually I moved source files into Git, pushed to a private GitHub repository, and set up GitHub Actions: every commit triggers an automatic build, and the output gets uploaded to the host via FTP. The workflow is now: edit file → verify on NAS preview → git commit → site updates in about 30 seconds. Manual steps reduced to a minimum.
Git also adds something valuable: a complete change history. Every modification is recorded. If something breaks, rolling back a file takes one command.
The Trade-offs
It’s not without overhead. The NAS needs to stay on, the hosting needs renewing, GitHub needs occasional attention. Troubleshooting falls entirely on me — at one point, a Cloudflare optimization feature was silently delaying my JavaScript execution, and it took a while to track down.
But overall, this architecture fits. It’s light, it’s understandable end-to-end, and when something goes wrong, I know where to look.
A personal site doesn’t need to be complicated. But it’s worth building with some care.