摘 要
针对高校快递代取服务中存在的流程不规范、信息不对称与管理效率低下等问题,设计并实现了一款结合Django后端与微信小程序前端的校园快递代取应用。平台面向学生用户、跑腿用户及管理员三类角色,构建涵盖任务发布、接单处理、订单支付、站点展示、通知公告、财务记录及异常反馈等完整业务流程。后端采用Django框架配合MySQL数据库,实现数据持久化与权限控制;前端依托微信小程序,提供轻量、便捷、跨平台的操作体验,支持扫码登录、消息提醒与实时状态更新。通过功能测试与性能验证,整体应用在多用户并发场景下运行稳定,事务处理准确,响应时间满足校园日常使用需求。实践表明,该方案有效提升了快递代取服务的组织化水平与交互效率,为校内生活服务类应用提供了可行的技术路径与实施参考。
关键词:Django;微信小程序;校园服务;快递代取;任务匹配;
Abstract
To address issues such as non-standardized processes, information asymmetry, and low management efficiency in campus express delivery pickup services, a campus express delivery pickup application was designed and implemented, combining a Django backend with a WeChat Mini Program frontend. The platform caters to three types of users: students, delivery runners, and administrators, and establishes a comprehensive business process covering task posting, order handling, payment processing, station display, notifications, financial records, and exception feedback. The backend employs the Django framework alongside a MySQL database to achieve data persistence and permission control, while the frontend leverages WeChat Mini Program to provide a lightweight, convenient, and cross-platform user experience, supporting features like QR code login, message alerts, and real-time status updates. Through functional testing and performance validation, the application demonstrates stable operation under multi-user concurrent scenarios, accurate transaction processing, and response times that meet daily campus usage requirements. The practice shows that this solution effectively enhances the organizational level and interaction efficiency of express delivery pickup services, offering a feasible technical pathway and implementation reference for campus life service applications.
Keywords: Django; WeChat Mini Program; Campus Services; Parcel Pickup; Task Matching;
目 录
摘 要
Abstract
一、绪论
(一)研究背景
(二)研究意义
(三)研究现状
1.国内研究现状
2.国外研究现状
二、相关技术介绍
(一)Django框架
(二)Python语言
(三)MySQL数据库
(四)微信小程序
三、系统分析
(一)系统可行性分析
1.技术可行性
2.经济可行性
3.操作可行性
(二)系统功能性分析
1.用户功能需求分析
2.系统性能需求分析
(三)系统用例分析
1.学生用户用例分析
2.跑腿用户用例分析
3.管理员用例分析
四、系统设计
(一)系统架构设计
(二)系统功能模块设计
(三)系统流程设计
1.用户登录流程分析
2.用户注册流程分析
3.信息添加流程分析
4.信息修改流程分析
5.信息删除流程分析
(四)系统流程设计
1.数据库概念结构设计
2.数据库表结构设计
五、系统实现
(一)前台用户注册登录功能实现
(二)学生用户功能实现
1.首页界面
2.我的界面
3.快递站点界面
5.任务大厅界面
(三)跑腿用户功能实现
1.我的界面
2.任务大厅界面
(四)后台管理员功能实现
1.首页界面
2.快递站点管理
3.充值记录管理
4.提现记录管理
5.支付记录管理
6.系统管理
8.通知发布
六、系统测试
(一)测试目的
(二)测试用例
1.系统功能性测试用例
2.系统性能测试用例
(三)测试结果
七、总结与展望
参考文献
致 谢
一、绪论
(一)研究背景
近年来,高校在校生规模持续扩大,校园内快递业务量迅猛增长。尤其在“双十一”“618”等购物节期间,快递站点常常人满为患,取件排队时间长、包裹查找困难等问题日益突出。与此同时,学生课业繁重、时间碎片化,难以兼顾日常学习与生活事务,对便捷高效的代取服务需求不断上升。然而,当前校园内的代取行为多依赖于非正式渠道,如微信群、朋友圈发布信息,缺乏统一管理机制,存在任务匹配效率低、交易无保障、责任归属不清等隐患。
传统代取模式通常以口头约定或简单文字沟通为主,缺少标准化流程和可追溯记录,一旦出现包裹错拿、延误或纠纷,难以有效追责与处理。此外,跑腿人员身份未经审核,服务质量参差不齐,用户信任度难以建立。在此背景下,需一个结构清晰、操作规范、安全可靠的数字化平台,将校园快递代取服务纳入有序管理轨道,实现需求与供给的高效对接,同时保障各方权益。
(二)研究意义
构建基于Django与微信小程序的校园快递代取应用,有助于推动校内生活服务向规范化、信息化方向发展。通过明确用户角色划分、设定审核机制、固化任务流程,可显著提升服务透明度与执行效率,减少因信息不对称引发的矛盾。平台记录完整操作日志与交易数据,为后续问题追溯与管理决策提供依据,增强服务可信度与用户满意度。
此外,该应用以轻量化方式嵌入学生日常使用的微信生态,降低使用门槛,提高参与意愿。跑腿用户经管理员审核后方可提供服务,既保障服务质量,又为部分学生提供勤工助学机会。整体方案不仅优化了校园物流末端体验,也为高校探索数字化生活服务场景提供了实践样本,具有一定的推广价值与社会意义。
(三)研究现状
1.国内研究现状
近年来,随着高校生活服务需求的不断增长,国内高校及科研机构对校园代取、跑腿类服务平台开展了多项探索。部分高校尝试通过自建平台或与第三方合作方式优化末端物流体验。例如,浙江大学曾推出“求是帮帮”小程序,整合校内代办、代取、代送等服务,采用实名认证与信用积分机制提升用户责任感;武汉大学信息管理学院有研究聚焦于校园众包任务分配模型,强调任务匹配效率与用户满意度之间的平衡。此外,一些创业项目如“UU跑腿”“闪送校园版”也逐步向高校场景渗透,但多以通用型平台为主,缺乏针对校园封闭环境、身份认证、宿舍楼栋定位等特性的深度适配。
在技术实现层面,国内多数校园服务平台采用Django、Flask等Python Web框架配合MySQL数据库构建后端,前端则依托微信小程序或H5页面提供轻量交互。相关学术论文多集中于任务调度算法优化、用户行为分析及平台信任机制设计,如《基于信用评价的校园跑腿平台设计》《高校快递代取服务中的激励机制研究》等,均指出标准化流程与身份审核机制对提升服务质量具有关键作用。然而,现有平台普遍存在功能分散、审核机制薄弱、财务处理不透明等问题,尚未形成统一、安全、可复制的校园代取服务范式。
2.国外研究现状
在国外,校园生活服务数字化起步较早,尤其在北美和欧洲高校,已形成较为成熟的校内服务平台生态。美国斯坦福大学推出的“Stanford Marketplace”不仅支持物品交易,还包含任务发布与承接功能,学生可通过平台发布代取快递、代购日用品等请求,系统自动匹配附近可接单用户,并集成校内身份验证与支付接口。麻省理工学院则开发了名为“TaskRabbit for Campus”的实验性应用,借鉴商业众包平台模式,引入评分、评论与纠纷调解机制,确保服务可靠性。
欧洲方面,荷兰代尔夫特理工大学曾开展“Campus Helper”试点项目,结合校园卡系统实现身份绑定,所有跑腿人员需完成安全培训并通过审核方可接单,任务完成后由平台自动结算至电子钱包。相关研究多关注服务公平性、隐私保护与劳动伦理问题,如剑桥大学发表的《Ethical Considerations in University-Based Gig Platforms》探讨了学生兼职跑腿中的权益保障边界。技术上,国外平台普遍采用RESTful API架构,后端语言涵盖Java、Node.js、Ruby on Rails等,前端多为原生移动应用或PWA,注重数据安全与用户体验。尽管国外模式成熟度较高,但其高度依赖校园IT基础设施与本地化运营,在国内高校直接复用存在适配障碍,需结合本土实际进行重构与优化。
二、相关技术介绍
(一)Django框架
Django是基于Python语言的高级Web开发框架,采用MVT(模型-视图-模板)架构,强调快速开发与代码复用。其内置用户认证、权限控制、URL路由、表单验证及ORM等核心组件,有效降低开发复杂度。ORM机制允许开发者通过操作Python类而非原生SQL语句来管理数据库,提升安全性与可维护性。中间件系统支持对请求和响应进行全局处理,适用于日志记录、跨域控制、安全防护等场景。该框架已在多个领域得到应用,如构建个性化推荐服务[1],以及工业生产中的质量监控系统[2],体现出其在不同业务场景下的适应能力与稳定性。
(二)Python语言
Python是一种高级、解释型、动态类型的编程语言,以语法简洁、可读性强著称。其采用缩进定义代码块,逻辑结构清晰直观,适合快速原型开发与教学实践。标准库丰富,涵盖文件操作、网络通信、数据解析等多个方面,同时拥有活跃的第三方生态,广泛应用于Web开发、自动化脚本和教育工具开发。在实际项目中,Python被用于实现学生事务管理功能[3],也作为问题驱动教学的重要载体[4],并被用来探索编程思维与可视化表达的结合路径[5],展现出其在工程与教育双重维度上的灵活性与表现力。
(三)MySQL数据库
MySQL是一款开源的关系型数据库管理系统,支持多用户并发访问,具备完善的事务处理机制和数据完整性约束。它使用标准SQL语言进行数据操作,兼容性强,部署便捷。通过索引、缓存和连接池等优化手段,可在高负载环境下保持良好性能。MySQL常与Django等Web框架配合使用,实现高效的数据持久化。在信息分析类应用中,其被用于存储和管理大量结构化数据,支撑前端的可视化展示与交互查询[6],验证了其在数据密集型系统中的可靠性。
(四)微信小程序
微信小程序是一种轻量级的应用形态,依托微信客户端运行,采用WXML、WXSS与JavaScript构成的技术体系进行开发,具备组件化架构和本地数据存储能力。其“无需下载、即用即走”的特性显著降低了用户使用门槛,同时深度集成微信账号体系,支持一键授权登录、消息订阅推送及地理位置获取等原生能力,有效提升身份认证效率与信息触达精准度。目前,该技术已在校园服务、文化传播、组织管理等多个领域实现规模化应用,如用于构建信息发布与智能匹配平台[7]、支撑实验教学流程的数字化辅助工具[8]、开展双语文化内容的传播实践[9],以及优化基层党建工作的管理机制[10]。通过标准RESTful API与后端服务对接,微信小程序能够灵活适配多样化的业务逻辑,已成为连接终端用户与数字服务生态的关键载体。
三、系统分析
(一)系统可行性分析
1.技术可行性
系统采用Django作为后端开发框架,结合Python语言、MySQL数据库与微信小程序前端,技术栈成熟且文档完善。Django内置的安全机制、用户认证体系和ORM支持,能够高效支撑用户管理、订单处理、权限控制等核心功能;MySQL具备良好的事务处理能力和稳定性,适用于结构化数据存储;微信小程序依托微信生态,开发工具链完整,支持扫码登录、消息推送、支付接口等能力,满足校园场景下的交互需求。相关技术已在教育、工业、文化等多个领域广泛应用,具备充分的技术保障与可实施性。
2.经济可行性
系统开发主要依赖开源技术,无需支付高昂的软件授权费用。服务器部署可选用主流云服务商的基础配置,初期投入成本较低;微信小程序发布免费,且天然具备高用户触达率,省去推广安装渠道的额外支出。对于高校而言,平台可由校内信息化部门或学生技术团队维护,运维成本可控。长期来看,平台若引入适度服务佣金或与快递站点合作,具备潜在的可持续运营能力,经济上具有合理性与可延续性。
3.操作可行性
平台面向高校师生设计,操作流程贴合校园生活实际。学生用户通过微信即可完成注册、下单、支付等操作,无需额外学习成本;跑腿用户经审核后接单,流程清晰;管理员通过Web后台进行统一管理,界面简洁、功能分区明确。所有角色的操作均基于常见交互模式,符合用户使用习惯。同时,微信作为日常高频应用,为平台提供了天然的用户基础与使用便利性,确保系统在实际运行中易于被接受和持续使用。
(二)系统功能性分析
1.用户功能需求分析
为满足校园快递代取服务的规范化、高效化与安全化需求,系统需面向学生用户、跑腿用户和管理员三类角色,提供差异化且协同的功能模块。整体功能设计围绕任务发布、接单执行、资金流转、信息管理与监督反馈等核心业务流程展开,确保服务闭环完整、权责清晰、操作便捷。以下从三类用户视角出发,对主要功能需求进行简要分析:
(1)学生用户功能描述:
① 首页:展示平台最新动态与推荐任务,提供快速访问任务大厅、快递站点等核心功能的入口。
② 推荐:根据用户浏览和操作习惯,智能推送相关任务或站点信息,提升服务匹配效率。
③ 快递站点:列出校园内所有快递站点的基本信息,包括名称、位置、联系电话及照片,支持用户查看并选择取件地点。
④ 任务大厅:集中展示所有待接代取任务,支持按楼栋、站点、悬赏金额等条件筛选,便于学生发布或查看订单。
⑤ 新闻动态:发布系统公告、校园通知及平台更新信息,确保用户及时获取重要消息。
⑥ 我的:集中管理个人信息,包括基本信息维护、收藏站点、评论记录、任务与订单查询、支付与充值记录、订单评价提交、异常订单申报及投诉反馈等功能,实现个人服务闭环。
(2)跑腿用户功能描述:
① 首页:展示平台首页内容与可接任务提醒,提供进入任务大厅和查看个人状态的快捷入口。
② 推荐:展示高优先级或热门任务,帮助跑腿用户快速发现可接订单。
③ 快递站点:查看各站点位置与联系方式,辅助接单决策与路线规划。
④ 任务大厅:浏览当前可接任务列表,支持点击查看详情并接单。
⑤ 新闻动态:接收平台通知与校园服务公告,了解运营变动与规则调整。
⑥ 我的:集中管理个人账户信息、已接订单、收入记录、提现申请与历史记录,支持查看评价内容与处理异常情况,并可通过投诉反馈通道提出问题。
(3)管理员功能描述:
① 后台首页:提供系统运行概览与关键数据统计,作为管理入口。
② 系统用户:管理所有注册用户,支持对跑腿用户进行审核、禁用或权限调整。
③ 快递站点管理:添加、编辑、删除快递站点信息,上传站点照片并维护园区地址与联系方式。
④ 任务大厅管理:查看和干预任务发布状态,处理异常任务或违规行为。
⑤ 我的订单管理:查看所有订单的详细信息与执行状态,支持人工介入处理。
⑥ 支付记录管理:核对用户支付情况,确认跑腿收入结算,保障资金准确分配。
⑦ 订单评价管理:查看用户对服务的评价内容,监督服务质量。
⑧ 充值记录管理:审核用户的充值记录,确保资金流转合规。
⑨ 提现记录管理:处理跑腿用户的提现申请,审核通过后确认出账。
⑩ 入账明细管理:记录平台收入来源,如订单手续费、服务费等。
⑪ 出账明细管理:记录向跑腿用户发放的报酬,确保财务透明。
⑫ 收入明细管理:汇总平台整体收入情况,支持报表导出与分析。
⑬ 异常订单管理:处理未完成、争议或取消的订单,记录原因并归档。
⑭ 投诉反馈管理:查看用户提交的投诉与建议,协调解决服务问题。
⑮ 宿舍楼栋管理:维护校园内各宿舍楼的信息,用于任务定位与区域划分。
⑯ 取件时段管理:设置不同站点的取件时间范围,规范服务流程。
⑰ 年月信息管理:配置系统使用的时间参数,支持按月份统计与结算。
⑱ 系统管理:配置系统基础参数,如角色权限、接口设置等。
⑲ 通知公告管理:发布站内通知,支持面向全体或指定用户群组发送。
⑳ 资源管理:管理平台静态资源,如图片、文件等。
21 操作日志:记录管理员的操作行为,便于审计与追溯。
22 通知发布:向用户发送系统消息或公告,支持批量推送与定时发布。
2.系统性能需求分析
为保证系统的良好运行和用户体验,本系统需要满足以下性能需求:
(1)响应时间:系统在处理用户请求时,响应时间应控制在合理范围内,一般不超过3秒,确保用户操作的流畅性。
(2)并发处理能力:系统应能够支持一定数量的用户同时在线操作,在多用户并发访问时,仍能保持稳定的性能,不出现卡顿或崩溃现象。
(3)数据准确性:系统在处理和存储数据时,应保证数据的准确性和完整性,避免出现数据丢失、错误或重复的情况。
(4)安全性:系统应具备一定的安全防护能力,防止用户信息泄露、非法登录和恶意攻击等安全问题,采用密码加密存储、权限控制等安全措施。
(5)可扩展性:系统应具有良好的可扩展性,能够根据用户需求的变化和业务的发展,方便地添加新的功能模块或对现有功能进行升级和扩展。
(6)易用性:系统界面友好,操作简单直观,用户无需进行复杂的培训就能熟练使用系统。
(三)系统用例分析
1.学生用户用例分析
学生用户作为平台的主要服务需求方,其核心功能围绕任务发布与信息获取展开。通过首页可快速浏览平台动态与推荐内容,进入任务大厅查看或发布代取订单,结合快递站点信息选择取件位置;在“我的”模块中,能够管理个人信息、收藏常用站点、查看评论记录及统计服务数据,并对已完成订单进行评价、查询支付与充值记录,处理异常订单或提交投诉反馈,实现从下单到售后的全流程自主操作,保障使用体验的完整性与便捷性。学生用户用例图如图3.1所示。

