Django入门教程：搭建你的第一个Python网站（一个Vim党被逼转型的血泪史）

去年双11大促前一周，我们后端组突然接到需求：“用Django快速搭个内部运营后台，下周三上线。”
我当时正用 Vim 在写一个 Java 微服务的重构方案，听到这个消息差点把咖啡泼到键盘上。作为资深 Vim 党 + Java 技术栈出身的老兵，我对 Python 的印象还停留在“脚本语言、胶水工具”的阶段。结果领导一句“现在团队技术栈要综合化”，直接把我按在了 Django 的椅子上。

但没办法，deadline 就像产品经理的 KPI 一样，从不等人。于是，我这个用了快两年 GitHub Copilot 的付费用户（是的，Copilot 真香，尤其当你被迫切换语言时），硬着头皮开始了我的 Django 初体验。今天就来和大家技术分享一下这段“从 Java Spring Boot 跳坑到 Python Django”的奇幻旅程。

---

为什么是 Django？真不是我想用

先说背景：我们公司主站是 Java + Spring Cloud 架构，性能稳如老狗，但内部工具链一直很零碎。这次要做的是一个内容审核平台，需要快速迭代、支持 RBAC 权限、还要能对接现有 SSO。运维同事一听“又要部署新服务”，脸都绿了——毕竟他们上周刚处理完一个因为 YAML 缩进不对导致的线上事故。

而 Django 的优势就在这儿：自带 Admin 后台、ORM、认证系统、中间件机制，一套下来，连数据库迁移脚本都不用手写。对我们这种“既要快又要稳”的场景，简直是救命稻草。

吐槽一句：Java 写个 CRUD 接口，光 DTO、VO、BO、DAO 层就能建五个包，Django 三行代码搞定。虽然我爱 Java 的严谨，但有时候真想对 Spring Boot 说一句：“你太重了！”

---

搭建过程：从 pip install 到“卧槽这也能行？”

第一步：环境隔离，别污染你的系统 Python

作为一个被 pip 全局安装搞崩过三次环境的人，我强烈建议用 venv：

python3 -m venv django-env
source django-env/bin/activate
pip install django gunicorn psycopg2-binary

注意：生产环境别用 SQLite！我一开始图省事用了默认 DB，结果测试压测时并发一上来直接锁表。赶紧切到 PostgreSQL，顺便把 psycopg2-binary 装上。

第二步：创建项目 & App

django-admin startproject ops_platform .
python manage.py startapp content_audit

这里有个小细节：项目名（ops_platform）和 App 名（content_audit）要分开。很多新手会混在一起，后期扩展权限、中间件时会非常痛苦。

第三步：模型设计 —— 性能优化从 Schema 开始

因为我们是从 Java 过来的，习惯先画 ER 图。审核平台核心就三个实体：User、Content、AuditRecord。

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

class Content(models.Model):
    title = models.CharField(max_length=255)
    body = models.TextField()
    status = models.CharField(
        max_length=20,
        choices=[('pending', '待审核'), ('approved', '通过'), ('rejected', '拒绝')],
        default='pending'
    )
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        indexes = [
            models.Index(fields=['status']),  # 高频查询字段加索引！
            models.Index(fields=['created_at']),
        ]
        db_table = 'content_audit_content'  # 显式指定表名，方便 DBA 管理

重点来了：

• 别用 TextField 存 JSON！虽然 Django 有 JSONField，但早期版本兼容性差，我们直接用 CharField + 序列化更稳。
• 所有高频查询字段必须加数据库索引，否则上线后慢查询日志会让你哭。
• 时间字段用 auto_now_add 和 auto_now，避免手动赋值出错。

---

接口设计：RESTful 还是 Admin？

一开始我想用 DRF（Django REST Framework）搞一套标准 API，但时间不够。最后决定：内部工具直接用 Django Admin + 自定义 View。

# admin.py
from django.contrib import admin
from .models import Content

