0
0
0

从大厂裸辞后，我用Django搭了个小站找回写代码的快乐

技术清醒派
2026-03-28 06:37
阅读 334

上周五晚上十一点半，我坐在阳台上，一边听着Lo-fi beats，一边盯着终端里 django-admin startproject mysite 的输出。窗外城市灯火通明，而我已经整整两个月没碰过公司那套复杂的Springboot微服务了。

说来有点好笑。在前东家干了快两年，每天不是在K8s集群里排查Pod CrashLoopBackOff，就是在CI/CD流水线里追着测试环境的诡异Bug跑。产品经理动不动就来一句“这个需求很简单，就是加个字段”，运维兄弟天天在群里@我说“你这服务内存又爆了”。最离谱的是去年双11前夜，因为一个Go写的中间件和Java服务的序列化不兼容，整个团队熬到凌晨四点，我当时真的想砸电脑。

现在辞职在家休息，反而开始怀念那种纯粹写代码的感觉。于是决定重新拾起Python，用Django搭个自己的小网站。为啥选Django？别问，问就是被Springboot折磨怕了——配置文件多到能写本书，启动时间比我泡面还慢。相比之下，Django开箱即用，文档友好，对新手极其温柔。

为什么不用Springboot、Go或者文心一言？

我知道肯定有人要问：你不是搞云原生的吗？为啥不用Go写个高性能服务？或者直接上Springboot？

先说Go吧。Go确实快，内存占用低，在我们组的边缘计算场景里表现优异。但问题是，Go的Web框架生态相对零散，gin、echo、fiber各有各的玩法，不像Django这种“全栈式”框架，admin后台、ORM、用户认证全都给你打包好了。我现在只想快速验证想法，不是去造轮子。

至于Springboot……说实话，我对Java生态已经PTSD了。还记得有一次为了调试一个JPA的懒加载问题，我在IntelliJ里打了二十几个断点，最后发现是事务边界没配对。而且Springboot项目启动动辄30秒+，改一行代码就得等半天，开发体验实在不敢恭维。

还有人提文心一言？哈哈，那玩意儿确实能帮你生成一些基础代码，但生成的Django代码往往缺少最佳实践，比如没做CSRF防护、数据库查询没优化，直接上线分分钟被拖垮。AI工具可以辅助，但核心逻辑还得自己把控。

所以结论很明确：小项目、快速迭代、个人玩票，Django依然是Python阵营里最稳的选择。

环境搭建：比K8s简单一万倍

在公司里部署一个服务，光是YAML文件就得写几十行，还要配Service、Ingress、ConfigMap、Secret……而在本地搭Django？三行命令搞定：

# 创建虚拟环境（强烈建议！别污染全局）
python -m venv django_env
source django_env/bin/activate  # Linux/Mac
# django_env\Scripts\activate   # Windows

# 安装Django
pip install Django

# 初始化项目
django-admin startproject blog_site
cd blog_site
python manage.py runserver

看到终端输出 Starting development server at http://127.0.0.1:8000/ 的那一刻，我差点感动哭了——这速度，比我们组那个动不动就OOM的Springboot服务快太多了！

小贴士：如果你之前用过Node.js的Express或者Ruby on Rails，会发现Django的“约定优于配置”哲学非常类似。但对于从Java转过来的同学，可能需要适应一下“少即是多”的思路。

写个博客系统：从Model到Template

既然要搭网站，那就做个最经典的博客系统吧。Django的MTV（Model-Template-View）架构清晰得让人安心。

第一步：定义数据模型

在 blog/models.py 里定义文章模型：

from django.db import models
from django.contrib.auth.models import User

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    author = models.ForeignKey(User, on_delete=models.CASCADE)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.title

对比一下我们在公司用的JPA实体类：

@Entity
@Table(name = "posts")
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "title", length = 200)
    private String title;
    
    @Lob
    @Column(name = "content")
    private String content;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "author_id")
    private User author;
    
    // ...一堆getter/setter和toString
}

是不是瞬间觉得Django清爽多了？而且Django ORM自动生成的SQL通常很合理，不像Hibernate有时候会搞出N+1查询这种坑。

第二步：注册到Admin后台

Django最让我惊艳的功能之一就是自带的Admin后台。只需两步：

  1. 在 blog/admin.py 中注册模型：
from django.contrib import admin
from .models import Post

admin.site.register(Post)
  1. 创建超级用户：
python manage.py createsuperuser

然后访问 http://127.0.0.1:8000/admin，输入刚才创建的账号密码，就能看到一个功能完整的后台管理系统！增删改查、搜索、过滤全都有，连富文本编辑器都能轻松集成。

这让我想起在公司时，前端同学为了做一个类似的管理后台，前后端联调了整整两周。而Django，十分钟搞定。

第三步：写视图和模板

视图函数写起来也极其直白：

# blog/views.py
from django.shortcuts import render
from .models import Post

