OliverChiu
管理
浏览知识库目录

Python

综合实战项目与进阶路线

发布于 2026年7月22日

综合实战项目与进阶路线

完成前面的章节后，最重要的不是继续收集零散知识，而是独立完成一个有真实业务规则的项目。本篇以“团队任务平台”为例，给出从需求、建模、迭代到上线的完整练习方案。

一、项目目标

实现一个小型团队任务平台：

  • 用户注册、登录和个人资料。
  • 创建团队和邀请成员。
  • 团队下创建项目。
  • 项目下创建任务、评论和附件。
  • 任务状态、优先级、负责人和截止时间。
  • 搜索、筛选、排序和分页。
  • 站内页面与 REST API。
  • 邮件或异步通知。
  • 管理后台、测试、日志和生产部署。

二、先写业务规则

编码前先明确：

  1. 团队拥有者可以管理成员，普通成员不能。
  2. 只有团队成员能看到团队项目。
  3. 项目成员可创建任务，任务负责人可更新状态。
  4. 删除项目需要二次确认，且只允许团队拥有者操作。
  5. 已归档项目不可新增任务。
  6. 附件只能由有权查看任务的用户下载。
  7. 所有关键权限变更都记录审计日志。

明确规则后，才能决定模型约束、查询范围、表单校验和测试用例。

三、应用拆分

config/          项目配置、根路由、ASGI/WSGI
users/           用户与个人资料
teams/           团队、成员、邀请
projects/        项目与项目成员
tasks/           任务、评论、附件
notifications/   通知与后台任务
core/            公共基础能力

按业务边界拆分，而不是创建 models_app、views_app 这种按技术层拆分的应用。项目初期不要过度拆分；某个模块拥有相对独立的数据和业务职责时再成为 App。

四、核心模型草图

from django.conf import settings
from django.db import models


class Team(models.Model):
    name = models.CharField(max_length=100)
    owner = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.PROTECT,
        related_name="owned_teams",
    )
    members = models.ManyToManyField(
        settings.AUTH_USER_MODEL,
        through="TeamMembership",
        related_name="teams",
    )


class TeamMembership(models.Model):
    class Role(models.TextChoices):
        OWNER = "owner", "拥有者"
        ADMIN = "admin", "管理员"
        MEMBER = "member", "成员"

    team = models.ForeignKey(Team, on_delete=models.CASCADE)
    user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    role = models.CharField(max_length=20, choices=Role.choices)
    joined_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["team", "user"],
                name="unique_team_member",
            )
        ]


class Project(models.Model):
    team = models.ForeignKey(
        Team,
        on_delete=models.CASCADE,
        related_name="projects",
    )
    name = models.CharField(max_length=120)
    is_archived = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)