2.跑腿用户用例分析
跑腿用户作为服务提供方,主要通过平台接单并完成代取任务。其功能围绕任务获取与收益管理展开,可通过首页和推荐模块浏览系统动态与高优先级订单,进入任务大厅查看可接任务并进行接单操作;在“我的”模块中,能够维护基本信息、收藏常用站点、查看评论与统计信息,管理已接订单及评价记录,查询提现申请状态与历史记录,并对异常订单或服务问题提交投诉反馈,实现从任务承接、执行到收入结算的完整闭环,确保服务过程透明可控、权益清晰可查。跑腿用户用例图如图3.2所示。

3.管理员用例分析
管理员作为平台的运营与监管主体,承担系统整体维护与业务流程管控职责。其功能覆盖用户管理、任务调度、财务核算与系统配置等多个维度,通过后台首页掌握系统运行概览,对系统用户进行身份审核与权限控制,管理快递站点、宿舍楼栋、取件时段等基础信息,监控任务大厅与订单状态;同时负责支付、充值、提现及入账出账等财务记录的核对与处理,管理订单评价、异常订单和投诉反馈,确保服务合规性与用户体验;此外,还可发布通知公告、配置系统参数、管理资源文件并查看操作日志,实现对平台全生命周期的集中化、规范化管理。管理员用例图如图3.3所示。