@admin.register(Content)
class ContentAdmin(admin.ModelAdmin):
    list_display = ('title', 'status', 'created_at')
    list_filter = ('status', 'created_at')
    search_fields = ('title', 'body')
    actions = ['approve_selected']

    def approve_selected(self, request, queryset):
        queryset.update(status='approved')
    approve_selected.short_description = "批量通过"

看到没？10 行代码实现带搜索、筛选、批量操作的后台。要是用 Java 写，前端 Vue + 后端 Controller + Service + Mapper，没两天搞不定。

当然，如果你要做对外 API，还是得上 DRF。但内部工具，Admin 就是王道。

---

性能优化：别让 Django 变成“慢 Django”

很多人吐槽 Django 性能差，其实是用法不对。我踩过几个大坑：

坑1：N+1 查询问题

默认情况下，Django ORM 不会自动关联查询。比如在 Admin 列表页显示 user.username，如果不优化，每条记录都会查一次 User 表。

解决方案：用 select_related 或 prefetch_related

# views.py 或 admin.py 中重写 get_queryset
def get_queryset(self, request):
    return super().get_queryset(request).select_related('user')

坑2：静态文件没配好，CSS 加载慢到怀疑人生

开发时用 runserver 没问题，但生产环境必须用 Nginx 托管静态文件。否则每次请求都走 Python 进程，CPU 直接拉满。

# nginx.conf 片段
location /static/ {
    alias /path/to/your/staticfiles/;
    expires 1y;
    add_header Cache-Control "public, immutable";
}

同时别忘了在 settings.py 里配置：

STATIC_ROOT = '/path/to/collected/static/'
STATIC_URL = '/static/'

然后执行 python manage.py collectstatic。

坑3：没开 Gunicorn 多进程

runserver 是单线程的，只能用于开发！生产环境必须用 Gunicorn + 多 Worker：

gunicorn --workers 4 --bind 0.0.0.0:8000 ops_platform.wsgi:application

Worker 数量建议设为 CPU 核数 * 2 + 1。我们线上 4 核机器配 9 个 Worker，QPS 轻松破千。

---

和 Java 技术栈对比：各有千秋

为了让大家更直观感受差异，我做了个简单对比：

维度	Java (Spring Boot)	Django
启动速度	慢（JVM 预热）	快（解释执行）
代码量	多（强类型、分层）	少（动态类型、约定优于配置）
性能上限	高（JIT 优化）	中（CPython GIL 限制）
开发效率	低（编译、依赖管理复杂）	高（热重载、内置功能多）
生态成熟度	极高（金融、电商广泛使用）	高（Web、数据科学领域强势）
运维复杂度	高（JAR、JVM 参数调优）	低（纯 Python，依赖少）

结论：

• 对外高并发系统 → 选 Java
• 内部工具、MVP、数据产品 → 选 Django

---

最后：Copilot 救我狗命

说实话，要不是 Copilot，我可能还在查 “Django 如何自定义 Admin Action” 的文档。它不仅能根据注释生成代码，还能自动补全 settings.py 配置、urls.py 路由，甚至帮我写出符合 PEP8 的 Python 代码（虽然我还是习惯驼峰命名，被同事笑死）。

---

结语

现在那个审核平台已经稳定运行半年，日均处理 5w+ 内容，响应时间 < 200ms。运维同学再也不用半夜被叫起来改缩进了（好吧，那是另一个故事）。

如果你也是 Java 出身，被逼学 Django，别慌。它的哲学很简单：Don't repeat yourself, and get things done。性能不是框架的问题，而是你怎么用的问题。

记住：技术没有银弹，只有合适的场景。综合化技术栈不是让你抛弃 Java，而是多一把趁手的刀。

好了，我要回去继续用 Vim 写我的 Java 重构了。下次再聊如何用 Django 做实时日志分析——那又是另一个通勤路上想出来的骚操作了。

（本文完，字数：2227）