1.2 环境搭建与项目骨架

1.2 环境搭建与项目骨架

本节摘要：本节动手创建墨迹博客的骨架：隔离的虚拟环境、锁定的依赖、由管理命令生成的项目与应用目录。重点不是命令本身，而是每一步背后的工程理由——为什么要隔离、为什么项目和应用是两个东西、为什么应用必须注册。

先隔离，再安装

Python 项目第一课不是 Django，是环境隔离。系统全局的包目录就像合租屋的公共冰箱：谁都能放东西，版本互相污染，出问题无从追溯。虚拟环境给每个项目一间独立厨房。

# 创建并激活虚拟环境（后续所有命令都在激活状态下执行）
python -m venv .venv
# Windows 激活
.venv\Scripts\activate
# macOS / Linux 激活
source .venv/bin/activate

# 安装 Django 并冻结版本
pip install django
pip freeze > requirements.txt
​

把依赖清单提交到版本库，任何一个同事、任何一台服务器、第 10 章的部署环境，都能用一条命令复现完全相同的依赖组合。墨迹博客上线当晚最怕的不是代码有 bug，而是"本地好好的、服务器上 Django 版本差了一个小版本号"。

版本怎么选？跟最新稳定版即可，初学不必追长期支持版差异。唯一要注意的是 Python 与 Django 的版本兼容矩阵——安装前确认你的 Python 版本在支持列表里，否则装上的会是陈旧版本而不自知。

两条命令生成骨架

django-admin startproject moji_project
cd moji_project
python manage.py startapp blog
python manage.py startapp accounts
​

跑完开发服务器确认骨架是活的：

python manage.py runserver
​

浏览器看到火箭欢迎页，骨架就绪。这个内置服务器只用于开发：它单线程、自动重载、明说了不适合生产。第 10 章会换上真正的应用服务器。

还有一个容易忽略的习惯值得在这里养成：骨架生成后立刻初始化版本库并做首次提交，此后每完成一小步就提交一次。这不只是为了备份——当你某次改动把项目改坏、又记不清改了哪些文件时，版本对比能让你在三十秒内看清"到底动了什么"。开发过程中最贵的时间往往不是写代码，而是找回"刚才还能跑"的状态。首次提交也是生命周期的第一个锚点，将来复盘时，它能告诉你项目的确切出生时刻。

项目与应用：一个关键区分

Django 里"项目"和"应用"是两个概念，初学者最容易混：

• 项目是一整套配置加上若干应用的容器，对应同名配置包——settings、根 URL 配置、WSGI 入口都在这里。
• 应用是一个可复用的功能模块，对应一个 Python 包——墨迹博客里 blog 管内容，accounts 管用户相关。

一个比喻：项目是一家出版社，应用是旗下的编辑部门。部门有自己的档案柜（模型）、自己的业务流程（视图），但纸张规格、出版规范（数据库配置、中间件、时区）由出版社统一规定。

划分应用的边界有个经验法则：能否想象把这个应用原样搬到另一个项目里用。blog 可以，accounts 可以，"项目专属的首页聚合"就不该单独成应用。宁可前期两个大应用，也不要按文件类型切出 models 应用、views 应用这种反模式——那是把 MTV 分工又搅浑了。

应用必须注册

# 项目配置中的应用清单（节选）
INSTALLED_APPS = [
    "django.contrib.admin",      # 后台，第8章
    "django.contrib.auth",       # 认证，第7章
    "django.contrib.contenttypes",
    "django.contrib.sessions",   # 会话，第7章
    "django.contrib.messages",
    "django.contrib.staticfiles",  # 静态文件，第5章
    "blog",
    "accounts",
]
​

新应用不写进这个清单，它的模型不会被迁移系统发现（第 2 章）、它的模板标签不可用、Admin 也找不到它。这是新手三大"为什么没生效"问题之首。

骨架里每个文件的定位

moji_project/            # 工作区根，虚拟环境、依赖清单住这
├── manage.py            # 管理命令入口，几乎所有操作从这进
└── moji_project/        # 配置包：项目级设置
    ├── settings.py      # 全局配置：数据库 应用 中间件 时区
    ├── urls.py          # 根 URL 表，第4章的路由总闸
    ├── wsgi.py          # 同步部署入口，第10章
    └── asgi.py          # 异步部署入口
blog/
├── models.py            # 模型层，第2章主战场
├── views.py             # 视图层，第4章主战场
├── admin.py             # Admin 配置，第8章
├── apps.py              # 应用元信息
├── migrations/          # 迁移脚本，第2章生成
└── tests.py             # 测试，第9章
​

⚠️ 一个高频疑问：settings 里的密钥配置提交到版本库安全吗？开发期无妨，但第 10 章部署前必须把敏感值挪到环境变量。骨架阶段就养成"配置与密钥分离"的意识，比上线前突击补救从容得多。

配置里两项目前就值得改：语言与用时区改成中文环境，后续 Admin 与错误信息会直接以中文呈现，学习报错的门槛低不少。

LANGUAGE_CODE = "zh-hans"
TIME_ZONE = "Asia/Shanghai"
​

本节要点回顾

• 虚拟环境是第一道工程纪律：依赖清单进版本库，环境可复现。
• 项目是配置容器，应用是功能模块：按业务边界切应用，不按文件类型。
• 应用必须注册进配置：不注册等于不存在。
• 骨架即架构投影：每个文件对应 MTV 的一层，第 2 章起我们逐层点亮。

骨架就位，下一章让模型层第一个入住：设计文章、评论与作者的模型，并交给迁移系统建表。