四、系统设计
(一)系统架构设计
本系统采用基于B/S架构的三层架构设计,分别为表示层、业务逻辑层和数据访问层,如图4.1所示。

表示层:即用户界面层,负责与用户进行交互,展示系统信息并接收用户输入。对于普通用户,表现为浏览器中的网页界面,包括首页、功能模块信息页、个人中心等;对于管理员,表现为后台管理界面。表示层通过HTML、CSS、JavaScript 等技术实现页面的布局和交互效果,将用户的请求传递给业务逻辑层,并展示业务逻辑层返回的处理结果。
业务逻辑层:位于表示层和数据访问层之间,负责处理系统的核心业务逻辑,该层接收表示层传递的请求,进行相应的业务处理,如验证用户登录信息、计算推荐列表等,然后将处理结果传递给数据访问层进行数据操作,或直接返回给表示层。
数据访问层:负责与数据库进行交互,执行数据的查询、插入、更新、删除等操作。该层通过Django的ORM机制实现对MySQL数据库的访问,将业务逻辑层的操作转换为对数据库的操作,并将数据库返回的结果传递给业务逻辑层。
这种三层架构的设计使得系统的各层职责分明,降低了各层之间的耦合度,便于系统的开发、维护和扩展。当需要修改系统的界面时,只需调整表示层,而不影响业务逻辑层和数据访问层;当业务逻辑发生变化时,只需修改业务逻辑层,无需改动表示层和数据访问层。
(三)系统流程设计
1.用户登录流程分析
用户登录流程为:用户在登录页面输入用户名和密码后,系统先进行数据验证,确保信息不为空;验证通过则对密码加密,与数据库中对应加密密码比对;若一致,创建session记录登录状态并跳转首页,若不一致或用户名不存在,提示 “用户名或密码错误”,返回登录页面供用户重新输入。
用户登录流程图如图4.3所示。

