企业官网建设流程全解析

1. 项目全貌拆解：Django中医药膳慢性病食疗平台到底在做什么

先把这个项目的定位说清楚。它是一个典型的Django Web毕业设计项目，核心业务是围绕"慢性病患者的日常饮食管理"展开，只不过切入的角度用了中医食疗这个传统方向。简单说，就是做一个网站，让用户（尤其是患有高血压、糖尿病、高血脂这类慢性病的人群）能够根据自己的体质、病症和忌口情况，在平台上查到适合自己的药膳方子、食谱和食材配伍建议。

这类项目在计算机专业的毕业设计里非常常见，每年都有大量学生选Web开发方向，而Django因为自带Admin后台、ORM数据库操作、用户认证体系，开发效率高，特别适合在几个月内完成一个能跑、能演示、能答辩的完整系统。这个题目还把"中医药膳"和"慢性病食疗"结合进来，等于加了一层专业场景，在盲审和答辩环节比单纯的学生管理系统、图书管理系统更有辨识度，也更容易扩展业务故事。

从标题里的"全套源码+文档"、"丰富项目"、"远程调试"、"讲解"、"定制"这些词就能猜出这套资料的服务模式——源码给你，文档给你，环境跑不起来可以远程帮你调，答辩讲不清可以给你讲思路，导师提了新需求可以加钱定制。这几乎成了Django毕设项目的标准交付形态。但作为一篇技术拆解博文，我不打算停留在"卖资料"这个层面，而是把这类项目背后的设计逻辑、技术选型、实现要点和避坑经验摊开来讲，让拿到Hands on项目的人能真正跑通、看懂、说得出原理。

我翻了一圈跟这个标题相关的热搜词，发现"django创建app"、"django添加好友"、"pip install django pymodbus requests"、"django执行查询-删除对象"这类词的搜索量都不低，说明很多人卡在最基础的Django操作上。这意味着这篇文章的读者，大概率是刚学完Python基础、Django官网教程刷过一两遍、但真要独立从零做一个完整项目就手足无措的应届生。所以下面的内容我会尽量讲透"为什么这么做"，而不是只给一句"你抄就行"。

2. 需求拆解与数据库设计：慢性病食疗平台的核心模型

2.1 从业务场景推导功能模块：不是拍脑袋，是顺着使用流程走

做毕设最容易犯的毛病就是一上来就写代码，写到哪算哪。我建议拿到这类题目后，先把自己当成一个真实用户，把"从注册到使用完一次功能"的完整流程走一遍，功能模块就自然浮出水面了。

这个食疗平台面向两类角色：

• 普通用户（患者/访客）：注册登录、浏览药膳方子、按疾病类型和体质搜索食谱、收藏喜欢的方子、查看食材详情、提交自己的食疗反馈。
• 管理员：维护疾病分类、维护体质标签、发布药膳内容、审核用户评论、查看用户数据统计。

顺着这个流程走，核心功能模块就出来了：用户认证模块、疾病分类管理模块、药膳信息展示模块、食材库模块、搜索与筛选模块、收藏与评论模块、后台管理模块。

这里有个容易被忽略的设计点：中医药膳信息本身的结构化程度很高。一道药膳方子，至少要包含：方名、适用病症（可以多个）、适用体质（可以多个，比如气虚质、阳虚质）、主要食材、具体做法、功效说明、禁忌人群、建议食用频率。这些字段如果全塞进一个表，后面做"按体质筛选"、"按疾病筛选"会非常痛苦。所以设计数据库时要把"药膳"和"疾病"、"体质"设计成多对多关系，而不是一对多。

2.2 数据库表设计：五张核心表撑起整个业务

我直接给出一版经过验证的表结构设计，这套设计我见过很多同类毕设项目在用，扩展性和可解释性都不错：

• User（用户表）：可以直接用Django自带的auth.User扩展，也可以从AbstractUser继承加字段，比如手机号、年龄、历史疾病备注。毕设答辩时，说"我基于Django内置用户系统做了扩展"会比"我自建了一套用户表"更显专业。
• Category（疾病分类表）：存高血压、糖尿病、高血脂这类慢性病名称和描述，用于前台按病种浏览。
• Constitution（体质表）：存中医九大体质（气虚质、阳虚质、阴虚质、痰湿质、湿热质、血瘀质、气郁质、特禀质、平和质），这是中医药膳区别于普通食谱平台的核心标签体系。
• DietRecipe（药膳食谱表）：主表，字段包括标题、封面图、适应疾病（与Category多对多）、适应体质（与Constitution多对多）、原料配方（TextField存结构化文本）、烹饪步骤、功效介绍、注意事项。
• Favorite / Comment（收藏表、评论表）：用户行为记录，关联User和DietRecipe。

