Reading
·3 分钟读完

这个小站是怎么跑起来的：一个 Python 文件 + Nginx

#技术#Python#Nginx

经常被问"你这个站用的什么框架"。

答案是：没有框架。

结构

整个站就这几样东西：

blog/
├── app.py          核心：markdown 解析 + 文章索引
├── render.py       渲染：把数据拼成 HTML / RSS
├── server.py       HTTP 服务（标准库 http.server）
├── templates/      HTML 模板
├── static/         CSS / JS / 图标
├── posts/          ← 文章都在这，一个 .md 一个文件
└── pages/about.md  关于页面

没有 package.json，没有 node_modules，没有 pip install。

为什么不用框架

不是说框架不好。是我这个站的需求太简单了：

  • 页面不超过 10 个模板
  • 没有用户系统
  • 没有评论（想聊就直接发邮件）
  • 并发量小到可以忽略

为了这点需求引入一整套工具链，我要付出的是：版本升级、依赖冲突、构建缓存失效……这些成本远大于收益。

能用标准库解决的问题，就别引入依赖。

文章是怎么变成页面的

每篇文章头部有一段 front matter：

---
title: 标题
date: 2026-09-28
tags: [技术, Python]
emoji: 💻
summary: 一句话摘要
---

然后下面就是正文。

服务器启动时会扫一遍 posts/ 目录，解析、渲染、按日期排序，全部放进内存。之后每次请求只是从内存里读字符串。

如果文件被改动（mtime 变了），下一次请求会自动重建索引——所以改完存盘，刷新页面就能看到，不用重启服务。

一个值得说的取舍

我在 render.py 里自己实现了一个 markdown 子集解析器，大概 100 行。

用现成的解析库当然更完整，但那样就得装依赖；而对一个博客来说，我需要的东西无非是：标题、列表、代码块、引用、链接、图片、粗体斜体。

为了一个博客引入一个通用 markdown 解析器，就像为了钉一颗钉子买一台机床。

部署

Nginx 在前面做反向代理，Python 进程在 127.0.0.1:8010 监听，systemd 负责守护。

location / {
    proxy_pass http://127.0.0.1:8010;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

就这样。整套东西常驻内存不到 40MB。

如果你也在纠结要不要给自己的博客上框架，我的建议是：先写出来，再考虑优化。

← 回到首页