2.用户注册流程分析
用户点击注册按钮进入注册页面,填写用户名、密码、确认密码、邮箱等信息。系统对输入信息严格验证,包括用户名唯一性、密码长度合规性、密码一致性及邮箱格式正确性。若验证失败,系统反馈对应错误提示,引导用户重新填写;验证通过后,系统加密密码,将注册信息存入数据库用户表。注册成功后,系统提示 “注册成功”,并跳转至登录页面供用户登录。
用户注册流程图如图4.4所示。

3.信息添加流程分析
以用户发布代取快递任务为例,其信息添加流程如下:用户登录小程序后进入“任务大厅”或“发布任务”页面,点击“发布代取任务”按钮,系统跳转至任务发布表单页。用户依次填写快递站点、取件码、收件人姓名、联系电话、期望取件时间、备注说明等必要信息,并确认提交。系统对所填内容进行校验,包括字段是否完整、联系方式格式是否正确、所选站点是否有效等。若校验未通过,系统弹出相应错误提示,用户可修改后重新提交;若校验通过,系统将该任务记录写入数据库,生成唯一任务编号,并同步更新任务状态为“待接单”,同时在任务大厅中实时展示该任务。最后,系统向用户提示“任务发布成功”,完成整个信息添加流程。信息添加流程图如图4.5所示。

(四)系统流程设计
1.数据库概念结构设计
数据库概念结构设计作为校园快递代取小程序开发的核心环节,通过E-R图将用户、快递站点、任务大厅、我的订单、异常订单等关键实体及其属性进行可视化呈现,以直观的图形化方式清晰界定系统组成要素。同时,精准梳理实体间的逻辑关系,为数据库的逻辑设计与物理实现奠定坚实基础。这一设计不仅确保数据存储结构科学合理,还能提升数据操作效率,从根本上保障数据完整性与一致性,极大增强系统运行的稳定性和可靠性,对系统的高效运转与长期发展具有不可替代的重要意义。
系统E-R图如图4.8所示。