有一点值得注意：多对多关系在Django里有两种实现方式。简单的可以直接用models.ManyToManyField，Django自动生成中间表；复杂的（比如中间表还要记录额外字段）就手动建中间模型，用through参数关联。药膳和食材之间如果还要记录"用量"，那就必须手动建中间表，这个细节踩过坑的人最有体会。

2.3 ORM查询设计要点：基础查询这样写，既能跑又能在答辩时讲

Django的ORM是这套技术栈里最值得讲的部分，因为每次答辩老师必问数据查询。这里我列举食疗平台里最常见的几个查询需求以及写法：

# 查询所有适合"气虚质"体质的药膳 recipes = DietRecipe.objects.filter(constitutions__name='气虚质') # 查询同时适合"高血压"和"糖尿病"的药膳 recipes = DietRecipe.objects.filter(categories__name='高血压').filter(categories__name='糖尿病') # 按疾病和体质联合筛选（前端传参） recipes = DietRecipe.objects.all() if disease := request.GET.get('disease'): recipes = recipes.filter(categories__id=disease) if constitution := request.GET.get('constitution'): recipes = recipes.filter(constitutions__id=constitution) # 收藏排行（annotate用法，答辩加分项） from django.db.models import Count hot_recipes = DietRecipe.objects.annotate(fav_count=Count('favorite')).order_by('-fav_count')[:10]

filter多参数和多行filter的区别要分清楚：逗号分隔是AND关系，链式调用也基本是AND，但如果涉及跨表查询，链式多个filter有时会因SQL的JOIN逻辑产生意想不到的结果。有经验的开发者更倾向于用Q对象来表达复杂条件：

from django.db.models import Q recipes = DietRecipe.objects.filter(Q(categories__name='高血压') | Q(categories__name='糖尿病'))

这个知识点在很多Django面试题里都会出现，答辩时主动讲"为什么这里用Q而不是多参数filter"，老师一听就知道你是真写过代码的。

3. 项目搭建与核心功能实现：从空目录到能演示的全过程

3.1 环境准备与项目初始化：这几条命令背后发生了什么

先说环境。Django项目最怕Python版本和Django版本不匹配，很多报错（比如ImportError: cannot import name 'force_text' from 'django.utils.encoding'）就是版本错位导致的。我做这个项目时用的是Python 3.10 + Django 4.2 LTS版本，一个是当前主流Python版本，一个是Django维护周期最长的稳定版，遇到问题搜索引擎能查到的解决方案也最全。

创建项目并初始化App的完整命令是这样：

# 建议先建虚拟环境，避免污染全局Python python -m venv venv source venv/bin/activate # Windows下为 venv\Scripts\activate # 安装Django和必要的第三方库 pip install django pillow django-simple-captcha # pillow处理图片字段，captcha做验证码 # 创建项目和核心App django-admin startproject foodcare . python manage.py startapp recipe python manage.py startapp user

说一下为什么不把全部功能放在一个App里。很多人图省事，所有models、views、urls全写在一个App下，项目也能跑，但等到写文档和答辩的时候就尴尬了——数据库、路由、模板全混在一起，讲不清模块划分。按照user（用户认证）、recipe（药膳内容）来拆分，角色清晰，docstring也好写。如果你的项目里还有"论坛"或"健康测评"这类扩展功能，就再单独建App，不要都塞进recipe里。

创建完App后，记得去settings.py的INSTALLED_APPS里注册。这一步漏掉，Django不会报编译错误，但运行时会提示找不到模板或没有数据表，而且错误信息不是直观的"你忘了注册"，新手排查起来很耗时间。

3.2 用户认证模块：别重复造轮子，用Django自带的Auth扩张

用户注册、登录、退出，这类功能用Django自带的认证模块做非常快，而且安全性远比自己写session管理要高。这里给出一个基于AbstractUser的自定义用户模型写法：