class Task(models.Model):
    class Status(models.TextChoices):
        TODO = "todo", "待处理"
        DOING = "doing", "进行中"
        DONE = "done", "已完成"

    project = models.ForeignKey(
        Project,
        on_delete=models.CASCADE,
        related_name="tasks",
    )
    title = models.CharField(max_length=200)
    description = models.TextField(blank=True)
    status = models.CharField(
        max_length=20,
        choices=Status.choices,
        default=Status.TODO,
    )
    assignee = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        null=True,
        blank=True,
        on_delete=models.SET_NULL,
        related_name="assigned_tasks",
    )
    due_at = models.DateTimeField(null=True, blank=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

through 模型让团队成员关系拥有角色、加入时间等额外字段。数据库唯一约束保证同一用户不会重复加入同一团队。

五、权限查询基线

所有项目查询都从当前用户可见范围开始：

def projects_for_user(user):
    if not user.is_authenticated:
        return Project.objects.none()

    return (
        Project.objects
        .filter(team__members=user)
        .select_related("team", "team__owner")
        .distinct()
    )

View、API、导出和后台任务尽量复用同一权限查询函数，避免不同入口出现不一致。

六、推荐迭代顺序

迭代 1：最小闭环

  • 自定义用户模型。
  • 团队、项目、任务三个核心模型。
  • 管理后台创建基础数据。
  • 任务列表、详情和创建页面。

完成标准：一个用户能登录并管理自己的团队任务。

迭代 2：权限和协作

  • 团队成员与角色。
  • 邀请成员。
  • 评论、附件和状态流转。
  • 对象级权限测试。

完成标准：修改 URL 主键也不能看到或修改其他团队数据。

迭代 3：可用性

  • 搜索、筛选、排序和分页。
  • 消息反馈和空状态页面。
  • 邮件通知与后台任务。
  • 响应式页面和无障碍基础。

迭代 4：API

  • Serializer、ViewSet 和 Router。
  • API 认证、权限和限流。
  • OpenAPI 文档。
  • API 自动化测试。

迭代 5：上线

  • PostgreSQL 与 Redis。
  • 生产配置、安全检查和日志。
  • CI 中运行测试。
  • HTTPS、备份、监控和回滚。

七、核心测试矩阵

场景 匿名用户 非成员 普通成员 管理员 拥有者
查看项目 拒绝 拒绝 允许 允许 允许
创建任务 拒绝 拒绝 允许 允许 允许
邀请成员 拒绝 拒绝 拒绝 允许 允许
删除项目 拒绝 拒绝 拒绝 按规则 允许
下载附件 拒绝 拒绝 允许 允许 允许

为每个高风险动作至少测试成功、未登录、无权限、对象不存在和输入非法。

八、项目完成标准

功能：

  • 核心流程可以从页面和 API 完成。
  • 权限规则在服务端统一执行。
  • 搜索、分页、空状态和错误提示完整。

质量：

  • 核心业务和权限有自动化测试。
  • 没有明显 N+1 查询。
  • 配置按环境分离，密钥不在仓库。
  • 日志可关联请求和关键对象。

上线：

  • 使用 PostgreSQL 和生产应用服务器。
  • HTTPS、静态文件、媒体存储配置正确。
  • 有备份、恢复、监控和回滚方案。
  • python manage.py check --deploy 无未处理的关键警告。

九、代码组织建议

业务变复杂时可逐步拆分：

tasks/
  models.py          数据结构与模型自身行为
  forms.py           HTML 输入校验
  selectors.py       复杂读取查询
  services.py        跨模型写入流程
  permissions.py     可复用权限规则
  views.py           HTTP 编排
  serializers.py     API 输入输出
  tasks.py           后台任务
  tests/             按模块组织测试

这不是强制模板。文件很小时保持简单；只有职责明显增长时再拆分。

十、继续深入的方向

  • 数据库：PostgreSQL 索引、全文搜索、锁、隔离级别和查询计划。
  • API：OpenAPI、版本管理、幂等、OAuth2/OIDC 和 Webhook。
  • 实时能力：ASGI、WebSocket、Django Channels。
  • 分布式任务：Celery 工作流、定时任务、死信与可观测性。
  • 架构：领域建模、服务层、模块边界和大型项目拆分。
  • 运维：容器、CI/CD、滚动发布、指标、链路追踪和容量规划。
  • 安全：威胁建模、依赖供应链、密钥轮换、审计和渗透测试。

一次只选一个方向，并把它落到项目功能上。比如学习 WebSocket，就实现任务状态实时更新；学习全文搜索，就为任务和评论加入可排序的搜索结果。

十一、最终自测

如果你能独立回答并实践下面的问题，就已经具备完整的 Django 项目开发能力：

  1. 请求如何经过路由、中间件、视图、模型和模板？
  2. 如何设计模型关系、约束、迁移和事务？
  3. 如何保证用户只能操作自己有权访问的数据？
  4. 如何定位慢查询并避免 N+1？
  5. 如何测试核心业务和权限？
  6. 如何安全处理密钥、Cookie、文件上传和跨站请求？
  7. 如何完成迁移、静态文件、应用服务器、HTTPS、监控和回滚？

学习路线至此形成完整闭环：能开发、能测试、能优化、能保护、能上线、能维护。

上一篇：部署 Django 项目 ｜ 返回：Django 完整学习路线