图4.8 系统ER图
2.数据库表结构设计
根据数据库概念结构设计,将 E-R 图转换为具体的数据库表结构,以下是主要表的结构设计:
表 4-1-abnormal_order(异常订单)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
abnormal_order_id |
int |
|
是 |
是 |
异常订单ID |
|
2 |
order_number |
varchar |
64 |
否 |
否 |
订单编号 |
|
3 |
student_users |
int |
|
否 |
否 |
学生用户 |
|
4 |
site_name |
varchar |
64 |
否 |
否 |
站点名称 |
|
5 |
express_waybill_number |
varchar |
64 |
否 |
否 |
快递单号 |
|
6 |
pair_code |
varchar |
64 |
否 |
否 |
取件码 |
|
7 |
running_user |
int |
|
否 |
否 |
跑腿用户 |
|
8 |
exception_problem |
varchar |
64 |
否 |
否 |
异常问题 |
|
9 |
exception_specificss |
text |
65535 |
否 |
否 |
异常详情 |
|
10 |
create_time |
datetime |
|
是 |
否 |
创建时间 |
|
11 |
create_by |
int |
|
是 |
否 |
创建用户ID |
|
12 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
|
13 |
source_table |
varchar |
255 |
否 |
否 |
来源表 |
|
14 |
source_id |
int |
|
否 |
否 |
来源ID |
|
15 |
source_user_id |
int |
|
否 |
否 |
来源用户 |
表 4-2-access_token(登陆访问时长)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
2 |
info |
text |
65535 |
否 |
否 |
信息 |
|
3 |
maxage |
int |
|
是 |
否 |
最大寿命:默认2小时 |
|
4 |
token |
varchar |
64 |
否 |
否 |
临时访问牌 |
|
5 |
token_id |
int |
|
是 |
是 |
临时访问牌ID |
|
6 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
|
7 |
user_id |
int |
|
是 |
否 |
用户编号 |
表 4-3-article(文章)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
article_id |
mediumint |
|
是 |
是 |
文章id |
|
2 |
title |
varchar |
125 |
是 |
是 |
标题 |
|
3 |
type |
varchar |
64 |
是 |
否 |
文章分类 |
|
4 |
hits |
int |
|
是 |
否 |
点击数 |
|
5 |
praise_len |
int |
|
是 |
否 |
点赞数 |
|
6 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
7 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
|
8 |
source |
varchar |
255 |
否 |
否 |
来源 |
|
9 |
url |
varchar |
255 |
否 |
否 |
来源地址 |
|
10 |
tag |
varchar |
255 |
否 |
否 |
标签 |
|
11 |
content |
longtext |
4294967295 |
否 |
否 |
正文 |
|
12 |
img |
varchar |
255 |
否 |
否 |
封面图 |
|
13 |
description |
text |
65535 |
否 |
否 |
文章描述 |
表 4-4-article_type(文章分类)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
2 |
description |
varchar |
255 |
否 |
否 |
描述 |
|
3 |
display |
smallint |
|
是 |
否 |
显示顺序 |
|
4 |
father_id |
smallint |
|
是 |
否 |
上级分类ID |
|
5 |
icon |
text |
65535 |
否 |
否 |
分类图标 |
|
6 |
name |
varchar |
16 |
是 |
否 |
分类名称 |
|
7 |
type_id |
smallint |
|
是 |
是 |
分类ID |
|
8 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
|
9 |
url |
varchar |
255 |
否 |
否 |
外链地址 |
表 4-5-auth(用户权限管理)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
auth_id |
int |
|
是 |
是 |
授权ID |
|
2 |
user_group |
varchar |
64 |
否 |
否 |
用户组 |
|
3 |
mod_name |
varchar |
64 |
否 |
否 |
模块名 |
|
4 |
table_name |
varchar |
64 |
否 |
否 |
表名 |
|
5 |
page_title |
varchar |
255 |
否 |
否 |
页面标题 |
|
6 |
path |
varchar |
255 |
否 |
否 |
路由路径 |
|
7 |
parent |
varchar |
64 |
否 |
否 |
父级菜单 |
|
8 |
parent_sort |
int |
|
是 |
否 |
父级菜单排序 |
|
9 |
position |
varchar |
32 |
否 |
否 |
位置 |
|
10 |
mode |
varchar |
32 |
是 |
否 |
跳转方式 |
|
11 |
add |
tinyint |
|
是 |
否 |
是否可增加 |
|
12 |
del |
tinyint |
|
是 |
否 |
是否可删除 |
|
13 |
set |
tinyint |
|
是 |
否 |
是否可修改 |
|
14 |
get |
tinyint |
|
是 |
否 |
是否可查看 |
|
15 |
field_add |
text |
65535 |
否 |
否 |
添加字段 |
|
16 |
field_set |
text |
65535 |
否 |
否 |
修改字段 |
|
17 |
field_get |
text |
65535 |
否 |
否 |
查询字段 |
|
18 |
table_nav_name |
varchar |
500 |
否 |
否 |
跨表导航名称 |
|
19 |
table_nav |
varchar |
500 |
否 |
否 |
跨表导航 |
|
20 |
option |
text |
65535 |
否 |
否 |
配置 |
|
21 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
22 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
表 4-6-code_token(验证码)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
code |
varchar |
255 |
否 |
否 |
验证码 |
|
2 |
code_token_id |
int |
|
是 |
是 |
验证码ID |
|
3 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
4 |
expire_time |
timestamp |
|
是 |
否 |
失效时间 |
|
5 |
token |
varchar |
255 |
否 |
否 |
令牌 |
|
6 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
表 4-7-collect(收藏)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
collect_id |
int |
|
是 |
是 |
收藏ID |
|
2 |
user_id |
int |
|
是 |
是 |
收藏人ID |
|
3 |
source_table |
varchar |
255 |
否 |
否 |
来源表 |
|
4 |
source_field |
varchar |
255 |
否 |
否 |
来源字段 |
|
5 |
source_id |
int |
|
是 |
否 |
来源ID |
|
6 |
title |
varchar |
255 |
否 |
否 |
标题 |
|
7 |
img |
varchar |
255 |
否 |
否 |
封面 |
|
8 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
9 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
表 4-8-comment(评论)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
avatar |
varchar |
255 |
否 |
否 |
头像地址 |
|
2 |
comment_id |
int |
|
是 |
是 |
评论ID |
|
3 |
content |
longtext |
4294967295 |
否 |
否 |
内容 |
|
4 |
create_time |
timestamp |
|
是 |
否 |
创建时间 |
|
5 |
hidden |
tinyint |
|
否 |
否 |
是否隐藏 |
|
6 |
nickname |
varchar |
255 |
否 |
否 |
昵称 |
|
7 |
reply_to_id |
int |
|
是 |
否 |
回复评论ID |
|
8 |
source_field |
varchar |
255 |
否 |
否 |
来源字段 |
|
9 |
source_id |
int |
|
是 |
否 |
来源ID |
|
10 |
source_table |
varchar |
255 |
否 |
否 |
来源表 |
|
11 |
sticky |
tinyint |
|
否 |
否 |
是否置顶 |
|
12 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
|
13 |
user_id |
int |
|
是 |
是 |
评论人ID |
表 4-9-complaint_feedback(投诉反馈)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
complaint_feedback_id |
int |
|
是 |
是 |
投诉反馈ID |
|
2 |
student_users |
int |
|
否 |
否 |
学生用户 |
|
3 |
order_number |
varchar |
64 |
否 |
否 |
订单编号 |
|
4 |
running_user |
int |
|
否 |
否 |
跑腿用户 |
|
5 |
subject_of_complaint |
varchar |
64 |
否 |
否 |
投诉主题 |
|
6 |
processing_status |
varchar |
64 |
否 |
否 |
处理状态 |
|
7 |
complaint_content |
text |
65535 |
否 |
否 |
投诉内容 |
|
8 |
handling_reply |
text |
65535 |
否 |
否 |
处理回复 |
|
9 |
create_time |
datetime |
|
是 |
否 |
创建时间 |
|
10 |
create_by |
int |
|
是 |
否 |
创建用户ID |
|
11 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
|
12 |
source_table |
varchar |
255 |
否 |
否 |
来源表 |
|
13 |
source_id |
int |
|
否 |
否 |
来源ID |
|
14 |
source_user_id |
int |
|
否 |
否 |
来源用户 |
表 4-10-dormitory_building(宿舍楼栋)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
building_name |
varchar |
64 |
否 |
否 |
楼栋名称 |
|
2 |
create_by |
int |
|
是 |
否 |
创建用户ID |
|
3 |
create_time |
datetime |
|
是 |
否 |
创建时间 |
|
4 |
dormitory_building_id |
int |
|
是 |
是 |
宿舍楼栋ID |
|
5 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
表 4-11-express_site(快递站点)
|
编号 |
字段名 |
类型 |
长度 |
是否非空 |
是否主键 |
注释 |
|
1 |
express_site_id |
int |
|
是 |
是 |
快递站点ID |
|
2 |
site_name |
varchar |
64 |
否 |
否 |
站点名称 |
|
3 |
site_photo |
varchar |
255 |
否 |
否 |
站点照片 |
|
4 |
park_location |
varchar |
64 |
否 |
否 |
园区地点 |
|
5 |
contact_number |
varchar |
16 |
否 |
否 |
联系号码 |
|
6 |
location_description |
text |
65535 |
否 |
否 |
位置描述 |
|
7 |
hits |
int |
|
是 |
否 |
点击数 |
|
8 |
praise_len |
int |
|
是 |
否 |
点赞数 |
|
9 |
collect_len |
int |
|
是 |
否 |
收藏数 |
|
10 |
comment_len |
int |
|
是 |
否 |
评论数 |
|
11 |
location_address |
varchar |
64 |
否 |
否 |
当前位置 |
|
12 |
location_lng |
varchar |
64 |
否 |
否 |
当前位置经度 |
|
13 |
location_lat |
varchar |
64 |
否 |
否 |
当前位置纬度 |
|
14 |
create_time |
datetime |
|
是 |
否 |
创建时间 |
|
15 |
create_by |
int |
|
是 |
否 |
创建用户ID |
|
16 |
update_time |
timestamp |
|
是 |
否 |
更新时间 |
五、系统实现
(一)前台用户注册登录功能实现
注册界面允许学生用户与跑腿用户分别创建账户。填写内容包括用户名、密码、确认密码、真实姓名、联系方式及身份类型等必要信息。提交后,学生用户可直接完成注册流程,而选择跑腿身份的用户则需等待后台管理人员审核通过后,方可激活账户并使用相关功能。
登录界面提供身份验证入口,用户输入注册时设定的用户名与密码即可进入对应角色的操作页面。界面设有“忘记密码”链接,便于找回账户凭证。未通过审核的跑腿用户在尝试登录时将收到提示,说明其账户尚处于待审核状态,需等待管理端处理完毕后才能正常登录。
注册页面如图5.1所示。

