Django常用命令

1.Django架构模式 MTV架构 Django采用了MTV架构模式 Django也是一个MVC框架。但是在Django中，控制器接受用户输入的部分由框架自行处理，所以 Django里更关注的是模型（Model）、模板(Template)和视图（Views），称为 MTV模式。 M：模型（model） T：模板（template） V：视图（views） 模型：数据存取层，处理与数据...

你点了浏览器的"刷新"按钮，0.5 秒后页面渲染完毕。这 0.5 秒里发生了什么？本文把 Django 处理一个 HTTP 请求的完整链路拆为六个步骤：WSGI Server 接收 TCP 连接 → 中间件栈的洋葱模型逐层处理 → URL 路由匹配 → View 执行业务逻辑 → ORM 生成 SQL 并发送到数据库 → Template 渲染或 JSON 序列化返回响应。每一步都配有对应的源码位置和关键代码片段，读完你能对一个请求的全生命周期建立起清晰的空间模型。穿插真实调试经历——一个中间件错误导致所有

本篇博客聚焦企业办公用品物资管理全新赛道，基于Python+Django打造采购、库存、申领、审批、归还、对账一体化系统，和日志、天气、智能在线考试、智能图书、考勤、会议室、固定资产、CRM、售后、教培排课等所有往期项目完全独立。项目融合库存算法、流程审批、多角色权限、台账管理、数据统计、Excel导出等技术，深度贴合企业行政日常工作，业务落地性极强。

接口突然从 50ms 变成 800ms，你第一反应是什么？"加缓存""改索引""换 SSD"——但你没看到实际的慢查询长什么样。上篇聚焦性能排查的第一步：用 Django Debug Toolbar 把所有 SQL 查询摊在桌面上，再通过 MySQL 的 EXPLAIN 命令读懂每条查询的执行计划。从安装配置 Debug Toolbar 开始，到定位出具体是哪个 View 的哪条 ORM 触发了慢查询，再到 EXPLAIN 输出中的 type / key / rows / Extra 四个核心字段的解读。

Python生态模版引擎：Django、Jinja2、Liquid、Mustache、Mako、Chameleon

上一篇我们使用Bootstrap搭建了一个静态博客页面，但是页面内容是写死的。这一篇我们来学习Django模板系统。模板系统可以把HTML页面和后端数据结合起来，这样我们就可以把数据库中的文章数据展示到页面中。Django中的模板一般是HTML文件。视图函数查询到数据后，可以把数据传递给模板，然后由模板负责展示页面。浏览器请求 -> urls.py -> views.py -> 查询数据 -> 模板渲染 -> 返回页面。

本篇聚焦企业CRM客户关系管理赛道，基于Python+Django打造全链路客户管理系统，和日志、天气、在线考试、智能图书、进销存、租赁、考勤、物业、记账、音乐等所有往期项目完全独立。项目结合状态流转、时间判定、多角色权限、文件附件、聚合统计、数据可视化等技术，完全贴合中小企业销售团队真实业务流程，是职场高频应用的企业级系统。代码结构规范、模块化清晰，可直接私有化部署使用；同时作为毕设、求职项目，CRM系统业务专业性强、技术覆盖面广，具备很高竞争力。

拿到一个 Django 老项目的仓库地址，新手的第一反应是 clone 下来直接 python manage.py runserver——然后迎面撞上 ModuleNotFoundError、mysqlclient 编译失败、Python 版本不匹配三连击。本文是"接手老项目"系列的上篇，聚焦环境复现的完整流程：从 requirements.txt 的版本锁定策略到 pip freeze 的陷阱、从 virtualenv 到 pipenv 的演进、从 MySQL 驱动安装的坑到 settings.py 数据

上篇把 Django 镜像从 2GB 瘦身到 180MB。下篇用 `docker-compose.yml` 把 Django、MySQL、Redis、Nginx 四个服务编排在一起——一个 `docker-compose up -d` 就全跑起来。重点讲：服务之间的依赖顺序控制（`depends_on` + `healthcheck`）、数据库数据持久化（`volumes`）、静态文件和白卷代理（Nginx 反向代理 Gunicorn）、以及生产环境的网络隔离策略。附完整可用的 `docker-compos

上篇讲完了环境复现——老项目终于能在本地跑起来了。下篇进入代码层面：面对一个没有文档的陌生 Django 项目，第一件事不是看 models，更不是看 views——而是看 urls.py 路由树。本文示范了一种"从外向内"的阅读方法：从 `ROOT_URLCONF` 开始，逐层递归画出路由树的完整结构，然后通过"URL → View → Model"的逆向链路快速定位核心业务。穿插真实经历——一个 CRM 系统通过路由树反向分析，发现 120 个 URL 中有 40 个已经废弃但仍然加载了对应的 view

第三板块的收官之作。综合前面九篇文章的全部知识点——环境管理、ORM 优化、请求链路、连接池、密钥管理、Docker 部署、日志规范——从零开发一个完整的在线图书管理系统。功能覆盖：借书/还书/库存管理/用户认证/借阅历史查询，后端 Django + DRF REST API，前端用模板渲染 + Bootstrap，数据库 MySQL 8.0，缓存 Redis，部署 Docker + Nginx。

本文介绍了基于Django 5.2的现代化博客系统DjangoBlog的核心架构与技术亮点。系统采用MTV架构，集成Alpine.js+Tailwind CSS+HTMX前端技术栈，具备插件系统、全文搜索、多主题支持等特性。文章详细解析了系统模块组成、技术选型表、核心功能实现原理，并提供了测试网站地址和付费源码下载链接（14.9元）。项目支持MySQL/SQLite数据库和Redis缓存，包含9个内置插件，可通过Vite进行前端构建。文末附有快速启动指南，适合开发者快速搭建个性化博客平台。

维度FastAPIDjangoVueReact定位高性能 API 框架全栈 Web 框架前端框架前端 UI 库核心哲学类型安全 + 异步电池已内置渐进式组合式适用场景微服务、API 服务复杂 Web 应用、CMS中后台、渐进增强大型 SPA、跨平台性能特点极高（ASGI + async）中等（WSGI，支持异步）虚拟 DOM + 响应式虚拟 DOM + Fiber选型决策框架——然后只在 benchmark 证明你需要时才做优化。

models.pypython运行注意：数据库迁移必须在项目初始化时配置，已建表后修改非常麻烦python运行# 请求前执行逻辑# 响应返回前执行逻辑# 视图异常捕获pass注册到 settings MIDDLEWARE 列表。

N+1 查询是 Django 项目中最隐蔽也最高频的性能杀手。表面看起来代码正常——获取 50 个用户然后显示每个用户的部门名称，但实际上数据库被查询了 51 次而不是 2 次。本文从头拆解 N+1 的成因——Django ORM 懒加载机制与关联对象访问的特性，然后逐一分析 `select_related`（JOIN 方式预加载外键）和 `prefetch_related`（额外查询预加载多对多）的差异和适用场景。配有 Django Debug Toolbar 实测和真实事故——一个报表接口因为 N+1

把 Django 项目 Docker 化的第一步——写 Dockerfile。但大多数人第一次构建出来的镜像都在 800MB-1.2GB 之间。原因很简单：基础镜像选了 `python:3.11` 而不是 `python:3.11-slim`，构建依赖和运行依赖混在一起，`pip install` 的缓存文件没清理。上篇聚焦 Dockerfile 的优化——从单阶段构建到多阶段构建、从 `pip install` 到 `--no-cache-dir`、从盲目选镜像到理解 `slim` 和 `alpine`