每年到这个时间点总有一批计算机专业的同学开始对着毕业设计题目发愁。前阵子有个同学私信我说题目是“基于Python的电脑配件商城的设计与实现”要求用Django或者Flask做后端前端用Vue开发工具是PyCharm。他一连问了好几个问题Django和Flask到底选哪个Vue学到什么程度够用商城系统要写哪些功能才能过答辩说实话这类全栈项目在毕业设计和课程设计中出现的频率极高因为它覆盖了Web开发的主流技术栈又贴近真实商业场景做完之后无论用于答辩还是写进简历都是很扎实的作品。这篇博文我就以这个题目为主线从技术选型、环境搭建、核心功能模块、前后端联调到高频问题和排查思路完整梳理一遍。内容以我实际开发这类项目的经验为基础兼顾Django和Flask两条技术路线你可以根据自己的情况选择一条走到底。无论是零基础起步还是已经会一点Python和前端照着这个思路走都能把一个能演示、能答辩的商城系统做出来。1. 立项之前电脑配件商城的技术选型与整体设计1.1 为什么前端选Vue后端在Django和Flask之间怎么选这个题目最核心的一个技术决策就是后端框架的选择。Django和Flask都是Python生态里非常成熟的Web框架但它们的定位和设计哲学差别很大。Django是一个“全家桶”式的重量级框架自带ORM、Admin后台、认证系统、表单处理、中间件机制等你不需要到处找第三方库按照它规定的模式写就能把一套系统搭起来。对于商城这种包含用户、商品、购物车、订单的系统Django的ORM能让你少写大量SQLAdmin后台更是可以直接用来管理商品分类和库存数据这在演示阶段是非常加分的功能。我见过不少用Django做毕设的人都把“使用Admin后台管理商品”作为系统的一个亮点来展示。Flask则是一个极简的微框架核心只有一个路由和模板引擎其他功能都靠扩展来实现。它更灵活你可以完全按自己的意愿组织代码结构。但这也是双刃剑——灵活意味着你自己要做很多决策比如ORM选SQLAlchemy还是Peewee表单验证用什么库用户认证自己写还是用Flask-Login这些都会消耗你的时间。Flask适合那种“我已经很清楚自己要什么”的开发者但对不熟悉Web架构的同学来说Django的上手曲线要平缓得多。我的建议是如果你的Python基础一般或者半年内只有零零散散的时间做项目优先选Django。它的“约定优于配置”能帮你减少掉坑的概率。如果项目要求中明确写了Flask或者你希望展示自己对代码结构的掌控能力也完全可以走Flask路线。两条路线我在下文都会给出具体的模块划分方式你可以对照着来。1.2 商城系统的核心模块拆解从需求到数据表拿到题目之后第一件事不是写代码而是把系统需要做什么拆清楚。电脑配件商城核心的业务链路是用户浏览商品、查看详情、加入购物车、生成订单、结算下单。围绕这条链路系统至少需要以下模块第一个是用户模块包括注册、登录、个人信息管理。登录状态可以用Token维持也可以用Session考虑到前后端分离的架构用Token更通用。第二个是商品模块包括商品列表、商品详情、商品分类、搜索。电脑配件类目很多比如CPU、显卡、主板、内存、固态硬盘、电源、散热器、显示器等做分类时要考虑如何组织这些层级。第三个是购物车模块包括添加商品、修改数量、删除商品、计算总价。第四个是订单模块包括生成订单、订单列表、订单详情、取消订单。第五个是后台管理模块按Django的做法就是Admin后台商品和分类的增删改查都放到这里。把这些模块映射到数据库核心的表就是用户表、商品表、分类表、购物车表、订单表、订单商品明细表。这几张表的字段设计如下用户表字段包括用户名、密码哈希、邮箱、手机号、创建时间商品表字段包括标题、图片、价格、库存、描述、所属分类、上架状态分类表字段包括名称、父级分类、排序购物车表字段包括用户、商品、数量订单表字段包括订单号、用户、总金额、状态、创建时间订单明细表字段包括订单、商品、单价、数量。表之间的关系不复杂用户和订单是一对多订单和商品是多对多但带数量字段分类和商品是一对多。这个阶段就把表和字段想清楚后面写models的时候就能顺很多。我习惯先画一个简单的实体关系图或者在纸上手写一遍字段名和类型再开始动手这一步骤能帮你避免后期反复改表结构的麻烦。1.3 环境版本选择Python、Node和数据库的搭配在正式动手之前先把开发环境确定下来。Python版本不用追新建议选Python 3.8到3.12之间的稳定版本。Django如果选4.2 LTS或者5.0版本对数据库和Python版本都有明确要求可以在官方网站上查到兼容矩阵。Flask的话3.0及以上版本没问题注意Flask 2.x和3.x的API基本兼容但一些扩展包要选择对应的版本。前端方面Vue 3是当前的主流版本搭配Vite作为构建工具会比旧版的Vue CLI快很多。需要确认你本机的Node.js版本在16以上最好用18或20的LTS版本否则Vite可能跑不起来。组件库方面Vue 3对应的是Element PlusVue 2时期用的Element UI不要装混了。这里经常有人踩坑下载了Element UI插到Vue 3项目里页面直接白屏。数据库推荐MySQL但不建议一开始就在MySQL里折腾。开发阶段用SQLite就够了Django和Flask-SQLAlchemy都支持无缝切换。等本地功能全部跑通再迁移到MySQL这样可以减少环境配置带来的干扰。当然如果题目本身要求必须用MySQL那就直接用注意在配置里设置好字符集避免中文乱码。2. 环境搭建与工程初始化一天内跑通前后端2.1 PyCharm下搭建Python虚拟环境与后端工程PyCharm社区版和专业版都可以用专业版对Web开发有一些额外支持但社区版做这个项目也足够了。新建项目的时候PyCharm会默认帮你创建一个虚拟环境这一步建议保留以后安装的所有Python依赖都装进这个虚拟环境避免污染全局环境。创建好项目之后在终端里安装依赖。Django路线就安装django和djangorestframework后续可能还会用到django-cors-headers、pillow、pymysqlFlask路线就安装flask、flask-sqlalchemy、flask-cors、flask-restful、pymysql。用pip安装建议加清华源加速。后端工程的目录结构无论Django还是Flask都应该按模块来组织。Django就按app划分用python manage.py startapp users生成用户模块再分别生成goods、cart、orders这些模块。Flask虽然没有强制要求但建议用blueprint蓝图划分模块一个模块一个Python文件或者一个包。初始化完成后首先要验证一条最简单的接口链路是否通。Django里写一个视图函数返回JSON数据配置好URL路由Flask里写一个app.route(/)返回JSON。跑起来之后用浏览器或Postman访问确认返回结果正常。这一步的意义是验证环境本身没问题当你后面遇到“莫名其妙跑不起来”的问题时可以快速判断是环境问题还是代码问题。2.2 Vue前端工程创建与Element Plus快速集成前端工程建议用Vite创建命令是npm create vitelatest frontend -- --template vue。创建完成后先用npm install安装基础依赖再安装路由、状态管理和UI组件库npm install vue-router4 pinia element-plus axios。Element Plus按需引入可以减少打包体积但为了方便新手入门我建议先全量引入在main.js里直接注册整个组件库等后期有优化需求再改。装完组件库之后先打印一个Hello World页面然后用Element Plus的el-button和el-input组件拼一个简单的登录界面。这一步能让你快速验证Vue生态是否正常运转同时也是一个心理上的“里程碑”——看到界面出来动力会足很多。前端项目的目录结构建议这样组织src/api放接口请求文件src/router放路由配置src/store放全局状态src/views放页面组件src/components放公共组件。这个结构是Vue项目的常见模式项目规模变大之后代码也不会乱。2.3 前后端联通的第一步CORS跨域配置前后端分离开发的第一道坎就是跨域。前端跑在81xx端口后端跑在80xx端口浏览器的同源策略会拦截前端的请求报错信息往往是Access to XMLHttpRequest ... has been blocked by CORS policy。Django解决跨域最省事的方式是装django-cors-headers在settings.py的INSTALLED_APPS里加上corsheaders在MIDDLEWARE中把CorsMiddleware放到尽可能靠前的位置然后设置CORS_ALLOW_ALL_ORIGINS True即可。开发阶段用这种全放开的策略是可以的但部署到正式环境时要把这个配置收紧改成具体的域名白名单。Flask解决跨域可以用flask-cors调用CORS(app)就能放开所有跨域限制。如果只想对特定路由开放写法稍微复杂一点但开发阶段没必要抠这个细节。我强烈建议在做任何页面之前先验证跨域配置。具体操作是在Vue项目里用axios向后端的一个测试接口发一个GET请求确认能在浏览器控制台看到返回数据。这一步通过了后面所有接口对接都只是重复这个模式。3. 核心功能设计与实操从用户到订单的完整链路3.1 用户注册登录Token认证与会话保持用户模块是商城系统入口没有登录态后面购物车和订单都无从谈起。在设计上前端提交用户名和密码到后端后端验证通过后返回一个Token前端把Token存在localStorage或Pinia里后续每次请求都在请求头带上这个Token后端通过校验Token识别用户身份。Django自带的django.contrib.auth管理用户非常方便配合Django REST Framework的TokenAuthentication可以在settings.py里注册认证类视图里加上authentication_classes和permission_classes就能实现。注册功能可以自己写一个视图接收用户名和密码调用User.objects.create_user创建用户这里要注意密码不能明文存储Django会自动用PBKDF2算法哈希。Flask路线没有现成的用户模型可以用Flask-SQLAlchemy定义User表密码用werkzeug自带的generate_password_hash和check_password_hash处理。Token方面可以用itsdangerous库生成带签名的序列化字符串也可以引入PyJWT生成JWT Token。这里我推荐用PyJWT因为JWT是行业通用标准后续如果要讲技术亮点JWT的身份认证机制比自定义Token更有说服力。登录功能还有一个容易被忽视的点验证码。如果你希望系统看起来更完整可以在登录页面集成一个简单的图形验证码。Django可以用captcha库Flask可以自己写一个生成图片的接口前后端效果都很好答辩时也能多一个可讲的点。3.2 商品列表与分类Django ORM查询与Vue组件化渲染商品列表页是整个商城最核心的展示页面。后端逻辑是接收分类ID、搜索关键词、页码这些参数从数据库查询商品数据按分页格式返回JSON。Django的ORM写起来比较顺手如果要实现搜索用Q对象组合多个查询条件分类过滤用filter(category_idxxx)分页可以直接用DRF自带的PageNumberPagination。Flask这边用SQLAlchemy的paginate方法或手动切片实现分页。前端商品列表页用Element Plus的el-card组件布局每个商品展示图片、标题、价格、库存状态。商品数据通过axios从接口拿拿到之后存在data里模板里用v-for循环渲染。这里要注意图片地址的处理——如果后端返回的是相对路径加文件名前端拼接时要找到完整的URL前缀。我的习惯是后端直接返回完整的可访问URL减少前端拼接时出错的概率。分类展示是一个容易忽略的体验细节。电脑配件的分类有两级大分类如CPU、主板、内存小分类如Intel平台CPU、AMD平台CPU。前端可以用el-tabs标签展示一级分类点击后再加载二级分类和对应商品。这种交互在演示时很出效果而且实现不复杂关键是后端要设计好分类表的父子关系。还有一个功能值得加上商品排序。按价格升序、降序、销量排序这类筛选逻辑在后端只有几行代码但能让页面显得功能完善。我一直建议在做这类项目时不要只做“能交差”的功能加一点真实电商常见的交互细节答辩时很加分。3.3 购物车与订单库存扣减与事务处理购物车模块在技术实现上有几种做法。最简单的是只存前端LocalStorage不调用后端接口正规一点的是把购物车数据同步到后端数据库用户切换设备时购物车数据不丢。考虑到项目答辩后一种更有技术含量。后端购物车表设计很简单一条记录就是一个用户加一个商品加一个数量。添加购物车接口先判断这条记录是否存在存在就累加数量不存在就新建。修改数量接口要更新字段删除接口就删记录。这里有一个细节每次操作后返回购物车的最新数据前端直接整体覆盖避免前端维护一个不同步的状态。这个模式我踩过不少坑还是后端返回完整购物车数据最省心。订单模块是整个系统里最需要技术严谨度的部分。生成订单时要做这几步校验商品库存是否足够从购物车选中的商品计算订单总金额创建订单记录创建订单明细记录扣减库存清空购物车。这里面任何一步失败都不应该让数据处于半更新状态所以必须用数据库事务包住这几步。Django里面用transaction.atomic()装饰器包住整个视图函数或者用with transaction.atomic():包住代码块Flask的SQLAlchemy用db.session.begin_nested()或者直接db.session.commit()之前抛异常db.session.rollback()。事务是答辩经常被问到的问题值得认真理解一下——为什么要事务不加事务会出现什么问题这些都要能说清楚。订单状态至少要设置几种待付款、已付款、已发货、已完成、已取消。状态变更可以用一个整数或字符串字段存储前端通过判断状态显示不同的操作按钮。3.4 后台管理Django Admin与自建管理页面的取舍后台管理是这个项目的隐藏加分项。坦白说很多学生不知道后台怎么处理最后只做了一个前台页面商品数据靠手动插入数据库这种项目演示时很容易被问破。Django的Admin后台只需要注册模型就能获得一个完整的后台管理界面。在admin.py里admin.site.register(Goods)然后把商品、分类都注册进去就能在后台直接添加商品、改库存、管理用户了。不要小看这一步它让你的系统闭环了——你不是靠SQL往里塞数据而是通过一个可视化界面在管理数据。答辩时说到“通过Django Admin后台对商品数据和订单数据进行管理”这本身就说明你理解了业务后台的价值。Flask这边需要自己写管理后台最简单的办法是做几个类似于前台页面的管理页面配上登录保护和增删改查接口。如果你选了Flask路线后台管理页面相当于多了一个小型CRUD项目工作量会增加一天左右。也可以只用SQLAlchemy写脚本插入初始数据但从项目完整度考虑我还是建议把管理页面写出来。4. 联调阶段的高频问题与排查实录4.1 前端拿不到数据从Network面板开始排查前后端联调过程中最常见的场景就是接口看起来写了前端也调了但页面上没有数据。排查的第一步永远是打开浏览器开发者工具的Network面板刷新页面看看对应的请求是什么状态。状态码200但是返回空数组一般是查询条件过滤掉了所有数据比如分类ID传错、关键词没有匹配项。状态码404是路由不匹配检查后端URL和前端请求路径是否一致。状态码500通常就是后端代码运行时报错了看后端控制台的具体报错堆栈直接定位到代码行。401和403是认证或权限问题检查Token有没有带上以及后端是否配置了对应的权限类。这里有一个很实用的排查技巧给后端的每个接口加日志输出打印接收参数和返回结果。Django可以用loggingFlask可以用app.logger。每次前端调用接口后端日志都能看到参数内容问题往往一目了然。调试完再把日志级别调回去不必删掉代码。我遇到过很多次前端传参和后端接收不一致的情况原因就是字段名一个用productId一个用product_id。在写接口文档时统一命名风格可以避免这类无意义的排错时间。4.2 数据库与ORM操作中的经典坑第一个经典坑是外键关联查询时出现的RelatedObjectDoesNotExist错误。购物车和订单明细都涉及关联查询如果外键字段没有值或者关联的对象被删除了查询时就会报错。处理方式是在模型定义时就设置好外键的on_delete行为商品删除时购物车记录是级联删除还是置空都要提前想清楚。第二个经典坑是批量插入或更新数据时的N1查询问题。列表页渲染时如果每一条商品都查询一次分类名称数据库会扛不住。Django里用select_related或prefetch_related优化查询SQLAlchemy里用joinedload或selectinload都能一次性把关联数据查出来。这个点如果能在答辩时讲出来是很加分的技术细节。第三个经典坑是删除对象时的外键约束。在执行Goods.objects.delete()时如果订单明细表里有记录引用这个商品删除操作会失败或者级联删除订单数据。正确的做法是商品表加一个“是否上架”的状态字段需要下架的商品改状态而不是物理删除。这也是真实业务系统的标准做法用软删除代替物理删除能保住历史数据的完整性。4.3 图片上传与静态资源管理的配置细节商城系统的商品必须有图片这一步也是容易出问题的地方。Django的图片字段用ImageField需要安装Pillow库并在settings.py里配置MEDIA_ROOT和MEDIA_URL。开发阶段还要在urls.py里加一个静态文件服务路由否则前端根本访问不到上传的图片。Flask这边用request.files接收上传文件保存到static/upload目录然后返回文件的访问URL。图片上传还有一个隐藏坑前端FormData的字段名必须和后端接口的参数名一致否则上传接口接收不到文件。除此之外图片的尺寸和格式建议做一下校验防止用户上传超大图片导致页面加载缓慢。上传成功之后要验证返回的URL能不能在浏览器直接访问很多404问题都是因为漏配了静态文件服务。4.4 部署与打包Localhost跑通之后怎么办如果你只需要本地演示那前面这些就够用了。但有些学校要求能远程访问或者你自己想把项目部署到服务器上给亲戚朋友看看那就涉及打包部署。前端Vue项目执行npm run build生成的dist目录包含了所有静态文件。后端部署方案有很多简单方式是把dist目录放到后端项目里Django配好静态文件收集用python manage.py runserver 0.0.0.0:8000跑起来Flask则直接用app.run(host0.0.0.0, port5000)。这种方式适合演示但不适合高并发。想正式一点就上Nginx加GunicornNginx处理静态文件请求和反向代理Gunicorn跑Python后端。Vue路由如果用了history模式Nginx还需要配置try_files否则刷新页面会404这是一个经典坑我见过不少人拿这个问题来问我。5. 我做这个项目的几个经验总结5.1 先做通一条链路再横向扩展我每次做这类全栈项目都坚持先做通一条完整链路从商品列表到商品详情再到加入购物车、生成订单。哪怕这条链路的页面很简陋但它证明了整个系统架构是通的。之后加用户系统、后台管理、搜索功能都是在已验证的骨架上填充内容不会出现做了半天发现基础方向错了的情况。5.2 版本管理和备份习惯要提前养成代码写到第三天你就会体会到Git的好处了。每完成一个功能模块就提交一次配合远程仓库即使本地代码出了不可恢复的问题也能随时回退。很多同学不习惯用Git到最后论文要交了才发现代码改坏了浪费大量时间。花二十分钟把Git基础命令学会是整场开发里回报率最高的一笔时间投资。5.3 答辩和技术文档要最后再整理项目做完之后先把代码跑一遍全流程截图存好再开始写论文或技术文档。文档里的架构图、功能描述、核心代码讲解都应该从你已经实现的代码里来不需要编或者凑。我当时是先跑通了所有功能再做了一次完整录屏然后写文档的时候就非常快了。不推荐一边开发一边写文档因为开发过程中方案会变文档要跟着改效率反而低。按照这个路线从头到尾把电脑配件商城做出来一周多的课余时间是足够的。如果你现在正好在准备这个题目就按“先链路、后模块、再优化”的顺序推进。遇到问题不要慌对照第四部分的常见问题去排查大部分坑都是能绕过去的。