from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): phone = models.CharField('手机号', max_length=11, blank=True) health_note = models.TextField('健康备注', blank=True)

关键一步是必须在settings.py里写：

AUTH_USER_MODEL = 'user.User'

这句话的顺序非常重要：任何一次数据库迁移之前就要配好，否则建完表之后再想改自定义用户模型，Django会给出大量迁移冲突，处理起来极其痛苦。我见过不止一个同学在这上面花了一下午才把数据库重置掉。用AbstractUser而不是写一个全新的User类，好处在于既能扩展字段，又能直接用@login_required装饰器、request.user.is_authenticated这类现成机制实现登录校验。

3.3 药膳信息展示与筛选功能：ListView + 多条件搜索

前台展示页是食疗平台的门面，也是功能演示的重点。Django的ListView泛型视图可以少写很多代码：

# recipe/views.py from django.views.generic import ListView from .models import DietRecipe class RecipeListView(ListView): model = DietRecipe template_name = 'recipe/list.html' context_object_name = 'recipes' paginate_by = 12 # 一页显示12条 def get_queryset(self): queryset = super().get_queryset() disease = self.request.GET.get('disease', '') constitution = self.request.GET.get('constitution', '') keyword = self.request.GET.get('keyword', '') if disease: queryset = queryset.filter(categories__id=disease) if constitution: queryset = queryset.filter(constitutions__id=constitution) if keyword: queryset = queryset.filter(title__icontains=keyword) return queryset def get_context_data(self, **kwargs): context = super().get_context_data(**kwargs) context['categories'] = Category.objects.all() context['constitutions'] = Constitution.objects.all() # 把当前筛选条件传回模板，用于保持选中状态 context['current_disease'] = self.request.GET.get('disease', '') context['current_constitution'] = self.request.GET.get('constitution', '') return context

有一个细节值得说明：为什么我建议用icontains做关键词搜索而不是contains？因为icontains忽略大小写，Windows上SQLite默认情况对中文没差别，但如果你后续把数据库切到MySQL（很多毕设外审时会要求兼容MySQL），大小写敏感性就体现出来了，用icontains能避免这类坑。

模板端接收筛选条件并保持下拉框选中态的逻辑也要写对：

<select name="disease" class="form-select"> <option value="">全部疾病</option> {% for cat in categories %} <option value="{{ cat.id }}" {% if current_disease == cat.id|stringformat:"s" %}selected{% endif %}> {{ cat.name }} </option> {% endfor %} </select>

注意current_disease是字符串，而cat.id是整数，直接比较永远不相等。这个bug很多新手会踩，先在视图里转好字符串类型，或者模板用stringformat过滤器，就不会出错了。

3.4 后台管理：Django Admin的正确打开方式

Django自带的Admin后台是这类管理后台项目的最大杀器，大量的数据管理功能根本不需要自己写页面，只要你把models注册到admin.py里，增删改查全都有。关键是做两件事让后台"专业感"更强：

# recipe/admin.py from django.contrib import admin from .models import DietRecipe, Category, Constitution @admin.register(DietRecipe) class DietRecipeAdmin(admin.ModelAdmin): list_display = ('title', 'get_categories', 'get_constitutions', 'created_at') list_filter = ('categories', 'constitutions') # 侧边栏筛选 search_fields = ('title', 'ingredients') # 后台搜索框 filter_horizontal = ('categories', 'constitutions') # 多对多选择优化 def get_categories(self, obj): return ", ".join([c.name for c in obj.categories.all()]) get_categories.short_description = '适用疾病'

filter_horizontal这个属性必须提，因为默认的多对多选择框是个多选框列表，选项一多操作很不方便，换成左右双栏选择器后整体体验一下子就不一样了。答辩演示后台的时候，这个细节能直观体现你考虑到了用户操作体验，算是低成本高回报的优化。

4. 远程调试与项目运行：解决环境问题才是动手写代码的前提

4.1 远程调试的价值与常见方案：别人怎么帮你调通这套代码

标题里出现的"远程调试"在毕设圈子里含义比较宽泛，通常指三种情况：