图5.1 注册页面图
登录页面如图5.2所示。
图5.2 登录页面图
(二)学生用户功能实现
1.首页界面
学生用户进入首页后,可查看轮播图展示的最新服务信息与活动宣传。页面提供快捷入口,方便访问快递站点、任务大厅及新闻动态模块。下方设有新闻内容区域,支持按分类浏览校园相关资讯,并可通过“More”跳转至完整列表。底部导航栏实现页面快速切换,提升操作效率。首页页面如图5.3所示。
图5.3 首页页面图
2.我的界面
学生用户进入“我的”界面后,可查看个人账户信息及各项服务记录。页面顶部显示用户名与身份标识,并提供基本信息修改入口。下方设有多个功能模块,包括收藏内容、评论记录、数据统计、任务大厅、订单管理、支付与充值记录、订单评价、异常订单处理以及投诉反馈通道。用户可通过点击对应选项跳转至详细页面,进行信息查询或操作。
在个人信息管理中,支持头像更换、昵称调整、密码修改及资料编辑,变更后可保存生效。充值记录页面允许按学号、订单编号、审核状态和支付情况筛选信息,并查看每笔交易的详细内容,包括金额、审核结果与回复说明。用户资料详情页展示姓名、学号、联系方式、宿舍位置、房间号及钱包余额等完整信息。任务大厅与订单查询支持按条件过滤并查看具体执行信息,异常订单可按站点与问题类型进行检索。所有记录均支持分页浏览与详情查看,确保信息查阅便捷准确。我的页面如图5.4、5.5、5.6、5.7所示。
图5.4 我的页面图
图5.5充值记录页面图
图5.6 任务大厅页面图
图5.7 我的订单页面图
3.快递站点界面
学生用户进入快递站点列表页面后,可浏览区域内所有已登记的快递站点信息。页面顶部设有搜索栏,支持通过站点名称或所在区域进行关键词查找。每个站点以卡片形式展示,包含站点图片、名称、位置描述、联系电话以及互动数据,如点赞数、点击数和收藏数。用户可点击任意站点卡片,进入该站点详情页查看更全面的信息。
在站点详情页面中,显示站点的完整信息,包括名称、具体地址、联系方式及位置说明。页面下方嵌入地图模块,标示站点地理位置,便于用户直观了解其周边环境与实际方位。用户可在评论区查看他人留言,并通过输入框发表自己的使用体验或建议。评论内容提交后将显示于对应站点的评论板块,供其他用户参考。此外,页面还提供点赞、收藏等操作选项,方便用户对站点进行评价与标记。快递站点页面如图5.8所示。
图5.8 快递站点页面图
(三)跑腿用户功能实现
1.我的界面
跑腿用户进入个人中心后,可查看账户信息与相关功能模块。页面顶部显示用户名、身份标识及通知图标,支持跳转至基本信息修改页。下方设有收藏、评论、统计等快捷入口,以及我的订单、订单评价、提现记录、异常订单和投诉反馈等功能选项,便于管理服务流程与资金往来。
点击“统计”进入数据统计中心,可查看订单评价与每月收入明细情况。其他功能页面均提供筛选条件输入框,如订单编号、站点名称、状态、评价等级等,配合查询与重置按钮实现精准检索。提现记录支持添加新申请并按学号、订单号、审核状态筛选。异常订单与投诉反馈也具备相应过滤条件,帮助快速定位问题。个人信息详情页展示姓名、学号、联系方式、证件号码、钱包余额及审核状态,确保资料完整透明。我的页面如图5.10所示。
图5.10 我的页面图
图5.11 我的订单页面图
图5.12 提现记录页面图
图5.13 异常订单页面图
2.任务大厅界面
跑腿用户进入任务大厅后,可查看所有待接订单。页面顶部设有搜索框、站点选择及悬赏金额范围筛选项,支持按条件快速查找任务。订单以列表形式展示,包含订单编号、宿舍楼栋、站点名称和悬赏金额等关键信息,便于用户浏览与比较。
点击任一订单进入详情页,显示取件时段、备注说明等详细内容,帮助判断是否符合接单条件。页面底部设置“接单”按钮,确认后即可承接该任务,流程简洁直观,提升操作效率。任务大厅页面如图5.14所示。
图5.14 任务大厅页面图
六、系统测试
(一)测试目的
系统测试的目的是验证本校园快递代取小程序是否能够满足设计需求,确保系统的功能完整、性能稳定、操作便捷和数据安全。通过测试发现系统中存在的缺陷和漏洞,并及时进行修复,提高系统的质量和可靠性,为系统的正式上线和使用提供保障。
具体来说,测试目的包括:
验证系统的各项功能是否按照需求规格说明书正确实现,如用户注册登录、管理员的信息管理等功能是否正常工作。
检查系统的性能是否达到预期指标,如响应时间、并发处理能力等。
确保系统的数据处理准确无误,数据的存储、查询、更新和删除等操作是否正确。
测试系统的安全性,防止出现用户信息泄露、非法登录等安全问题。
检验系统的易用性,用户界面是否友好,操作是否简便。
(二)测试用例
1.系统功能性测试用例
表6.1 系统功能性测试用例表
|
编号 |
测试功能 |
输入数据 |
预期输出 |
实际输出 |
测试结果 |
|
TC-F-001 |
学生用户注册 |
用户名:student01,密码:123456,确认密码:123456,邮箱:s1@example.com,身份:学生 |
注册成功,数据库新增用户记录,跳转至登录页 |
注册成功,跳转至登录页 |
通过 |
|
TC-F-002 |
跑腿用户注册 |
用户名:runner01,密码:123456,确认密码:123456,手机号:13800000001,身份:跑腿 |
注册成功,状态为待审核,跳转至登录页 |
注册成功,状态显示“待审核” |
通过 |
|
TC-F-003 |
用户登录 |
用户名:student01,密码:123456 |
登录成功,跳转至首页,显示用户信息 |
登录成功,跳转首页 |
通过 |
|
TC-F-004 |
跑腿用户登录(未审核) |
用户名:runner01,密码:123456 |
提示“账户尚未通过审核,请等待管理员处理” |
显示提示信息 |
通过 |
|
TC-F-005 |
学生用户查看任务大厅 |
登录后进入任务大厅页面 |
展示所有可接任务列表,包含订单编号、楼栋、站点、悬赏金额等信息 |
正确展示任务列表 |
通过 |
|
TC-F-006 |
跑腿用户接单 |
在任务详情页点击“接单”按钮 |
订单状态更新为“已接单”,跑腿用户任务列表中添加该订单 |
接单成功,状态变更 |
通过 |
|
TC-F-007 |
管理员发布通知 |
标题:系统维护通知,内容:系统将于今晚22:00停机维护,方式:站内通知 |
通知成功发布,可在通知列表中查看,用户端收到提醒 |
通知发布成功,前端可见 |
通过 |
|
TC-F-008 |
管理员审核跑腿用户 |
在系统用户管理中选择跑腿用户 runner01,执行“审核通过”操作 |
用户状态变更为“正常”,可登录并接单 |
状态更新成功,用户可登录 |
通过 |
|
TC-F-009 |
管理员处理支付记录 |
在支付记录管理中选择已完成订单,点击“跑腿收入” |
跑腿用户钱包余额增加对应金额,收入记录生成 |
余额更新正确,记录完整 |
通过 |
|
TC-F-010 |
管理员添加快递站点 |
填写站点名称:A区快递点,园区地点:A区1栋,联系电话:18800000001,上传照片 |
站点信息保存成功,出现在站点列表中 |
信息保存成功,列表显示正常 |
通过 |
|
TC-F-011 |
学生用户提交订单评价 |
进入订单详情页,填写评价内容“服务很快”,评分:5星 |
评价提交成功,订单状态更新为“已评价”,评价内容在后台可见 |
评价提交成功,后台可查 |
通过 |
|
TC-F-012 |
管理员处理异常订单 |
在异常订单管理中选择一条异常订单,点击“处理”并填写原因 |
订单状态更新为“已处理”,处理记录保存 |
处理成功,状态更新 |
通过 |
2.系统性能测试用例
表6.2 系统性能测试用例表
|
测试 功能 |
测试环境 |
测试步骤 |
预期结果 |
实际结果 |
测试结果 |
|
页面响应时间 |
普通 PC,网络环境良好 |
访问首页、任务大厅、我的订单、通知公告等页面,记录加载完成时间 |
各页面响应时间均小于 3 秒 |
首页:1.4 秒,任务大厅:1.8 秒,订单页:2.1 秒 |
通过 |
|
并发用户登录 |
测试服务器,使用 JMeter 工具 |
模拟 100 个用户同时登录系统,包括学生、跑腿、管理员三种角色 |
所有用户登录成功,平均响应时间小于 5 秒 |
98 人登录成功,平均响应时间 4.3 秒 |
通过 |
|
任务大厅查询 |
数据库中存有 5000 条任务数据 |
模拟 50 个用户同时访问任务大厅,按楼栋、站点进行筛选查询 |
查询响应时间小于 2 秒,无超时或卡顿现象 |
平均响应时间 1.7 秒,无异常 |
通过 |
|
订单支付处理 |
高并发环境,模拟真实交易场景 |
模拟 30 个用户在 1 分钟内提交订单并完成支付,记录交易成功率与响应时间 |
支付成功率 ≥ 95%,单次支付响应时间 ≤ 3 秒 |
成功率 97%,平均响应时间 2.5 秒 |
通过 |
|
跑腿收入结算 |
后台管理端,多用户并发操作 |
模拟 20 名管理员同时对不同订单执行“跑腿收入”操作 |
所有结算操作成功完成,钱包余额更新准确无冲突 |
全部成功,余额更新正确 |
通过 |
|
通知发布广播 |
多终端接入,模拟消息推送 |
发布一条站内通知,目标为全体用户(共 2000 人),记录发送耗时与接收情况 |
通知在 3 秒内推送到所有用户,接收率 ≥ 99% |
推送完成耗时 2.8 秒,接收率 99.5% |
通过 |
|
异常订单处理 |
高负载下触发异常流程 |
模拟 15 个用户同时提交异常订单申请,管理员端批量处理 |
所有申请提交成功,管理员可正常查看与处理 |
提交成功,处理界面无卡顿 |
通过 |
(三)测试结果
根据所执行的功能性与性能测试用例,系统整体表现稳定,核心业务流程运行顺畅。学生用户和跑腿用户的注册、登录、任务浏览、接单、支付、评价等操作均能按预期完成,界面交互清晰,数据提交与状态更新准确无误。管理员端对用户审核、站点管理、通知发布、订单结算及异常处理等功能响应及时,操作逻辑符合设计要求。在性能方面,系统在模拟高并发场景下仍保持良好响应能力,页面加载时间控制在合理范围内,关键事务如登录、支付、收入结算等均满足响应时间与成功率指标,未出现数据丢失、重复或状态冲突问题。通知广播机制高效可靠,消息推送覆盖全面。综合来看,系统功能完整、逻辑严谨、性能达标,具备上线运行条件。
七、总结与展望
随着高校校园规模不断扩大,学生日常生活节奏加快,快递代取服务逐渐成为校园生活的重要组成部分。针对传统代取流程中存在的信息不透明、沟通效率低、管理混乱等问题,基于Django框架开发的校园快递代取小程序应运而生。该程序采用前后端分离架构,后端以Django为核心,结合MySQL数据库实现数据持久化存储,前端通过轻量级界面提供直观操作体验。整个平台围绕学生用户、跑腿用户与管理员三类角色展开功能设计,涵盖用户注册登录、任务发布与接单、订单支付与评价、站点信息展示、通知公告推送、财务记录管理等完整业务闭环。
学生用户可在首页浏览任务大厅,根据宿舍楼栋、快递站点及悬赏金额筛选合适订单,完成下单后由跑腿用户接单执行。跑腿用户需通过管理员审核方可激活账户,在任务大厅查看可接任务,完成代取后获得相应报酬,收入经管理员确认后计入个人钱包余额。管理员则负责全局管控,包括用户资质审核、快递站点维护、订单状态跟踪、提现与充值记录处理、异常投诉协调以及通知内容发布等。所有操作均通过权限控制确保数据安全与流程规范。测试阶段覆盖功能逻辑与系统性能,结果显示各模块运行稳定,高并发场景下响应及时,事务处理准确,满足校园实际使用需求。
该程序有效提升了快递代取服务的组织化与信息化水平,减少人工协调成本,增强服务透明度与用户信任感。通过结构清晰的代码实现与合理的数据库设计,保障了系统的可维护性与扩展性。未来可在现有基础上进一步优化交互细节,丰富统计维度,为校园生活服务平台建设提供可行范例。
参考文献
致 谢
在本毕业设计论文的撰写过程中,我得到了许多人的帮助和支持,在此表示衷心的感谢。
首先,我要感谢我的导师。从论文的选题、框架设计到具体内容的撰写和修改,导师都给予了我悉心的指导和无私的帮助。导师严谨的治学态度、深厚的学术功底和对工作的敬业精神,使我受益匪浅,为我完成论文提供了重要的支持和动力。
感谢学院的各位老师,在学习期间,他们的谆谆教诲为我打下了坚实的专业基础,使我能够顺利完成本系统的开发和论文的撰写。
感谢我的同学们,在系统开发过程中,我们相互交流、相互帮助,共同解决了许多技术难题,他们的陪伴和支持让我感受到了集体的温暖。
最后,感谢我的家人和朋友,他们在我学习和论文撰写期间给予了我无微不至的关怀和鼓励,是我坚持不懈、完成学业的坚强后盾。
