插画鲜花商城系统听名字就能猜个大概——用户端是一个走插画视觉风格的花店商城可以浏览花束、下单买花管理端是常规的商品、订单、用户管理。这类项目在Django毕设里属于典型的全栈电商平台型题目覆盖了用户认证、商品展示、购物车、订单流转、后台管理这些核心链路工作量适中又有足够的展示点。我帮过不少同学调试这类项目坦白讲大部分代码都能跑通但真要说得清楚为什么这么设计往往需要把整个MVT流程、数据库关系、会话状态串起来讲明白。这篇文章就围绕基于Django的插画鲜花商城系统这个题目展开把项目里的核心设计、关键代码、实战踩坑、调试与定制经验一次讲透适合正在做类似毕设的同学也适合想用一个完整案例入门Django全栈开发的读者。1. 项目定位与整体思路为什么选Django做插画鲜花商城1.1 毕设选题的核心考量每年到毕设季选题无非那么几类管理系统、内容网站、移动端小程序、数据处理平台。电商商城类一直是热门因为它的业务链条完整——从用户注册登录到商品浏览、加购、下单、订单查看再到后台的商品维护和订单处理每一个环节都能在系统里找到对应的功能和代码位置写进论文里也有清晰的业务模块图、流程图、时序图可以画。而插画鲜花这个前缀不是随便加的它把项目从通用商城模板变成一个有明确视觉主题和消费场景的作品答辩时也更容易讲出设计感。选Django做这个题目核心原因是它的开发效率和对初学者友好程度。Django自带Admin后台意味着商品管理、分类管理、订单管理这些功能在项目初期就能快速搭建出一版可用的界面自带ORM不用手写SQL就能完成大部分查改增删自带用户认证体系session、login、logout都封装好了。对毕设来说时间紧、要求又要有深度Django的约定优于配置思路能让你把精力集中在业务逻辑而不是底层基建上。1.2 商场系统的业务需求拆解把一个插画鲜花商城当成一个真实业务来分析先别急着写代码把用户故事理清楚。普通用户进到商城第一件事是浏览首页看到轮播图、热门花束、分类入口点进分类页按玫瑰百合绿植这些标签筛选再点开商品详情看价格、库存、插画风格的实物图。看中了就加入购物车购物车里可以调整数量、删除商品结算时要填收货地址生成订单。因为电商系统在毕设里一般不会真的接支付网关所以用模拟支付的方式处理点击立即支付后订单状态从待付款变成待发货。管理员登录后台可以新增、编辑、下架商品修改库存发货后订单状态再推进到待收货、完成。从这套业务流里提炼出核心功能模块用户模块、商品模块、分类模块、购物车模块、订单模块、后台管理模块。这也是大多数毕设商城系统的标准结构。模块之间不是孤立的商品和分类是一对多关系订单和用户是多对一关系订单和订单明细是一对多关系购物车则是用户会话期间的一种临时数据载体。把这些关系想明白数据库设计就成功了一大半。1.3 技术栈与工程目录规划我建议的技术栈是这样Python Django 4.x数据库本地开发用SQLite部署演示时换MySQL也没问题前端用Bootstrap加自定义CSS配合插画风格的图片素材不追求复杂的前后端分离数据交互用Django模板渲染为主购物车操作可以用jQuery发异步请求提升体验。这样整一套下来技术选型既稳又能在文档里写出合理的理由。工程目录上我习惯按功能模块建app而不是把所有视图堆在一个views.py里。建议拆成users、goods、cart、orders、admin_ops这几个app每个app下面都有自己的models、views、urls。这样代码结构一目了然论文里画系统架构图时也方便标注表现层—业务层—数据层的对应关系。注意Django自带的admin其实已经承担了很大一部分后台管理职责可以基于它定制而不是另建一套后台。提示毕设项目最怕的是能跑但是讲不清。目录结构清晰后面写论文、做答辩PPT、应对老师提问都会省力很多。规划工程结构本身就在帮你想清楚系统边界。2. 数据库模型与核心功能模块设计2.1 从业务对象到数据表数据库设计我习惯先从实体入手再把关系转化成模型字段。这个项目里最主要的实体有用户、分类、鲜花商品、购物车记录、订单、订单明细、收货地址。用户可以直接用Django内置的User模型扩展也可以用AbstractUser写一个自定义用户表我会推荐后者因为可以顺手加上手机号、头像、昵称这些字段后面扩展登录方式也方便。分类和商品就是标准的一对多。商品模型里除了名称、价格、库存、描述、封面图还要注意业态细节鲜花有花语适用场景这类特色字段插画主题的商品还需要有风格标签。你把字段设计得越贴合业务答辩时越有话说。购物车在这个项目里我建议用session实现因为匿名用户也能加购。每次请求时把购物车字典存到request.session里关联的商品数据则到数据库实时读取避免session里存了过期的价格和库存。这是一种很实用的权衡轻量、无需建表、代码简单非常适合毕设阶段的演示效果将来要升级成登录后购物车跨设备同步再考虑建表也不迟。订单这块必须有主表和明细表。订单主表记录订单号、用户、总金额、状态、收货人信息订单明细表记录每条商品的ID、购买数量、成交价格。之所以拆两张表是为了保证订单历史快照的完整性——商品后来涨价、下架甚至被删掉都不影响已经生成的订单内容。这是电商系统里非常重要的设计原则。2.2 用户与商品模块的落地细节用户模块看起来简单但细节里藏着不少考点。注册时要做表单校验比如用户名长度、密码强度、两次密码是否一致注册成功后自动登录并跳转回首页。登录后要能在导航栏显示当前用户昵称。个人中心里展示历史订单列表还可以扩展修改收货地址编辑个人资料这些小功能。这些功能用Django的auth视图和表单类来做代码量不大但是能体现你对框架内置能力的掌握程度。商品模块的展示链路是视图从数据库取数据上下文传给模板模板渲染成页面。首页除了默认推荐商品还要做分类导航商品列表页要支持按分类过滤、按价格排序、搜索关键词商品详情页除了基本信息还要做相关推荐可以简单取同分类下的其他商品。搜索建议用Django ORM的icontains实现LIKE模糊查询支持输入玫瑰匹配到玫瑰花束。插画风格的视觉呈现是这个项目的加分项。模板里可以做一个大的视觉风格基调比如柔和的粉色调背景、圆角卡片、手绘风的轮播图、统一的卡片悬停效果。加上这种设计之后系统从练手demo变成了有设计理念的作品。答辩时你甚至可以把插画风格的UI设计作为一个章节来写和系统功能设计并列。2.3 购物车、订单与支付模块的核心逻辑购物车用session实现的思路我在2.1里提过这里展开说一下数据结构。session里存的是一个字典key是商品ID字符串value是数量加价格加名称的子字典。加购时要判断商品是否还在售、库存是否充足购物车页面要展示每一件商品的小计和购物车总价修改数量要考虑库存上限同时更新session。如果某些商品的库存已经为零要给用户明显提示并在结算时把这些商品过滤掉。这种边界处理往往是代码里容易漏、但答辩评委容易问到的点。订单生成是整个系统最核心的一段逻辑。我从一开始就在订单创建成的同一段逻辑里做库存扣减而不是等支付完成再扣因为毕设项目的并发量几乎为零这种处理方式最简单可靠。订单状态建议用一个小状态字段来存pending待付款、paid待发货、shipped待收货、completed已完成、cancelled已取消。每次状态变更都只做一次简单的update同时给用户展示状态流转的进度条这个交互非常加分。支付模块在毕设中一般建议做模拟支付——点击支付按钮后弹一个确认窗口显示订单金额点击确认后跳转到支付成功页面同时把订单状态置为待发货。这里的关键是让流程完整让老师看到你理解了支付环节在业务流中的位置。如果想写得更有亮点可以引入第三方支付沙箱环境来对接真实支付接口流程但注意要提前确认学校是否接受这种方式以及接口调试的时间成本。供应商选择上稳妥优先功能演示顺畅比炫技更重要。3. 关键代码实现与细节解读3.1 商品展示视图、路由、模板的MVT联动前面把设计思路说清楚了这一节直接给能落地的代码并且讲清楚每一段在整条链路里的位置。先看商品模型我用的是自定义用户模型和商品分类、商品实体的组合# users/models.py from django.contrib.auth.models import AbstractUser class User(AbstractUser): nickname models.CharField(max_length50, blankTrue, verbose_name昵称) phone models.CharField(max_length11, blankTrue, verbose_name手机号) avatar models.ImageField(upload_toavatars/, blankTrue, verbose_name头像) class Meta: verbose_name 用户 verbose_name_plural 用户# goods/models.py from django.db import models class Category(models.Model): name models.CharField(max_length50, verbose_name分类名称) sort_order models.IntegerField(default0, verbose_name排序) class Meta: verbose_name 商品分类 verbose_name_plural 商品分类 def __str__(self): return self.name class Flower(models.Model): name models.CharField(max_length100, verbose_name花名) category models.ForeignKey(Category, on_deletemodels.CASCADE, related_nameflowers, verbose_name所属分类) price models.DecimalField(max_digits8, decimal_places2, verbose_name价格) stock models.PositiveIntegerField(default0, verbose_name库存) cover models.ImageField(upload_toflowers/, verbose_name封面图) style_tag models.CharField(max_length50, blankTrue, verbose_name插画风格标签) description models.TextField(blankTrue, verbose_name商品描述) is_on_sale models.BooleanField(defaultTrue, verbose_name是否上架) created_at models.DateTimeField(auto_now_addTrue, verbose_name创建时间) class Meta: verbose_name 鲜花商品 verbose_name_plural 鲜花商品 ordering [-created_at] def __str__(self): return self.name模型字段命名尽量语义化这对后面写Admin列表页、写查询逻辑都有好处。价格用DecimalField而不是FloatField是为了避免浮点数导致的金额精度问题属于电商项目里很基础但容易忽略的细节。视图层面商品列表的经典写法是按分类过滤使用这样的逻辑def product_list(request, category_idNone): category None products Flower.objects.filter(is_on_saleTrue) if category_id: category Category.objects.filter(idcategory_id).first() products Flower.objects.filter(categorycategory, is_on_saleTrue) keyword request.GET.get(keyword, ) if keyword: products products.filter(name__icontainskeyword) sort request.GET.get(sort, default) if sort price_asc: products products.order_by(price) elif sort price_desc: products products.order_by(-price) paginator Paginator(products, per_page9) page_number request.GET.get(page) page_obj paginator.get_page(page_number) context { page_obj: page_obj, category: category, keyword: keyword, sort: sort, } return render(request, goods/product_list.html, context)这段代码把分类过滤、搜索、排序、分页都合并到了一个视图里逻辑清楚模板只要处理一个page_obj对象即可。注意查询集的惰性特性——所有的filter都是链式叠加真正执行query是在模板渲染时所以不要担心多次filter会造成性能问题这个量级的项目完全够用。分页用的Paginator是Django自带功能在模板里渲染页码链接只需要几行代码。3.2 购物车与下单的核心逻辑实现购物车这块我用session方案具体功能拆成加购、改数量、删除、结算四个动作。加购和改数量使用JsonResponse返回给前端前端用jQuery的ajax请求这样页面不用刷新体验更接近真实电商。看核心代码# cart/views.py from django.http import JsonResponse from django.shortcuts import redirect from django.views.decorators.http import require_POST def add_to_cart(request, flower_id): flower Flower.objects.filter(idflower_id, is_on_saleTrue).first() if not flower: return JsonResponse({code: 404, msg: 商品不存在或已下架}) cart request.session.get(cart, {}) key str(flower.id) if key in cart: cart[key][count] 1 else: cart[key] { name: flower.name, price: str(flower.price), count: 1, } request.session[cart] cart return JsonResponse({code: 0, msg: 已加入购物车, count: cart[key][count]}) require_POST def update_cart_item(request, flower_id): cart request.session.get(cart, {}) key str(flower_id) if key not in cart: return JsonResponse({code: 404, msg: 购物车中不存在该商品}) try: new_count int(request.POST.get(count, 0)) except ValueError: new_count 0 flower Flower.objects.filter(idflower_id, is_on_saleTrue).first() if not flower or new_count 0: cart.pop(key, None) elif new_count flower.stock: cart[key][count] flower.stock else: cart[key][count] new_count request.session[cart] cart return JsonResponse({code: 0, count: cart[key][count] if key in cart else 0})这里有几个细节值得注意修改数量时不能只更新session必须先去数据库核对最新库存如果用户把数量改成0或负数就应该从购物车里移除商品下架后在加购接口里要直接拦截。判断是否下架这件事很多初写者会漏但实际业务里商品会有上下架的变更不拦截会导致用户把一个已经下架的鲜花加进购物车后面结算出错。下单逻辑是重点业务流程依次是确认登录状态、检查购物车非空、去数据库核验每件商品的库存、扣减库存、创建订单主表与明细表、清空购物车。订单号的生成不能用数据库自增ID直接给用户看一般会拼上日期和随机串比如20250601加六位随机数保证可读性和唯一性。def create_order(request): if not request.user.is_authenticated: return redirect(login) cart request.session.get(cart, {}) if not cart: return redirect(index) total Decimal(0.00) order Order.objects.create(userrequest.user, statuspending) for key, item in cart.items(): flower Flower.objects.filter(idint(key), is_on_saleTrue).first() if not flower or flower.stock item[count]: continue flower.stock - item[count] flower.save() OrderItem.objects.create( orderorder, flower_nameflower.name, flower_coverflower.cover, priceflower.price, countitem[count], ) total flower.price * item[count] order.total_amount total order.order_no f{timezone.now():%Y%m%d%H%M%S}{random.randint(1000, 9999)} order.save() request.session[cart] {} return redirect(order_detail, order_idorder.id)订单明细里直接冗余了flower_name、flower_cover、price这几个字段这是刻意做的目的就是保留下单时刻的快照信息。订单列表和详情页里不再关联查询商品表一张历史订单在商品改名或删除后依然能显示完整内容。3.3 后台管理定制与插画视觉风格后台管理不需要从零开始渲染Django自带admin可以覆盖大部分需求。在admin.py里通过list_display、list_filter、search_fields来定制列表页用fieldsets来分组编辑页。鲜花商品管理尤其需要列表页直接看到封面图缩略图这可以用一个自定义方法实现from django.contrib import admin from django.utils.html import format_html admin.register(Flower) class FlowerAdmin(admin.ModelAdmin): list_display (cover_preview, name, category, price, stock, is_on_sale, created_at) list_filter (category, is_on_sale) search_fields (name,) list_editable (price, stock, is_on_sale) def cover_preview(self, obj): if obj.cover: return format_html(img src{} styleheight: 50px; /, obj.cover.url) return 无图 cover_preview.short_description 封面一定要注意模板里展示图片时实际引用的是MEDIA_URL拼接文件名的路径也就是Django在本地开发环境中通过urlpatterns配置来serve这些用户上传的文件。settings里必须把MEDIA_URL和MEDIA_ROOT配好开发的urls里再把media目录当作静态资源暴露出来。这一步是我见过的最常见的配置遗漏后面专门写一节排坑。前端视觉方面我建议做一个统一的模板基座。具体做法是在base.html中定义导航栏、页脚、内容块首页和列表页引用同一套插画风格的CSS变量——主色调、卡片圆角、阴影、按钮样式都集中定义。页面整体营造一种有设计感的品牌花店的感觉而不是默认的无样式白底页面。做到这个程度并不需要写大量复杂CSS定义几个全局变量、统一卡片和按钮的class视觉质感就会明显提升。4. 毕设实战避坑指南与远程调试实录4.1 静态文件404与图片上传路径这个坑在Django项目里几乎人人都会踩一遍尤其到了演示阶段页面打不开、图片显示成裂图场面非常尴尬。先说本质Django的开发服务器默认只关注urls.py里的路由静态文件CSS、JS、图片和上传文件用户传的商品图、头像都是外挂资源需要在配置里显式指明从哪里去找。settings.py里两手都要硬STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media然后在项目的根urls.py里把MEDIA路径挂到路由上只适用于开发环境from django.conf import settings from django.conf.urls.static import static urlpatterns [...] if settings.DEBUG: urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)如果你把DEBUG改成False做上线演示静态文件的服务方式就变了需要先执行collectstatic把静态文件收集到STATIC_ROOT目录然后让web服务器去托管这些文件。很多同学在本地开发时一切正常一关DEBUG就白屏十有八九就是这个原因。我给的建议是本地调试阶段保持DEBUGTrue和上面的配置演示时如果想不开Debug模式再单独配一个能standalone跑起来的方式比如用Django的runserver加静态托管中间件或者使用白噪声库。这个一定要提前演练不要在演示现场翻车。4.2 数据库迁移、中文乱码与依赖版本问题先来说依赖版本这个最隐蔽的坑。Django生态里普遍存在的一个问题是某些第三方库版本对Python版本和Django版本有明确的兼容要求。比如某同学环境里Python 3.12配合旧一点的Django 3.2再安装某个旧版本数据库驱动很可能出现ModuleNotFoundError或者AttributeError。我处理过不少这种案例基本都是版本不匹配导致。所以项目开始时就把requirements.txt固定住关键版本别装最新版要装稳定版。我用过一套比较稳的组合Python 3.10、Django 4.2、django-simple-captcha按需安装、Pillow处理图片字段。这个组合在主流系统下兼容性都很好。数据库迁移的坑集中在第一次makemigrations和migrate时。常见的有三种一是改了模型字段但忘了生成迁移文件运行时直接报no such column二是改字段时有数据残留迁移报错让你给新字段设置默认值三是自定义用户模型没有在第一次migrate前就配置好AUTH_USER_MODEL导致后续改起来特别麻烦。针对第三种我特别提醒如果你打算用AbstractUser自定义用户要在项目的settings里配置成AUTH_USER_MODEL users.User并且最好在一开始迁移数据库之前就配置好。项目跑了一半再回头换用户模型Django底层表结构会乱掉。中文乱码问题现在其实比以前少多了主要会在两个位置出现一是数据库默认编码不是utf8mb4写入中文会变问号或者报错二是Windows控制台打印日志时中文乱码看着头晕但功能不受影响。SQLite默认就是UTF-8一般没事如果你用了MySQL建库时指定字符集为utf8mb4即可。这个坑不算大问题但卡住的时候也挺闹心。4.3 远程调试的实用技巧远程调试这个提法在不同人嘴里意思不太一样。有的是指远程协助看报错有的是指远程连服务器部署。对于毕设项目来说最常见的其实是两个人一个在写一个在看的协作场景。这种协作下效率最高的不是反复截图发来发去而是让写代码的人先自己搭出一套标准的排错流程先看浏览器F12开发者工具的Console和Network有没有报错再看终端里Django的完整Traceback最后看关键变量的上下文。把报错信息完整截下来哪怕自己看不明白发给帮忙的人也能立刻定位而不是丢一句我这边显示404就没了下文。日志是调试的好帮手很多你肉眼看不出来的问题日志里都有答案。在视图函数的关键路径上用Python的logging打点比如打印接收到的POST参数、查询到的商品对象、库存值、session内容跑一遍流程再看日志逻辑漏洞一眼就能看出来。我在远程调试时最常用的一招就是让对方在出问题的视图函数里加一条print(request.POST)和print(request.session.get(cart))看数据到底长什么样很多为什么计算结果不对的诡异问题都是因为数据本身不符合预期。注意远程调试时不要急着改代码先确认用户的真实操作路径。我有一次帮某同学排查购物车总数不对的问题看代码完全正常最后才发现他每次测试都开了两个浏览器标签页session不是同一个所谓的bug其实是操作方式导致的。定位问题前问清楚操作流程能省一半时间。4.4 常见问题速查表我把这几年Django毕设里出现频率最高的十来个问题整理成了一张表按照现象—原因—解法的结构写以后遇到类似问题可以先查表再上网搜现象常见原因解决办法静态文件404STATICFILES_DIRS未配置或路径错误检查settings确认static目录放在BASE_DIR下上传图片不显示MEDIA_URL未挂到urlpatterns在根urls.py添加static(settings.MEDIA_URL)DEBUGFalse后白屏静态文件未collect执行collectstatic并正确配置STATIC_ROOT改模型后报no such column没有makemigrations执行makemigrations然后migrate自定义用户模型迁移报错项目初始化后才配置AUTH_USER_MODEL新建项目时第一时间配置该参数图片上传字段报错没装Pillowpip install Pillow中文写入MySQL变问号数据库字符集不对建库时指定utf8mb4购物车刷新就丢用了request.GET没保持session确认写入request.session并调用session.save订单金额小数精度错FloatField存价格价格改用DecimalField分页页码点击无效链接没拼接查询参数模板分页链接保留keyword与sort参数后台没有模型未注册admin在admin.py中用site.register注册迁移时提示依赖冲突第三方库版本不兼容固定requirements版本重建虚拟环境这张表不是让你背下来而是告诉你排查的思路。大多数问题的共性在于先分清楚是配置问题、数据问题还是代码逻辑问题再针对性地看对应层级的线索会比漫无目的试要快得多。5. 定制化扩展方向与毕设答辩讲解思路5.1 结合热点需求做功能增量毕设做到基础功能全通只是及格想拿高分就得有增量亮点。增量不必追求大而全关键是和主题契合、能体现你的设计思考。插画鲜花商城这个主题我推荐几个常见的扩展方向难度有梯度第一个方向是内容化运营。加一个花语故事或者插画灵感的文章模块管理员可以在后台发布图文前台展示成类似博客的栏目。这样商城就不只是一个交易系统还有了内容沉淀能体现你对电商内容生态的理解。第二个方向是营销工具。比如优惠券系统——后台创建满减券用户领券下单时自动抵扣或者限时秒杀——某个时间段内某款花束显示秒杀价。这两个功能都和订单流程深度耦合要动下单逻辑、订单明细的价格展示、后台的管理入口代码量和思考量都够是很好的加分项。第三个方向是视觉与交互升级。比如商品详情页增加多图轮播、在模板里用CSS动画做卡片悬停效果、购物车增加同价换购推荐。这些不用动后端核心逻辑适合想往前端方向展示能力的同学。第四个方向是数据化。做一个简单的后台统计页面展示每日订单量、销售额、热销商品Top10用Chart.js画几张折线图、柱状图数据来源就是订单表按日期聚合查询。这个扩展能让项目看起来更有分析价值论文里把E-R图一摆、统计图一贴实证性就出来了。选择扩展方向时我做提醒优先选择与已有代码能复用、逻辑链条顺的不要为了亮点硬接一套新技术栈给自己挖坑。一个增量的完成度和稳定性比三个半成品的亮点更有说服力。5.2 答辩时怎么把逻辑讲清楚毕设答辩和代码演示完全是两回事。代码里你可以靠搜索定位到某个函数但答辩讲的是整体逻辑线。我见过太多同学一紧张就开始念代码评委听得一头雾水。正确的方式是围绕一句话主线展开用户从注册开始经过浏览、加购、下单、支付订单状态逐步变化管理员在后台处理订单并推进状态。这条用户旅程就是整个答辩的串联线索。讲解时建议先画一张简单的系统功能结构图把用户端和后台管理端分开标注然后用一张数据库关系图讲清楚模型之间的关联关系讲的时候顺便解释订单和明细为什么要拆两张表——能被问到的高频问题反正我在评审时一定会问这个。最后演示环节要提前备好测试账号和测试数据避免现场注册、现场手动输入一堆商品信息的尴尬。演示时从首页到下单全流程走一遍中途可以适当点开后台看商品管理不用每个功能都点一遍但要让评委看出后台确实能管理数据。容易被问到的问题提前准备答案为什么session存购物车、订单状态是怎么流转的、库存是什么时候扣的、怎么保证订单金额和明细一致、为什么Django适合这个项目、迁移到MySQL要改哪里。遇到不会回答的问题不要强行编如实说这块当时没有深入做然后补一句如果继续扩展我的思路是会怎么做反而比瞎编加分。5.3 我的几点实操体会带过不少同学跑完整个流程我发现最后能高分通过的人都有一个共同点他们不是把所有代码写完再一次性总结而是每完成一个模块就自己讲一遍这个模块的流程把自己当作答辩评委来提问。比如写完订单模块就问自己如果老师让我说明库存和订单的一致性我怎么回答这个问题想明白了代码逻辑本身也会更清晰。资源整理方面做毕设时一定要把文档和代码分开管理。文档除了需求分析、概要设计、数据库设计、核心功能实现、测试这几个固定章节外最好还保留一个开发日志记录每天做了什么、遇到什么问题、怎么解决的。这个日志不一定要交给老师但对写论文、排错、答辩都极有用而且能防止时间一长自己忘了当初的思路。最后再说一点关于项目文件结构的体会。把整套源码加文档组织成一个干净的目录顶部放README写明环境版本、启动步骤、测试账号、功能清单下面按app分目录放代码docs目录放需求文档和设计文档。这个习惯一是方便老师审阅二是将来找工作放项目集时也能直接用一举两得。我见过太多在答辩前几天还在从聊天记录里翻代码的同学那种压力完全没必要。项目做完的时间线至少要提前两周留一周做功能和演示数据完善留一周专门做文档与答辩演练从容地收尾效果一定比最后通宵赶出来好很多。