• 卖家通过远程桌面/TeamViewer/向日葵直接操作你的电脑，帮你把环境配置好、把代码跑起来。
• 你在本地开发，运行代码的服务器在远端（比如云服务器），需要远程部署并调试报错。
• 用IDE的远程调试功能，连接远程Python解释器进行断点调试。

对毕设项目的场景来说，绝大多数远程调试需求是第一种——压根不是高深的调试技巧，就是环境配置问题太多、沟通成本太高，干脆让懂行的人远程操作一遍，顺便录屏发给你。

但如果你希望自己掌握一点"真·远程调试"技能，我建议你至少学会用VS Code的Remote-SSH插件，或者PyCharm Professional的远程解释器功能。这两个工具都能让你在本地IDE里直接编辑服务器上的代码、在服务器环境里跑Django开发服务器，断点也能正常命中。具体配置步骤如下：

1. 在服务器上安装Python和虚拟环境，用pip install -r requirements.txt装好依赖。
2. 本地VS Code安装Remote-SSH插件，连接服务器。
3. /path/to/venv/bin/python -m django runserver 0.0.0.0:8000启动项目。
4. 在.vscode/launch.json中配置Python调试器，justMyCode设为false就能进入Django源码断点。

32位系统和64位系统、Python 3.8和3.12的兼容性问题，远比自己想象的更容易踩，所以如果你是在Windows上开发、Linux服务器上部署，务必确保两边Python大版本一致，否则装psycopg2或编译某些带C扩展的库时极易报错。

4.2 常用调试技巧：print大法之外，还要会用Logging和Django Debug Toolbar

给毕设项目做调试，我不建议一上来就学什么高深的pdb断点调试（当然会更好），最实用的其实是三步走：

1. 页面报错500：立刻去看终端输出的完整Traceback。90%的Django报错，最下面那几行就写明了是哪个文件、哪一行、什么类型的错误。这比瞎猜快得多。
2. 没有报错但数据不对：用print(request.user)、print(queryset.query)输出关键变量和SQL语句，确认数据是不是查出来了、查询条件是不是多了或少了。
3. 性能奇慢：安装django-debug-toolbar，通过侧边栏看SQL查询次数和页面渲染时间。优化一条逻辑让SQL从50次降到5次，这个素材写进文档里很加分。

有一个我强烈推荐的配置是让Django在开发环境输出所有SQL日志。在settings.py里加一段LOGGING配置，就能在终端看到每次ORM操作对应的原生SQL，这对排查N+1查询问题帮助巨大：

LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console': { 'level': 'DEBUG', 'class': 'logging.StreamHandler', }, }, 'loggers': { 'django.db.backends': { 'handlers': ['console'], 'level': 'DEBUG', }, }, }

4.3 把项目部署到Linux服务器的关键步骤：本地能跑只是第一步

很多毕设要求部署到服务器上演示，标题里涉及"python django 麒麟"这个热搜词，大概就是有人尝试在麒麟操作系统上部署Django项目。麒麟系统本质上是Linux的分支，Django部署思路和Ubuntu/CentOS大同小异，核心三步是：

• 用python manage.py check --deploy检查生产环境配置，重点看DEBUG=False、ALLOWED_HOSTS、SECRET_KEY、静态文件托管等。
• 用python manage.py collectstatic收集静态文件到指定目录，再用Nginx托管。
• 用Gunicorn或uWSGI启动Django服务，Nginx反向代理转发请求。

这里必须提醒一个新手极易出错的地方：不要在settings.py里写死ALLOWED_HOSTS = ['*']然后直接上生产，Django官方也建议显式列出域名或IP。而如果你在服务器上用了runserver而不是Gunicorn，虽然也能访问，但并发稍微高一点就会看到"Run the server with a production WSGI server"的警告，答辩演示时被问到就比较尴尬。

5. 文档撰写与答辩准备：代码会写，还要说得漂亮

5.1 毕业论文/设计文档的章节规划

毕设评分往往由三块组成：代码运行效果、论文/报告质量、答辩表现。很多技术不错的学生在论文上栽跟头，不是因为写得少，而是因为把论文写成了"用户手册"——大段贴代码、贴截图，没有分析过程。

一个结构比较稳妥的论文大纲是这样的：

