Django 模式集

要解决的具体问题

• 随着 Django 项目规模增长，代码容易散落在 views.py、serializers.py 或模型中，导致职责不清、重复逻辑多、修改成本高。
• ORM 查询存在隐式 N+1、未分页列表接口、批量写入性能差等问题，排查时缺少统一入口。
• 跨应用副作用依赖信号或直接调用，流程难以追踪，容易过度耦合。
• 配置与密钥管理不规范，敏感信息可能被硬编码在 settings.py 中。

技能如何工作

• 通过模块化拆分组织 Django 项目：业务写操作集中在 services.py，读操作集中在 selectors.py，视图保持轻薄。
• 使用 django-debug-toolbar 或 connection.queries 在测试中检查查询，避免 N+1 和全表扫描。
• 在 DRF 序列化器中使用自定义 validate 方法进行输入校验，而不是把逻辑堆在视图层。
• 跨应用副作用优先使用信号；同一应用内部直接调用服务，保证调用链清晰。
• 自定义中间件遵循 WSGI callable 模式，便于在请求处理链中统一注入逻辑。
• 提供检查清单，覆盖业务逻辑位置、关联查询、分页、配置拆分、迁移审核、批量操作、测试覆盖等关键项。

适用边界与注意点

• 该技能不是可自动替换代码的脚手架，而是一套需要团队共同遵守的工程约定。
• 信号只能用于跨应用副作用；同应用逻辑直接调用服务，避免流程难以追踪。
• 原始 SQL 必须使用参数化查询，密钥应通过环境变量管理，不要写进 settings.py。
• 检查清单应作为代码审查和测试的参考，不能替代自动化测试与持续集成。