Django入门教程：搭建你的第一个Python网站

上周五晚上十一点，我还在公司改一个线上活动的Bug。产品经理临时加了个需求：“能不能在H5页面里展示玩家最近七天的登录记录？”我一边在心里默念“冷静，冷静，不能骂人”，一边打开终端准备搭个简单的后台服务。考虑到时间紧、需求简单，用我们游戏后端常用的Java Spring Boot显然有点杀鸡用牛刀了——光是Maven依赖下载就得等五分钟，更别说写一堆DTO、Service、Controller三层架构。

就在这时，我想起了最近为了跳槽刷题时顺手学的Django。说来惭愧，作为网易做了三年服务端开发的老咸鱼，之前一直觉得“Python就是脚本语言，干不了大事”，直到被隔壁组用Django三天搭出一个运营后台狠狠打脸。这不，现在轮到我自己“真香”了。

为什么一个Java后端要学Django？

先自我介绍一下：我在网易某工作室做服务端开发三年，参与过两款MMO和一款休闲手游的上线。日常主力语言是Java（配合Netty做网络层），数据库主要是MySQL+Redis，中间件能写一黑板：Kafka、ZooKeeper、Apollo……但说真的，不是所有场景都需要这么重的架构。

去年双11期间，我们搞了个限时活动，需要一个独立的小站给运营同学填数据。当时组长拍板：“别用主服，单独搞个轻量级服务，两天内上线！”结果我吭哧吭哧用Spring Boot搭完，光是配置文件就写了快200行，而隔壁组用Django的兄弟，喝着咖啡就把活干完了——还自带Admin后台！

从那以后，我就开始偷偷研究Django。尤其最近在准备跳槽（嘘，别让领导知道），发现很多互联网公司对“全栈能力”越来越看重。光会Java后端？可能连简历关都过不了。于是我把《Django企业开发实战》这本书翻烂了（比《Java编程思想》薄多了，心理压力小不少），又扒了几个开源项目的源码，终于敢说自己“会用Django”了。

今天这篇文章，就是想带大家快速上手Django，用最短时间跑起一个能看的网站。全程避坑指南，全是血泪经验。

五分钟创建你的第一个Django项目

先装环境。别跟我提pip install django就完事——生产环境里，版本管理、虚拟环境这些细节才是魔鬼。

# 强烈建议用venv隔离环境！别污染全局Python
python3 -m venv mysite_env
source mysite_env/bin/activate  # Linux/Mac
# mysite_env\Scripts\activate   # Windows

pip install django==4.2.7  # 指定版本！别用最新版，容易踩坑
django-admin startproject mysite
cd mysite
python manage.py runserver

如果看到 Starting development server at http://127.0.0.1:8000/，恭喜你，已经跑起来了！别笑，我第一次跑的时候因为端口被占用卡了半小时，最后发现是Jupyter Notebook占着8000端口……社死现场。

目录结构解读（Java程序员视角）

Django的目录结构对Java开发者来说可能有点“散”，但其实很清晰：

mysite/
├── manage.py          # 类似Spring Boot的启动类，但功能更多
├── mysite/            # 项目配置目录（注意同名！）
│   ├── __init__.py
│   ├── settings.py    # 全局配置，相当于application.yml + 配置类
│   ├── urls.py        # 总路由，类似@RequestMapping根路径
│   └── wsgi.py        # 部署用，开发不用管
└── db.sqlite3         # 默认数据库文件（别用这个上生产！）

对比一下Spring Boot：

• settings.py ≈ application.yml + @Configuration 类
• urls.py ≈ @RestController 的根路径映射
• 没有显式的main()函数，启动逻辑封装在manage.py

创建第一个App：别被“App”这个词骗了

Django里的“App”不是指手机应用，而是功能模块。比如用户系统、博客、商品管理各自是一个App。

python manage.py startapp blog

生成的目录：

blog/
├── migrations/    # 数据库迁移文件（类似Flyway）
├── models.py      # 数据模型（≈ JPA Entity）
├── views.py       # 视图逻辑（≈ Controller）
├── admin.py       # 后台管理注册
└── apps.py        # App配置

这里有个坑：新建App后，必须在settings.py里注册，否则Django根本不认它！

# mysite/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    # ... 其他内置App
    'blog',  # ← 别忘了加这一行！
]

我第一次忘加这行，结果makemigrations死活不生成表，查了俩小时文档才发现……当时真的想砸键盘。

写个Hello World：从View到Template

1. 定义视图（views.py）

# blog/views.py
from django.http import HttpResponse

def hello(request):
    return HttpResponse("Hello, Django! 一个Java后端的眼泪")

2. 配置路由（urls.py）

先在blog目录下创建urls.py：

# blog/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('hello/', views.hello, name='hello'),
]

然后在项目总路由mysite/urls.py里包含它：

# mysite/urls.py
from django.contrib import admin
from django.urls import path, include  # ← 别漏了include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('blog/', include('blog.urls')),  # 所有blog路由以/blog/开头
]

访问 http://127.0.0.1:8000/blog/hello/，就能看到那行辛酸的Hello World了。

3. 用模板渲染HTML（告别字符串拼接！）

直接返回HTML字符串？太原始了！Django的模板系统比JSP优雅多了（别打我）。

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