• 绪论：研究背景与意义（慢病管理需求、中医食疗数字化）、国内外研究现状（国外营养管理App、国内中医健康平台）、研究内容与论文结构。
• 相关技术介绍：Python、Django框架、MTV模式、SQLite/MySQL、前端Bootstrap。
• 系统分析：可行性分析（技术、经济、操作）、需求分析（功能需求、非功能需求）、用例图。
• 系统设计：总体架构、功能模块设计、数据库设计（E-R图 + 表结构说明）。
• 系统实现：按模块展示核心代码和运行截图，并解释实现思路。
• 系统测试：功能测试用例表、测试结果、兼容性测试。
• 总结与展望。

这里说一个很多同学会忽略的点：每个模块的实现章节，不要只放代码，一定要配上"为什么这么实现"的文字说明。比如"为了减少重复代码，我把药膳筛选逻辑封装在ListView的get_queryset方法中"这样一句话，比大段贴代码得分高得多。

5.2 答辩高频问题与应答策略

答辩老师通常不会花时间细读代码，但会针对项目提出几个常规问题测试你是否真的理解自己的项目。我整理了食疗平台方向最常被问的问题：

• "为什么选用Django而不是Flask或Spring Boot？"
  应答要点：Django自带ORM、Admin、Auth，适合快速构建数据密集型业务系统；Flask轻量但需要额外集成大量组件；Spring Boot适合大型分布式的后端服务，对毕设体量来说偏重。
• "数据库表之间是什么关系？解释一下多对多是如何实现的。"
  应答要点：先讲表间关系（用户-收藏-药膳多对多，药膳-疾病多对多），再结合SQLite/MySQL里中间表的实际数据讲ManyToManyField或中间模型。
• "药膳的推荐逻辑是什么？"
  这是最核心的问题。如果你的项目只做了"按条件查询"，说实话，这不是真正的推荐。建议在答辩前至少做一个增强：在ListViews里增加"相似推荐"模块，逻辑可以很简单：当前药膳的疾病标签相同、体质标签相同的其他药膳，按标签重合数量排序。用一行annotate就能实现，但讲出来，"推荐算法"的格调一下就上来了。
• "系统安全性如何考虑？"
  至少提三点：用户密码使用Django默认的PBKDF2加盐哈希存储；登录接口可以集成django-simple-captcha做验证码防暴力破解；表单提交使用Django的CSRF防护。这三条足够证明你有安全意识。

5.3 讲解环节怎么演示最高效

远程讲解是这类带"讲解"服务的交付物里的重要环节。我的建议是，无论你是给自己讲，还是帮别人讲，一定要按这个顺序演示：

1. 先花30秒介绍项目背景和业务价值，别上来就打开代码编辑器。
2. 用普通用户身份演示整个核心流程：注册 → 登录 → 按疾病/体质筛选 → 查看详情 → 收藏 → 查看收藏。
3. 切到Admin后台，演示管理员维护药膳数据的流程，重点展示Admin里配置过的列表筛选、搜索、多对多选择器等增强功能。
4. 最后贴出项目结构目录，讲解MTV分层和核心数据表。
5. 全程控制在10分钟以内，多余的"炫技"内容（比如部署过程）放在QA环节再展示。

6. 经典坑位与经验复盘：这些坑值得刻在桌面上

6.1 迁移相关：为什么每次跑 migrate 都报错

我见过最多的报错是django.db.migrations.exceptions.InconsistentMigrationHistory和Field 'id' expected a number but got 'xxx'。

前者通常是因为在AUTH_USER_MODEL配置之前就执行过migrate。解决办法是如果开发的早期阶段发现这个问题，直接删掉数据库文件和migrations目录下除了__init__.py之外的所有文件，重新makemigrations和migrate。如果已经有大量数据不想删，那就用python manage.py migrate --fake appname zero重置指定App的迁移记录，再重新迁移，但这个操作比较危险，新手不建议尝试。

后者多数是类型转换问题，比如表单提交的ID在模板里被当成了字符串传给ORM，Django无法完成匹配。解决思路是先确认request.GET.get('id')的值，用int()转换后再传给filter(pk=id)。

6.2 模板与静态文件：图片显示不出来，样式全部丢失

在开发模式（DEBUG=True）下图片加载不出来，通常有两个原因：一是文件没上传到MEDIA_ROOT指定目录，二是配置文件里漏了MEDIA_URL或者访问路径没路由到文件。Django 4.x以上版本需要在urls.py里加这样一段：

