0
0
0

从零开始用Django搭个网站，大专生也能搞后端！

小而美开发者
2026-01-03 11:52
阅读 509

去年秋天我刚入职上海一家做SaaS工具的小公司，职位是前端开发。说来惭愧，虽然岗位写的是“前端”，但因为团队只有5个人，leader看我简历上写着“会Python”（其实是自学了一点基础语法），上周五晚上快下班时直接甩给我一个需求：“下周一上线一个内部管理后台，用Django搭，你行的。”

我当时真的想砸键盘——不是因为技术多难，而是deadline太离谱！不过转念一想，这不正是我补全后端技能的好机会吗？毕竟在B站刷了那么多教程，总不能一直只写Javascript吧。

于是，那个周末我戴着AirPods，一边听《Blinding Lights》一边在租的小屋里敲代码，终于把第一个Django项目跑起来了。今天就带大家复盘一下这个过程，希望能帮到和我一样非科班出身的朋友。

为啥选Django？真香警告！

说实话，一开始我想用Flask，毕竟轻量、自由。但考虑到这是个要上线的项目，而且可能涉及用户权限、数据库迁移、Admin后台这些功能，Django“自带电池”的特性简直救我狗命。

“Don’t repeat yourself” —— Django官方哲学，我深表赞同。

比如它内置的Admin界面，几行配置就能让你拥有一个功能完整的后台管理系统，连登录认证都不用自己写。对于我这种时间紧、任务重、经验少的应届生来说，简直是天降神兵。

环境搭建：别在第一步就翻车

首先确保你装了Python 3.8+（我用的是3.10）。然后创建虚拟环境——这一步千万别省，不然以后pip install乱成一锅粥，debug到凌晨三点都找不到问题。

# 创建项目目录
mkdir mysite && cd mysite

# 创建虚拟环境（Windows用户用 python -m venv venv）
python3 -m venv .venv

# 激活（Linux/macOS）
source .venv/bin/activate
# Windows: .venv\Scripts\activate

# 安装Django
pip install django

激活虚拟环境后，用django-admin startproject mysite .（注意最后有个点！）初始化项目。很多人这里漏掉点，结果生成了两层目录，后面路径配置全错。

项目结构大概是这样：

mysite/
├── manage.py
├── mysite/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py

这时候运行python manage.py runserver，浏览器打开http://127.0.0.1:8000，看到那个火箭图标——恭喜，你已经迈出了第一步！

创建App：模块化才是正道

Django推崇“App”概念，一个项目可以包含多个App。比如我们这个内部后台，我拆成了两个App：accounts（用户管理）和 dashboard（数据展示）。

python manage.py startapp accounts
python manage.py startapp dashboard

然后在mysite/settings.py里注册它们：

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    # ... 其他默认项
    'accounts',      # ← 加在这里
    'dashboard',     # ← 还有这里
]

踩坑提醒：我第一次忘了注册，结果模板渲染时报错TemplateDoesNotExist，查了半小时才发现是App没加进去。血泪教训！

模型设计：数据库不是随便建的

我们后台需要记录用户提交的工单（ticket），所以先在accounts/models.py里定义模型：

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

class Ticket(models.Model):
    STATUS_CHOICES = [
        ('pending', '待处理'),
        ('processing', '处理中'),
        ('resolved', '已解决'),
    ]
    
    title = models.CharField(max_length=200, verbose_name="标题")
    description = models.TextField(verbose_name="描述")
    status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='pending')
    created_by = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name="提交人")
    created_at = models.DateTimeField(auto_now_add=True)
    
    class Meta:
        verbose_name = "工单"
        verbose_name_plural = "工单列表"

这里有几个细节：

  • 用ForeignKey关联Django自带的User模型，避免重复造轮子；
  • on_delete=models.CASCADE表示用户删除时，其工单也一并删掉（业务允许的话）；
  • verbose_name是为了让Admin后台显示中文，提升可读性。

写完模型别忘了生成并执行迁移：