def post_list(request):
    posts = Post.objects.all().order_by('-created_at')
    return render(request, 'blog/post_list.html', {'posts': posts})

对应的模板 templates/blog/post_list.html：

<!DOCTYPE html>
<html>
<head>
    <title>我的博客</title>
</head>
<body>
    <h1>所有文章</h1>
    {% for post in posts %}
        <div>
            <h2>{{ post.title }}</h2>
            <p>作者: {{ post.author.username }}</p>
            <p>{{ post.content|truncatewords:50 }}</p>
        </div>
    {% endfor %}
</body>
</html>

整个流程行云流水，没有任何魔法。不像某些框架，为了“简洁”隐藏了太多细节，出了问题根本不知道从哪debug。

性能与安全：别以为小项目就不用考虑

虽然这是个个人小站，但作为前大厂SRE，我还是忍不住做了些优化。

数据库查询优化

注意到上面的 post_list 视图了吗？如果每篇文章都要显示作者名，Django默认会为每篇文章单独查一次User表，这就是典型的N+1问题。

解决方案很简单，用 select_related：

posts = Post.objects.select_related('author').all().order_by('-created_at')

这样Django会用一条JOIN语句搞定所有数据，性能提升明显。

静态文件处理

开发时Django自动serve静态文件很方便，但生产环境必须用Nginx。我把配置写成了Dockerfile的一部分：

FROM python:3.9
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
RUN python manage.py collectstatic --noinput

FROM nginx:alpine
COPY --from=0 /app/static /var/www/static
COPY nginx.conf /etc/nginx/nginx.conf

配合简单的nginx.conf，静态文件响应时间从200ms降到20ms。

安全加固

Django默认开启了CSRF保护、XSS转义等安全机制，但有几个地方还是要手动检查：

  • 设置 DEBUG = False（生产环境绝对不能开Debug！）
  • 配置 ALLOWED_HOSTS
  • 使用 SECRET_KEY 环境变量
  • 启用HTTPS（用Let's Encrypt免费证书）

这些在公司的安全审计清单里都是必选项，没想到在个人项目里也用上了，职业病啊……

和GitHub联动：代码即服务

写完代码当然要push到GitHub。我甚至还加了个简单的CI：

# .github/workflows/test.yml
name: Test
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.9'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Run tests
        run: python manage.py test

虽然只是跑几个单元测试，但看到绿色的✅还是很有成就感。这让我想起在公司时，每次PR都要过十几道CI关卡，测试覆盖率低于80%直接被拒。现在自己玩，反而更注重代码质量了——毕竟没人逼你，但你知道什么是对的。

对比主流Web框架（非正式版）

为了帮大家选型，我简单对比了几个主流选择：

框架 学习曲线 开发速度 生态成熟度 适合场景
Django 中等 ⚡️⚡️⚡️⚡️⚡️ ⚡️⚡️⚡️⚡️⚡️ 全栈应用、MVP、内容型网站
Springboot 陡峭 ⚡️⚡️ ⚡️⚡️⚡️⚡️⚡️ 企业级微服务、高并发后端
Go (Gin) 平缓 ⚡️⚡️⚡️ ⚡️⚡️⚡️ 高性能API、微服务、CLI工具
Node.js (Express) 平缓 ⚡️⚡️⚡️⚡️ ⚡️⚡️⚡️⚡️ 实时应用、前后端同构

可以看到，如果你要快速做出一个功能完整的网站，Django依然是最优解之一。特别是当你不想花时间折腾前端时，它的模板系统+Admin后台简直是神器。

写在最后：技术选择的本质是权衡

裸辞这两个月，我最大的感悟是：没有最好的技术，只有最适合场景的技术。

在大厂，我们追求高可用、高性能、可扩展，所以要用K8s、用Springboot、用Go。但在个人项目里，开发效率、学习成本、维护难度才是关键。Django恰好在这几方面做到了很好的平衡。

现在的我已经把博客部署到了云服务器上（没错，就是用我熟悉的K8s，不过只跑了一个Pod 😅）。每天写点技术笔记，偶尔看看访问日志，感觉比在工位上盯着Grafana面板幸福多了。

如果你也在考虑学Web开发，或者想做个自己的小项目，不妨试试Django。它可能不够“酷”，不够“前沿”，但它足够稳、足够快、足够让你找回写代码的初心。

对了，代码我已经开源到GitHub了，搜 django-beginner-blog 就能找到。欢迎Star，也欢迎提Issue吐槽——反正现在没人催我改需求了，我可以慢慢修 😄

作者：前大厂云原生工程师，现自由探索者。喜欢边听City Pop边写Python，梦想是做出一个不需要加班维护的系统。

标签:Springboot文心一言GoGitHub

评论 0

最热最新
暂无评论

为你推荐

暂无相关推荐
匿名用户Lv.1
0
影响力
0
文章
0
粉丝

相关推荐

暂无相关推荐

精选内容

暂无精选内容