from django.conf import settings from django.conf.urls.static import static urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

生产模式下，Media文件通常由Nginx处理，不再经过Django。很多人在本地开发时只配了STATIC_URL，忘了MEDIA_URL，导致上传后的图片路径能存库但访问不到，这个问题排查并不难，但如果不了解原理，很容易绕得很远。

6.3 时区与时间：Django里有个坑叫TIME_ZONE

在settings.py里，默认情况下TIME_ZONE是'UTC'，如果你不设成'Asia/Shanghai'，那么所有DateTimeField写入的时间都会与国际标准时间相同——比北京时间慢8小时。比较隐蔽的是，如果你只改了TIME_ZONE而忘了设置USE_TZ = False（或者反过来，使用了带时区的时间但数据库存储的是本地时间），在页面上显示的时间看起来没错，但后台查询范围时会发现边界情况出问题。

我的建议是：如果你的项目只用SQLite，直接把USE_TZ = False加上，所有时间用本地时间，省心且符合大多数中文毕设项目的演示需求；如果你要用MySQL，就保持USE_TZ = True，数据库里存UTC，渲染时由Django自动转成本地时间。关键是你得理解这层逻辑，答辩老师一问"时间是怎么处理的"就能答得上。

6.4 查询性能：N+1问题为什么是面试必问

药膳列表页如果展示每个方子的原文内容、封面、适用疾病列表，没注意查询优化的话一次页面请求会触发几十条SQL。这就是经典的N+1问题：先用一条SQL查出所有药膳，再在模板循环里逐条查相关的疾病与体质数据。解决办法很固定——用select_related和prefetch_related：

# select_related适用于ForeignKey一对一/多对一 # prefetch_related适用于多对多和反向关联 recipes = DietRecipe.objects.prefetch_related('categories', 'constitutions').all()

这两行代码写上去，SQL数量从几十条降到几条，页面加载速度肉眼可见地变快。我这个经验是在开发收藏排行榜功能时发现的，当时页面出现明显的卡顿，一查SQL日志才发现根本没有做预取。

6.5 新增功能时的扩展思路：比如加一个BMI体质测评模块

如果导师要求你加新功能，"健康测评"是非常推荐的扩展方向。做一个简单的"中医体质测评问卷"，用户在页面上回答十几个问题，系统根据答案统计得出体质类型，再推荐对应的药膳食谱。这个功能从技术上讲很简单：前端用表单提交，后端把答案按规则打分，最后的推荐逻辑还是查DietRecipe表。但从项目故事完整性上讲，"健康测评 + 食疗推荐"的闭环比单纯的"查菜谱"高出一个档次，论文的创新点也好写很多。如果你需要分阶段开发，建议把这个功能拆成三步：先做问卷页面和结果页，再做打分规则，最后把测试结果和食谱推荐打通。

7. 写在最后：这些经验是我踩过的坑换来的

这套Django食疗平台项目，我前前后后带过不少学生做类似的开发，从"数据库怎么设计"到"答辩讲什么"，完整的坑位基本都踩过一遍了。如果说只能给出一条建议，那就是：不要在环境配置上纠结超过两个小时。Python版本不兼容、Django安装失败、数据库驱动缺失、端口被占用，这些问题的解法网上搜一堆，但最有效的方法永远是找人远程帮你看一眼，或者换个干净的环境重来。很多同学在环境上耗了大半天，最后发现只是下载了一个过旧版本的依赖包，这种时间浪费太不值了。

另外一点，项目里代码能跑和答辩能过是两回事。答辩老师更看重的是你对"为什么这么设计"的回答，而不是你写了多少行代码。建议在开发过程中每个模块完成以后，顺手写一段技术说明，把你在这个模块踩过的坑和解决思路都记下来，最后写论文的时候你会感谢自己这个习惯。

如果后面有条件，这套项目还可以往移动端扩展——用Django REST Framework写一套API，前端用小程序的WebView或原生框架做壳，后端不用大改，核心食谱数据还是从同一个数据库读取。这个扩展方案我已经在几个进阶版定制需求里验证过了，工作量不算很大，但项目体感完全不一样。这篇分享里提到的代码片段和设计思路都可以直接用在你的项目里，有问题欢迎一起交流。