def home(request):
    context = {'name': '老张', 'games': ['逆水寒', '永劫无间', '蛋仔派对']}
    return render(request, 'blog/home.html', context)

创建模板文件 blog/templates/blog/home.py：

<!-- blog/templates/blog/home.html -->
<h1>欢迎你，{{ name }}！</h1>
<p>你玩过的网易游戏：</p>
<ul>
{% for game in games %}
    <li>{{ game }}</li>
{% endfor %}
</ul>

注意目录结构：templates/blog/ 这个blog/子目录不能省！这是Django的命名空间机制，避免不同App的模板冲突。我第一次没建这个子目录，结果页面404，调试日志显示“TemplateDoesNotExist”，气得我直拍桌子。

数据库操作：Model + ORM

Django的ORM真心香，比MyBatis简洁，比Hibernate直观。定义模型就像写Java Bean，但不用写getter/setter。

# blog/models.py
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)
    
    def __str__(self):  # 相当于Java的toString()
        return self.title

然后生成并执行迁移：

python manage.py makemigrations
python manage.py migrate

这俩命令相当于：

• makemigrations → 生成SQL变更脚本（类似Liquibase changelog）
• migrate → 执行脚本更新数据库

生产环境忠告：
千万别用默认的SQLite！开发可以，但上线必须切MySQL/PostgreSQL。在settings.py里改几行就行：

# mysite/settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'my_blog_db',
        'USER': 'root',
        'PASSWORD': 'your_password',
        'HOST': 'localhost',
        'PORT': '3306',
    }
}

记得装MySQL驱动：pip install mysqlclient（别用PyMySQL，性能差一截）。

自带神器：Django Admin

最让我震惊的是Django Admin——不用写一行前端代码，自动生成CRUD后台！Java生态里要实现这效果，至少得搭个Vue+Element UI，再配个Spring Data REST……

注册模型到Admin：

# blog/admin.py
from django.contrib import admin
from .models import Article

admin.site.register(Article)

创建超级用户：

python manage.py createsuperuser

然后访问 http://127.0.0.1:8000/admin，输入账号密码，就能看到：

• 自动识别Article模型
• 支持增删改查
• 时间字段自动格式化
• 搜索、过滤、分页全都有

我当时就惊了：这玩意儿要是早点知道，去年做运营工具能省多少加班时间啊！运维同事来看了一眼，幽幽地说：“你们开发是不是又要抢我们运维的活了？”

开发心得：从Java视角看Django

作为一个常年和Java打交道的服务端，用Django最大的感受是：它把“约定优于配置”做到了极致。

维度	Java (Spring Boot)	Django
项目初始化	需要IDE + Spring Initializr	一条命令搞定
路由映射	注解(@RequestMapping)	URL配置文件
数据库ORM	JPA/Hibernate(MyBatis)	内置ORM，开箱即用
管理后台	需要额外集成(如EL-ADMIN)	自带Admin，注册即用
部署	打jar包 + java -jar	WSGI服务器(uWSGI/Gunicorn)

当然，Django也有短板：

• 异步支持弱：虽然Django 3.0+支持ASGI，但生态远不如Node.js或Go
• 微服务不友好：单体架构思维太重，拆微服务得自己折腾
• 性能天花板：高并发场景还是Java/Go更稳（我们游戏登录服QPS 5w+，绝对不敢用Python）

但！对于中小型项目、内部工具、原型验证，Django的开发效率简直降维打击。上周那个七天登录记录的需求，我用Django写了不到50行代码，包括数据库查询和JSON返回：

# views.py
from django.http import JsonResponse
from .models import LoginRecord

def recent_logins(request, user_id):
    records = LoginRecord.objects.filter(
        user_id=user_id
    ).order_by('-login_time')[:7]
    data = [{'date': r.login_time.strftime('%Y-%m-%d')} for r in records]
    return JsonResponse({'logins': data})

测试同学跑完用例，发来消息：“接口OK，比预期快多了”。那一刻，我觉得学Django真值了。

跳槽学习建议：别只盯着框架

最近刷LeetCode的同时，我也在反思：为什么大厂面试总问Django？其实他们不是要你精通Django，而是考察你快速解决问题的能力。

如果你和我一样是Java后端，我建议：

1. 先掌握核心概念：MTV模式（Model-Template-View）、ORM、Admin、中间件
2. 对比学习：用Django实现一个你熟悉的Java小项目（比如用户注册）
3. 深挖原理：读Django源码里django/core/handlers/base.py（请求处理流程）
4. 结合书籍：《Django企业开发实战》讲部署和安全很到位，《Two Scoops of Django》是最佳实践宝典

记住：工具只是手段，解决问题才是目的。就像我们游戏后端常说的：“别炫技，能扛住双11流量才是好架构”。

最后：关于综合能力

写这篇文章时，我刚收到一个面试邀约，岗位要求写着：“熟悉至少一种Web框架（Django/Flask/Spring Boot）”。你看，市场要的是综合能力，不是单一技术栈。

作为服务端开发者，我们既要能用Java扛住高并发，也要能用Django快速交付。技术没有高低贵贱，只有合不合适。下次产品经理再提“紧急需求”，我可能会笑着说：“给我两小时，Django安排！”

（完）

---

P.S. 文中提到的书籍我都放在公司书架上了，如果你也在网易，来找我要就行——不过得请我喝瑞幸，毕竟跳槽季，咖啡因续命嘛！