项目、settings 与请求链路
最小可运行实现
# tickets/views.py
import django
from django.http import JsonResponse
from django.views.decorators.http import require_GET
@require_GET
def health(request):
return JsonResponse({"status": "ok", "django": django.get_version()})# config/urls.py
from django.contrib import admin
from django.urls import path
from tickets.views import health
urlpatterns = [
path("admin/", admin.site.urls),
path("health/", health, name="health"),
]# config/settings.py（只展示需要新增的部分）
INSTALLED_APPS = [
# Django 自带应用……
"tickets",
]运行 python manage.py runserver，另开终端执行：
curl -i http://127.0.0.1:8000/health/
curl -i -X POST http://127.0.0.1:8000/health/心智模型
manage.py 选择 settings；django.setup() 配置日志并加载应用注册表；服务器构造 request；middleware 包裹后续处理；URLconf 选择 view；view 返回 response。ASGI/WSGI 入口由服务器调用，普通管理命令已经替你执行 setup，独立脚本才需要显式配置。
深水边界
- settings 是启动配置，不是运行时全局状态仓库。秘密来自环境或秘密管理器。
ALLOWED_HOSTS校验 Host，不代替反向代理访问控制。- App 的导入阶段应保持轻量；导入时查询数据库会破坏迁移、测试和冷启动。
- 健康检查分层：存活检查不应依赖所有下游，就绪检查才验证接流量所需依赖。
- Django 6.0 需要 Python 3.12+；5.2 是最后支持 Python 3.10/3.11 的系列。
排错顺序
python -m django --version是否属于当前虚拟环境。python manage.py check是否能加载 settings 和应用。python manage.py showmigrations是否看到迁移状态。- URL 是否带尾斜线，方法是否允许。
- 查看完整异常和第一处属于自己代码的栈帧。
验收
manage.py check 通过；GET /health/ 返回固定字段，POST 返回 405；测试能在全新测试库运行。
练习（先独立完成）
- 为健康响应增加
service: "ticket-desk"，写一个测试固定合同。 - 创建
config/settings_test.py，只覆盖测试真正不同的配置。 - 解释为什么健康检查不应该返回全部 settings。
深度加餐：把一次请求画成流水账
调试 Django 时不要从模板开始猜；先确认请求经过哪个进程、哪个中间件、哪个 view，最后是谁生成响应。
先做一个可观察实验
# tickets/middleware.py
import time
from django.http import JsonResponse
class RequestTraceMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
started = time.perf_counter()
response = self.get_response(request)
response['X-Request-Time-ms'] = f'{(time.perf_counter() - started) * 1000:.2f}'
return response
# config/settings.py
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'tickets.middleware.RequestTraceMiddleware',
'django.middleware.common.CommonMiddleware',
]预期：响应头能看到处理耗时；中间件按列表顺序进入、按反向顺序退出，异常路径也应被记录。
原理下潜与工程边界
manage.py 只是启动入口，真正的配置由 DJANGO_SETTINGS_MODULE 指向。ASGI/WSGI 服务器加载 application 后才进入中间件链；路由匹配、view、模板和响应回写都发生在同一个请求合同里。
中间件里访问数据库会让每个请求都背上成本；StreamingHttpResponse 的内容可能在 view 返回后才迭代；异常中间件与 DEBUG 页面不应泄漏密钥和堆栈给外部用户。
反例排错路线
用 request.path、request.method、request.id 记录最小字段；先跑 django-admin check，再确认 URL 解析，最后才进入业务函数。若耗时异常，分别测中间件、查询和模板渲染。
练习加码（仍不提供答案）
加码：实现一个只给 staff 用户添加诊断头的中间件，并测试 200、404、异常响应都不会泄漏内部异常文本。
验收时请补充：正常路径、权限或失败路径、以及一条能证明事务/资源/配置边界没有被绕过的测试。
继续查阅：Django 官方文档（外部资料已收录于证据账本） · Django 安全清单（外部资料已收录于证据账本）
课程合同：项目配置与请求生命周期
学习目标
学完本篇，读者应能把「GET /health/ 经过 WSGI/ASGI、middleware、URL resolver、view 和响应回写」拆成输入、可信边界、Django 机制和可复查证据；同时能说明 Django 6.0 与 5.2 LTS 的差异不会改变业务不变量。
心智模型
请求/数据输入 → 边界检查 → Django 核心机制 → 可观察输出 → 恢复动作。配置、数据库提交和外部副作用分别拥有自己的生命周期；没有证据的“应该可以”不算完成。
本地机制图
图中的“输入”是不可信的 HTTP、表单、任务或配置；“边界”负责身份、格式、权限、大小、超时与版本；“机制”才是 URL、View、ORM、事务、缓存、Tasks 或 ASGI；“证据”是测试、响应、日志、查询计划和发布记录。
最小实验
在全新虚拟环境中运行：
python -m django --version
python manage.py check
python manage.py test实验只验证一个机制：输入一条有效值，再输入一条空值、重复值或无权限值。每次实验都记录 Django 版本、数据库、命令和退出码。
完整场景
把实验接到 tickets 工单流：请求携带用户身份和工单 ID，经过当前专题负责的边界，完成一次读或写，并留下响应状态、数据库变化、日志字段和清理动作。完整场景必须能第二次执行，或明确说明幂等键、事务回滚、缓存失效和任务重试策略。
运行输出
成功路径应出现：
Django 6.0.x
System check identified no issues (0 silenced).
OK失败路径要保留真实信号，例如 400（输入无效）、403（权限/CSRF）、404（资源不存在）、405（方法不允许）或数据库约束异常；不要把失败改写成含糊的 200。
失败边界
至少验证：空输入、重复提交、匿名用户、越权对象、并发写入、下游不可用、超时和版本不兼容。记录“谁拒绝、何时拒绝、状态是否回滚、重试是否安全”。开发模式的 traceback 不得进入生产响应，缓存不得跨用户复用敏感结果。
原理与排错
先确认版本和 settings，再用 manage.py check 定位启动问题；接着确认 URL/任务入口、输入解析和权限；最后检查 SQL、事务提交、响应和副作用。若结果异常，用最小复现打开 SQL/请求 ID/任务 ID 观测，沿「复现 → 缩小 → 观测 → 修复 → 回归」闭环，不靠重装依赖猜测。
练习（正文不泄答案）
- 为上述完整场景补一条正常路径和两条失败路径测试，并记录完整输出。
- 画出本篇机制图，标出身份 owner、数据提交点、缓存/任务副作用和恢复动作。
- 故意制造一次重复、越权或超时，说明应返回的状态、日志字段和是否可重试。
- 写一条 Django 5.2 LTS 兼容验收标准，再说明 Django 6.0 的新能力是否需要条件分支。
验收标准：命令可重复、输出可复查、正文没有练习答案；完成后再打开本阶段答案册。
答案册
本阶段答案册提供参考实现、关键推理、失败边界和替代方案；先独立完成练习再对照。
下一篇
下一篇是环境配置与应用启动，继续沿同一条输入—边界—机制—证据链前进。