Django入门教程：搭建你的第一个Python网站 —— 一个被创业公司“毕业”过的前端的踩坑手记
去年十月，我坐在北京昌平一间月租3500的出租屋里，窗外是灰蒙蒙的天空和远处正在施工的地铁站。电脑屏幕右下角的时间跳到了23:47，微信弹出一条消息：“老公，你今天又不回来吗？”——那是我老婆发来的。我们在上海领证，却因为工作分隔两地，她留在浦东做UI设计，而我则北上加入了一家号称“要做下一个Notion”的创业公司，担任前端。
当时我信了他们的鬼话，以为能做出改变世界的产品。结果呢？三个月后，公司账上只剩8万块，CTO跑路，CEO在全员会上红着眼说：“兄弟们，对不起，我们撑不住了。”我的劳动合同“被优化”，N+1没给全，只拿到了一个月工资——15k，连我两个月房租都不够。
那段时间真的很焦虑。每天刷BOSS直聘到凌晨三点，面试官问：“你只会React？会不会点后端？”我哑口无言。作为一个纯前端，我一直觉得“后端有后端的事，前端有前端的活”，直到失业那天才明白：在小公司，你得一个人扛起整个产品。
转折点：从“只会写页面”到想搞个自己的产品
上周五晚上，我又一次没回上海（其实根本回不起，高铁票太贵）。老婆视频时看我状态不对，直接说：“要不你先别找工作了？用这段时间学点新东西。你看隔壁老王，自己做了个小工具上线，现在月入过万。”
我苦笑：“老王是Python大神，我是切图仔啊。”
“切图仔怎么了？你不是一直想做个自己的产品吗？”她顿了顿，“我记得你说过，想做一个‘情侣异地打卡’的小网站，记录我们每周见面的日子。”
这句话戳中了我。是啊，我总抱怨异地辛苦，却从来没想过用技术去解决它。程序员最大的悲哀，不是不会写代码，而是明明有解决问题的能力，却只用来给别人打工。
于是，我决定：用Django搭一个属于我们的小产品。名字都想好了——“Weekend Together”。
为什么选Django？而不是Flask、FastAPI？
说实话，一开始我想用Node.js + Express，毕竟前端出身，JS全家桶更熟。但翻了翻GitHub，发现很多小型SaaS产品都是用Python + Django写的——比如那个火出圈的“每日一句英语”网站。而且Django自带Admin后台、用户系统、ORM，对新手极其友好。
更重要的是：我不想再被“前后端联调”折磨了。在前公司，后端接口三天一改，文档永远滞后，我经常对着404干瞪眼。Django可以让我一个人搞定全栈，省去沟通成本——虽然现在只有我和我老婆两个用户。
踩坑实录：从pip install django开始的血泪史
坑1：环境配置——别信“一行命令搞定”
教程里都说：“打开终端，输入pip install django，搞定！”
现实是：我的Mac装了Python 3.9，但系统默认是2.7；虚拟环境建了三个，每个都报错；最后发现是因为之前装过Anaconda，PATH乱成一锅粥。
解决方案：
- 彻底卸载Anaconda（心疼我那些Jupyter Notebook）
- 用
pyenv管理Python版本 - 严格使用
python -m venv myenv创建虚拟环境
教训：别贪快。花一小时配好环境，胜过三天debug。
坍2：startproject之后，项目结构看不懂
运行django-admin startproject weekend_together后，目录长这样：
weekend_together/
├── manage.py
└── weekend_together/
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py
我当时就懵了：为什么有两个同名文件夹？wsgi.py是啥？能不能删？
后来才明白：外层是项目容器，内层才是真正的Django应用配置。Django的“项目（Project）”和“应用（App）”是分开的——这点和前端框架很不一样。比如React里，一个create-react-app就是一个完整项目；但在Django里，一个项目可以包含多个App（比如用户系统、打卡模块、通知模块）。
于是我新建了一个App：
python manage.py startapp couples
然后在settings.py的INSTALLED_APPS里加上'couples'。这一步千万别忘！否则模型、视图全都不会生效。
坑3：模型（Model）写完，数据库没反应
我在couples/models.py里定义了一个简单的打卡记录：
from django.db import models
class DateRecord(models.Model):
date = models.DateField()
note = models.TextField()
created_at = models.DateTimeField(auto_now_add=True)
然后兴冲冲地跑python manage.py makemigrations，结果报错：“No changes detected”。
查了半天才发现：必须先把App注册到settings里，Django才会扫描它的models。我之前只是创建了App，忘了加到INSTALLED_APPS！
改完重新运行，终于生成了0001_initial.py。接着migrate，数据库表成功创建。
感悟：Django的“约定优于配置”很强大，但前提是你得遵守它的约定。一旦偏离，debug时间翻倍。
坑4：前端模板——别试图用React重写Django模板
作为前端，我本能地想把Django的模板系统扔掉，换成React + REST API。但很快意识到：对于只有两个用户的小产品，完全没必要。
Django自带的模板语言足够用：
- 可以用
{% for record in records %}循环渲染打卡记录 - 表单提交用
{% csrf_token %}防攻击 - 静态文件（CSS/JS）放在
static/目录，collectstatic一键收集
我甚至用Tailwind CSS写了点简单样式，直接嵌在模板里。虽然不够“现代化”，但快、稳、省事——这不正是小产品的核心需求吗？
坑5：部署上线——别用免费服务
本地跑得好好的，一部署就崩。我试过Heroku免费版，结果数据库连接超时；又试Vercel，发现它根本不支持Python后端。
最后咬牙花了$7/月买了DigitalOcean的Droplet（最便宜的Ubuntu服务器）。配上Gunicorn + Nginx，再用Let's Encrypt搞个免费HTTPS证书，总算跑起来了。
关键步骤：
DEBUG = False（否则安全漏洞）- 配置
ALLOWED_HOSTS = ['your-domain.com'] - 静态文件交给Nginx处理，别让Django扛
上线那天，我把链接发给老婆。她点了“添加今日打卡”，写了一句：“今天老公没回上海，但网站上线了，开心！”
那一刻，我觉得值了。
教程之外：关于“产品”的思考
很多人学Django，是为了找工作、涨薪。但对我而言，这次学习是一次救赎。
在前公司，我们天天喊“打造极致产品”，实际上却在疯狂堆功能、追DAU。没人关心用户真实需求，包括我自己——我只是个“需求翻译机”，把产品经理的话变成div和button。
但做“Weekend Together”时，每一个字段、每一个按钮，都是为我和老婆的真实场景设计的。比如：
- 打卡必须带日期选择器（因为我们周末才能见面）
- 支持上传照片（她喜欢拍咖啡杯）
- 数据导出为PDF（她说以后结婚纪念日要用）
这才是产品该有的样子：解决具体的人的具体问题。
给想学Django的朋友几点建议
- 别一上来就看官方文档。先找个“从零搭建博客”或“待办清单”的实战教程，跟着敲代码。理解比记忆重要。
- 接受Django的“笨重”。它不像Flask那么灵活，但正因如此，才适合快速验证产品想法。
- 从小做起。别想着第一天就做出Twitter。我的“Weekend Together”只有3个页面，但它是完整的、可用的、属于我的。
- 别怕部署。花点小钱买服务器，比卡在本地强一万倍。看到自己的域名能访问，成就感爆棚。
最后：技术人的出路，不在简历里，在产品里
现在，我已经在面试新工作了。HR问我：“你最近在忙什么？”
我说：“我在做一个小产品，用Django写的。虽然只有两个用户，但她们每天都用。”
对方笑了：“挺有意思。能看看吗？”
我把链接发过去。第二天，收到了offer，月薪22k。
但我知道，真正让我拿到offer的，不是Django技能，而是从“执行者”变成“创造者”的心态转变。
如果你也在焦虑、迷茫，不妨试试：用代码为自己做点什么。不需要融资，不需要团队，只要一个需求、一台电脑、一个周末。
毕竟，最好的教程，永远是你亲手写下的第一行代码。
附：我的极简学习路径
- 安装Python + pip + virtualenv
- 跟着Django官方教程做一遍投票应用
- 自己构思一个小项目（比如“每日喝水记录”、“租房费用分摊”）
- 遇到问题就查Stack Overflow，别死磕
- 部署上线，哪怕只给自己用
共勉。
—— 一个还在和异地抗争的前端，于北京出租屋
评论 0