python manage.py makemigrations
python manage.py migrate

运维经验：在生产环境，migration文件一定要纳入版本控制！我们有一次线上部署忘了同步migration，数据库结构对不上，整个服务挂了半小时——产品经理差点把我祭天。

视图与路由：前后端怎么“说话”

Django的视图负责处理请求并返回响应。为了和前端交互，我决定用Javascript通过AJAX请求数据，所以后端要提供JSON接口。

在dashboard/views.py里写个简单API：

from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt
import json

@csrf_exempt  # 仅用于演示！生产环境务必处理CSRF
def get_tickets(request):
    if request.method == 'GET':
        tickets = Ticket.objects.all().values('id', 'title', 'status', 'created_at')
        return JsonResponse(list(tickets), safe=False)
    return JsonResponse({'error': 'Method not allowed'}, status=405)

然后在dashboard/urls.py配置路由：

from django.urls import path
from . import views

urlpatterns = [
    path('api/tickets/', views.get_tickets, name='get_tickets'),
]

别忘了在主urls.py里include这个子路由：

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('dashboard.urls')),  # ← 关键！
]

这时候前端就可以用fetch调用了：

// 前端JS代码（我写的）
fetch('/api/tickets/')
  .then(res => res.json())
  .then(data => {
    console.log('工单数据:', data);
    // 渲染到页面...
  });

吐槽一句：虽然我是前端，但写后端接口时还是被CSRF搞懵了好久。后来才知道，如果纯API服务，可以用Django REST framework，或者关闭CSRF（仅限可信内网！）。

Admin后台：老板看了直呼专业

Django最让我惊艳的就是Admin。只需在accounts/admin.py注册模型：

from django.contrib import admin
from .models import Ticket

@admin.register(Ticket)
class TicketAdmin(admin.ModelAdmin):
    list_display = ('title', 'status', 'created_by', 'created_at')
    list_filter = ('status', 'created_at')
    search_fields = ('title', 'description')

再创建超级用户：

python manage.py createsuperuser

输入用户名密码后，访问/admin，登录——boom！一个功能齐全的后台管理系统就有了。支持搜索、筛选、编辑、删除，连日期范围选择都有。

我们产品经理看到后惊呆了：“这真的是你周末两天做的？” 我只能苦笑：“Django牛逼，不关我事。”

部署上线：从本地到生产

本地跑通只是开始。公司用的是阿里云ECS + Nginx + Gunicorn。

关键步骤：

  1. 安装Gunicorn：pip install gunicorn
  2. 收集静态文件：python manage.py collectstatic
  3. 配置Nginx反向代理到Gunicorn
  4. 用systemd托管Gunicorn进程（避免ssh断开就挂）

gunicorn.conf.py示例：

bind = "127.0.0.1:8000"
workers = 3
worker_class = "sync"
timeout = 30
keepalive = 2
max_requests = 1000
max_requests_jitter = 100

性能提示：我们初期没配max_requests，结果内存泄漏，每天半夜服务崩一次。后来加上这个参数让worker定期重启，问题解决。

总结：非科班也能玩转全栈

回过头看，Django确实降低了后端入门门槛。作为一个大专毕业、靠自学找到工作的前端，这次经历让我意识到：技术栈的边界没那么重要，解决问题的能力才是核心。

虽然过程中踩了不少坑——比如时区设置没改导致数据库时间差8小时，或者DEBUG=True忘关导致敏感信息泄露——但每一次debug都是成长。

现在这个内部后台已经稳定运行三个月，还被其他部门借去用。下周我打算给它加上WebSocket实时通知，顺便研究下Django Channels。

如果你也像我一样，学历普通、经验不足，别怕。Just code it. 把音乐打开，键盘敲起来，下一个上线项目的，就是你。

P.S. 谁能告诉我，为什么每次写后端都要和数据库较劲？😭

标签:项目Javascript后端

评论 0

最热最新
暂无评论

为你推荐

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

相关推荐

暂无相关推荐

精选内容

暂无精选内容