我见过太多人在毕设选题时反复横跳今天想做社交App明天想搞推荐算法最后写出来的系统要么过于简陋被老师打回要么过于庞大一个人根本做不完。如果让我给你一个稳妥又不容易翻车的选择基于Web的药品商城会是一个非常合适的答案。它不像“学生管理系统”那样千篇一律又不像“分布式电商平台”那样超出本科毕设的合理容量同时天然包含商品管理、购物车、订单流转、权限控制、支付对接这些招聘时经常被问到的核心场景。这篇内容我会从一个真正动手做过药品商城项目的人的角度把选题理由、数据库设计、用户端与管理端的核心流程、技术选型逻辑、安全与异常处理、本地部署和源码二次开发建议全部拆开讲。不管你手里是已经拿到了一套免费毕设源码想读懂它还是打算从零手写一套这篇都能帮你少走不少弯路。1. 为什么是药品商城这个题目的容量与边界1.1 项目合理容量一个本科毕设的核心诉求毕设项目最怕两个极端一个是简单到只有增删改查代码量撑不起一篇论文另一个是设计成微服务集群、分布式事务、高并发秒杀结果只有两周时间写完最后连启动都费劲。药品商城Web项目恰好卡在中间。它的核心链路是“用户注册登录 - 浏览药品 - 加入购物车 - 提交订单 - 模拟支付或沙箱支付 - 管理端发货 - 确认收货”这本身就是一套完整的电商闭环意味着你在答辩时可以讲清楚每一个模块的输入、处理、输出论文也有充足的内容可写。同时药品这个垂直领域有它独特的业务约束药品分为处方药和非处方药不同分类在前端展示和下单流程上要有差异药品存在批准文号、生产厂家、存储条件等通用电商商品没有的字段库存信息需要更严格的管理。这些约束让项目在通用商城框架之上多了一层专业性不会让老师觉得你只是在拿一个极简商城模板糊弄事。1.2 药品商城与普通电商平台的分水岭如果你已经看过一些商城源码你会发现绝大多数开源项目把商品表设计成“标题、价格、图片、详情、库存”就结束了。但药品商城如果照搬这种设计答辩时老师只要问一句“你的系统如何区分RX和OTC”你就很难回答。药品商城的核心差异有两个一个是商品属性的结构化。通用商品用一串富文本描述就够药品则需要把批准文号、生产厂家、剂型、规格、用法用量、存储条件、Rx标识等作为独立字段存储而不是揉在文本里。另一个是购买流程的规则差异。处方药需要提示“请遵医嘱”部分源码会加入处方上传功能非处方药可以正常加购。作为毕设我建议你保留区分字段和前端提示逻辑但不需要做完整的处方审核流那是医院信息系统的体量。1.3 这套系统面向哪些人、解决什么问题如果你属于下面三类人这篇的参考价值最大第一类是计算机相关专业的本科生正在做毕业设计需要一个结构清晰、代码能跑、答辩有亮点的项目作为参考。第二类是准备找Web开发或Java开发岗位的在校生需要一个能写进简历的项目经验想通过真实业务场景理解电商系统的开发全流程。第三类是已经拿到免费毕设源码但看不懂代码结构、不知道怎么改需求、不知道怎么部署的同学——网上下载的源码最麻烦的就是“能启动但不敢动”我希望帮你把它变成“看得懂、改得了、跑得顺”的项目。2. 数据库与核心表设计药品商品化的关键决策2.1 用户、药品、订单三张核心表的字段设计思路数据库设计是几乎所有毕设的重头戏也是答辩老师第一个关注的地方。很多同学的数据库表只有三五张明显撑不起一个商城系统但也有同学建了二十多张表其中一半是冗余字段和空表显得结构凌乱。这里我给出药品商城场景下最实用的一套基础表划分用户表、药品分类表、药品表、购物车表、收货地址表、订单主表、订单明细表、管理员表。先看用户表。它应该包含用户的唯一ID、用户名、密码、昵称、手机号、头像地址、状态字段。密码字段非常重要一定不要存明文要用BCrypt加密后的哈希值。状态字段用于控制用户是否可以登录比如管理员可以禁用异常用户这个字段在答辩时也能体现你对用户管理的理解深度。再看药品表。除了常规的编号、名称、副标题、分类ID、价格、库存、销量、主图地址、详情内容之外还需要增加几个药品特有字段Rx类型1表示处方药RX0表示非处方药OTC、批准文号、生产厂家、剂型、规格。表中还应设计一个上下架状态字段用0/1表示管理端可以将药品改为下架状态下架后用户端不可见、不可加购。订单主表需要记录订单编号、用户ID、订单总金额、支付方式、订单状态、收货人姓名、联系电话、收货地址、支付时间、创建时间。订单明细表则要记录订单ID、药品ID、药品名称快照、药品图片快照、单价快照、购买数量、小计金额。这里的关键点在于快照因为在真实的电商系统中用户在提交订单后如果商家修改了药品名称或价格订单历史信息不应该跟着变。2.2 数据库为什么需要这些约束设计表结构时有一个非常容易被忽略的坑字段的类型和约束。很多毕设源码喜欢用varchar存价格、用varchar存状态虽然用起来舒服但后期统计金额、排序价格时非常痛苦。金额字段用decimal(10,2)而不是float或double因为二进制浮点数在计算0.10.2时会得到0.30000000000000004这样的结果订单金额一旦涉及累计和退款精度问题会直接导致金额对不上。状态字段优先用tinyint配合后端代码里定义好的枚举值不用varchar存“待支付”“已支付”这种中文状态否则数据库混乱、前端展示也麻烦。时间字段统一用datetime并在后端统一设置时区不要有的用int时间戳、有的用字符串会让排序和统计非常难做。另外外键约束我并不建议你在表结构中大量使用但逻辑外键一定要有。也就是说订单明细表里的药品ID在业务逻辑上关联药品表但不需要物理 FOREIGN KEY 约束。理由很简单毕设项目规模小、数据量少外键不会造成严重性能问题但删除数据时外键会限制自由度比如管理员想清理测试订单时外键关联会让操作变复杂。保持索引和一致性检查放在业务层做对开发调试更友好。2.3 SQL脚本与初始化数据的重要性网上下载的毕设源码通常带一个sql文件但质量参差不齐。有的只建表不给数据启动后整个系统空空如也演示效果大打折扣有的数据是乱编的价格明显不合理。我建议你拿到源码后不要急着改代码先重建数据库并导入初始化脚本然后做三件事检查分类表里是否有完整的药品分类数据比如感冒用药、肠胃用药、皮肤用药、医疗器械、维生素矿物质等检查药品表中是否有至少20条能用的演示药品并且每个分类下都有代表性商品检查是否有演示账号和管理员账号。对药品的价格和图片做一次清理把明显不对的修改掉把失效的网络图片替换成本地图片或占位图。这一步做好你后期做功能演示时能省很多不必要的时间。3. 技术选型与工程结构为什么我推荐这套组合3.1 后端框架选型的真实理由药品商城作为一个典型的Java Web项目当前毕设源码中主流的技术方案是SpringBoot MyBatis-Plus少部分在用SpringBoot JPA比较老旧的还在用SSMSpring SpringMVC MyBatis甚至JSP Servlet。我强烈建议你优先使用SpringBoot MyBatis-Plus组合。SpringBoot带来的最大价值是自动配置和起步依赖不需要你写繁琐的XML配置文件主类一启动内嵌Tomcat就跑起来了这对毕设开发效率非常关键。MyBatis-Plus则在原生MyBatis基础上封装了通用Mapper和Service单表增删改查几乎不用写SQL直接调用selectPage()、selectById()就完成可以将开发周期压缩到一个可控范围。为什么不推荐直接上Spring Cloud微服务因为药品商城不需要。微服务要解决的是团队协作与独立部署的问题而你一个人做毕设单体应用完全够用。如果非要在答辩中聊扩展性你可以说“系统采用模块化分层架构为未来拆分为独立的用户服务和订单服务预留了空间”但代码层面保持简单的单体结构就好。3.2 前端是服务端渲染还是前后端分离药品商城Web项目在前端有两种典型做法。第一种是用Thymeleaf服务端模板渲染前端页面由后端Controller返回ModelAndView控制。这种方式结构简单、不需要额外部署前端服务但是页面交互体验有限购物车更新、异步校验等操作实现起来比较绕。第二种是前后端分离后端提供JSON接口前端使用Vue Element UI开发单页应用通过Axios调用接口部署时前端打包成静态文件交给Nginx托管。这种方式更接近企业开发的真实形态也是现在免费毕设源码中比较受欢迎的方案。我的建议是只要你的时间允许优先选择前后端分离方案。它带来的额外复杂度是配置一次跨域、处理一次Token鉴权、多维护一套前端工程但对于简历项目和答辩展示来说收益远大于成本。你可以在前端项目里把登录、商品列表、购物车、订单管理做成清晰的路由页面演示时切换页面非常直观答辩时也能明确说清楚“前端负责交互逻辑后端提供RESTful API接口”。如果时间实在紧张再考虑Thymeleaf渲染方案代码量少但亮点也少。3.3 工程结构如何给源码做“提词器”拿到源码后第一步一定是看项目结构而不是急着启动。一个清晰的后端工程结构应该是长这样的src/main/java/com/example/pharmacy ├── common # 通用类统一返回结果、异常处理、常量定义 ├── config # 配置类跨域、拦截器、WebMvc配置 ├── controller # 控制器层接收前端请求、返回JSON ├── entity # 实体类与数据库表字段对应 ├── mapper # MyBatis-Plus的数据访问接口 ├── service # 业务逻辑层接口 │ └── impl # 业务逻辑层实现 ├── utils # 工具类JWT工具、文件上传工具等 └── PharmacyApplication.java # 启动类如果一个源码包里的所有Java文件都堆在同一个包里或者一个文件三千行我建议你谨慎使用。代码的可读性和扩展性决定你后续改需求的难度也决定老师阅读源码时对你的评价。前端Vue工程通常按src/api、src/router、src/views、src/components的方式组织如果结构混乱同样建议自行重组后再开发。4. 用户端核心链路从检索药品到订单落库4.1 登录鉴权不只是拦截未登录用户用户端最常见的入口操作是注册和登录。在商业系统中很少用Session保存用户状态而是采用JWT模式用户登录成功后后端生成一个Token返回给前端前端存储在localStorage中每次请求都把它放在请求头里面后端通过拦截器验证Token的合法性并从中解析出当前用户ID。在SpringBoot中实现这个逻辑通常需要三步编写JWT工具类负责生成和解析Token编写自定义拦截器校验放行登录接口和公开接口对需要登录的接口解析用户信息在WebMvcConfig中注册拦截器并设置放行路径比如/api/user/login、/api/user/register、/api/drug/list等。这里有一个关键细节拦截器拦截了请求并解析出用户ID后怎么把它传递给Controller。常见做法是使用ThreadLocal将用户ID存到ThreadLocal中Controller在处理请求时从ThreadLocal获取当前用户。但要注意请求结束后必须调用remove()清除ThreadLocal否则线程池复用后会串号。这个细节很可能在代码审查时被老师注意到也是区分“背代码”和“真明白”的一个点。4.2 药品分类与检索让用户找得到药药品列表页不是简单地把所有药品SELECT出来而是需要支持分类筛选、关键字搜索、分页和排序。药品分类表可以是两级分类也可以是一级分类。毕设中使用单层分类就好比如大类就是感冒用药、肠胃用药等再往下分容易把数据管理弄复杂。搜索逻辑的处理方式是在Service层组装查询条件如果用户传入了关键字就按药品名称或副标题做模糊匹配如果传入了分类ID就按分类ID过滤同时要始终过滤掉下架状态的药品。页码和每页大小建议使用MyBatis-Plus的分页插件配置一个MybatisPlusInterceptor并加上PaginationInnerInterceptor。分页返回的结果需要包含总条数、当前页、每页数量和列表数据前端才能正确渲染分页器。很多新手直接把所有药品一次性返回药品数量少时没感觉一旦插入几百条测试数据页面会越来越慢而且分页这个功能本身就是招聘中的高频考点值得好好实现。4.3 购物车加购与数量校验购物车可以持久化在数据库中而不是存放在Session或localStorage因为用户换设备后购物车不应该丢失。购物车表包含ID、用户ID、药品ID、加购数量、加购时间等字段即可不需要存冗余的价格快照因为购物车展示的是实时价格最终价格快照应放在订单明细里。加购药品时有一个重要校验必须检查药品当前是否处于上架状态、库存是否足够。用户在前端加购数量可以随便改但后端在下单和加购时都要再次校验库存。存在竞态条件的点在于两个用户同时买同一个药品最后一份库存被同时扣减。解决办法我放在第5部分的安全和并发内容中详细讲这里先记住一个原则所有库存校验必须在服务端完成并且放入事务中执行。4.4 订单生成与状态机骨架是状态流转订单模块是整个商城系统的灵魂。提交订单时后端应该执行一系列步骤校验用户收货地址是否为空从购物车或前端提交的订单条目中读取要购买的药品校验每个药品是否上架、库存是否充足计算订单总金额加上运费如果有生成订单编号插入订单主表和订单明细表扣减药品库存清空已购买的购物车记录。这些步骤必须放在同一个事务方法中任何一个步骤失败都应该回滚否则会出现“订单生成了但库存没扣”或者“钱扣了但订单丢失”的情况。订单编号不建议使用自增ID直接当订单号展示给用户因为会暴露系统每天的订单量。建议生成规则如时间戳yyyyMMddHHmmss 随机数或用户ID这样订单号看起来更真实也方便后续对接支付系统时作为商户订单号使用。订单状态建议定义如下状态值状态名称说明0待支付用户已下单但未支付1已支付/待发货支付成功后进入待发货流程2已发货管理端已发货用户可见物流信息占位3已完成用户确认收货后完成4已取消用户未支付取消或超时取消状态流转的规则要严格控制比如已取消的订单不能改成已支付已完成订单不能重复确认收货。这些逻辑在Service层通过状态判断实现同时返回给前端时可配合不同操作按钮的显隐。5. 管理后台与权限设计把后台做成可用系统5.1 后台模块的功能边界管理端是很多毕设源码的短板题目里写着“商城系统”后台却只有用户列表和商品列表订单管理功能形同虚设。但严格来说一个商城的完整闭环离不开后台支撑后台至少应该有五个模块仪表盘数据统计、药品管理、分类管理、订单管理、用户管理。数据统计模块中对药品总数、用户总数、订单总数、销售额进行汇总。这个模块在答辩演示中非常加分因为一进入后台就能看到直观的数字比空荡荡的列表更有说服力。数据统计不需要搞复杂的报表工具用SQL的COUNT和SUM就能完成。药品管理模块中管理员可以新增、编辑、上下架药品。新增药品时需要处理图片上传图片存储可以使用本地磁盘存储也可以使用OSS等对象存储。作为毕设本地磁盘存储更简单但要注意保存的是相对路径而不是IP端口全路径否则换电脑部署后图片路径全废。编辑药品时要同时更新药品特有字段分类变化也要同步。订单管理模块中管理员可以查看所有订单列表按订单状态筛选对待发货订单进行发货操作。发货时需要填写物流单号前端将状态从“已支付”改为“已发货”。订单列表同样需要分页因为数据量大之后一次查询全表会让数据库压力变大。5.2 后台鉴权不能和用户端混用新手最容易犯的错误是把管理员和普通用户放在同一张表里或者用同一个登录接口登录不同角色。药品商城正确做法是设计独立的管理员表后台拥有独立登录页使用独立拦截器校验管理员Token。管理员表不需要太多字段管理员ID、用户名、密码、昵称、状态即可。管理员登录成功后也生成Token但Token中要包含角色标记如role: ADMIN。在后台拦截器中除了校验Token是否有效还要校验角色是否为管理员。如果接口只允许管理员调用普通用户的Token就不能通过校验。这样一个简单设计就能避免“普通用户调用管理员接口删商品”的严重漏洞答辩时老师很爱问这类权限问题。5.3 统一接口风格与统一异常处理前后端分离项目中后端返回给前端的数据结构最好保持统一。推荐定义一个通用返回体{ code: 200, message: 操作成功, data: {} }前端Ajax拦截器判断codecode为200时进入正常逻辑其他code弹Message提示。这样设计的价值是无论Controller层返回什么前端都能用同一套代码来处理。同时后端需要编写一个全局异常处理器用RestControllerAdvice捕获业务异常和系统异常避免某个接口报错后直接把500堆栈抛给前端。全局异常处理器在捕获异常后应该记录日志返回给前端合理的错误提示比如“库存不足”“参数异常”“未登录”等。这样前端能及时提示用户后端能定位问题整体体验会专业很多。6. 安全、并发下库存扣减与支付对接的防坑记录6.1 密码安全不要让你的用户裸奔很多毕设源码里用户密码直接用明文存数据库或者用MD5算出固定哈希值这两种做法目前都已经落伍。正确的做法是使用BCrypt算法。BCrypt的特点是为每个密码生成不同的盐即使两个用户密码相同数据库中存储的哈希值也不同同时它本身的计算过程较慢能有效抵抗暴力破解。在SpringBoot中使用BCrypt非常简单引入 spring-security-crypto 依赖后调用BCryptPasswordEncoder().encode(password)即可登录时再调用matches(rawPassword, encodedPassword)校验。6.2 库存超卖经典的并发问题库存是一个商城系统最容易出事故的地方。假设药品库存只剩1件两个用户几乎同时提交订单如果先查询库存再扣减两个请求都可能看到库存大于0从而都认为可以下单结果库存扣了两次变成了负数。一个简单可靠的方案是使用SQL条件更新UPDATE drug SET stock stock - #{num} WHERE drug_id #{drugId} AND stock #{num}通过受影响行数来判断是否扣减成功如果行数为0说明库存不足直接抛出业务异常回滚事务。这个方案避免了对行加锁的复杂操作在单机应用和低并发场景下完全够用。如果你的毕设想展示更强的并发处理能力可以在订单表中增加一个唯一订单号约束防止重复提交。6.3 支付模块沙箱支付的取舍支付是电商项目的重头戏但在毕设中完全从零对接支付渠道并不容易。大多数免费毕设源码选择在订单模块中提供一个“模拟支付”按钮用户点击后前端调用后端的模拟支付接口后端直接将订单状态从待支付改为已支付。这个方案胜在简单、演示稳定不会因为环境问题中断答辩流程。如果你想做得更有说服力可以接入支付宝沙箱环境先注册一个支付宝开放平台账号在沙箱应用中获得AppID、应用私钥、支付宝公钥在后端引入支付宝SDK在支付接口中构造AlipayTradePagePayRequest并发起支付请求用户会在一个模拟的支付宝页面上完成“付款”。沙箱环境不需要真实资金适合演示。支付回调接口是重点支付宝服务器会异步通知你的回调地址回调接口必须验证签名、校验订单金额、校验商户订单号然后才能更新订单状态并且一定要做幂等处理避免回调多次导致状态被重复更新。这里要特别提醒如果你打算在答辩时用沙箱支付务必提前在本地把流程完整跑通不要当场依赖外网环境。如果网络环境不稳定采用模拟支付方案会保险得多。你可以在代码中保留两种方案通过一个配置项切换。6.4 防重复提交与参数校验用户在提交订单时如果手抖点了两次按钮可能会生成两笔相同订单。前端可以禁用按钮但后端仍需要兜底。简单做法是使用Redis的setnx命令在提交订单时以用户ID商品组合为key设置一个短过期时间的分布式锁如果key已存在说明请求正在处理中直接返回“正在处理请勿重复提交”。这个功能代码量不大但在答辩时经常被当成加分亮点。参数校验方面后端不能信任前端传过来的任何数据。不要在前端限制购买数量为正整数就以为万事大吉攻击者可以直接构造请求绕过页面。后端要用Spring Validation注解如NotNull、Min、Max在DTO层做基础校验在Service层再次做业务校验比如库存是否充足、药品是否上架、地址是否属于当前用户。7. 本地部署、运行验证与毕设源码的正确打开方式7.1 拿到源码后的启动步骤下载了一套免费毕设源码最怕是怎么都跑不起来。这里说一套我自己的启动排查顺序先看README如果README只写了“下载后导入运行”而没有写JDK版本、MySQL版本、Redis是否必须、前端启动命令那么后面大概率有坑。再检查pom.xml确认SpringBoot版本不同版本对应的JDK要求不同。接着导入SQL脚本到MySQL确认数据库名和用户名密码是否与配置文件一致如果不一样就改配置文件或改用application.yml里的配置。最后启动后端观察控制台日志是否报数据库连接失败如果端口被占用在message里会有明确提示。前端如果是Vue项目需要先执行npm install安装依赖这一步经常因为网络问题失败可以更换npm镜像源然后执行npm run dev启动开发服务器。启动后建议用浏览器分别打开前端页面和Swagger地址如果配置了验证接口连通。7.2 常见跑不起来的原因与解决办法我自己在帮人排查这类医疗/药品类Web毕设项目时遇到过最多的几类问题整理在下面问题现象常见原因解决思路连接数据库失败MySQL密码不对、数据库没建、驱动版本不匹配检查application.yml、确认mysql服务启动、确认SQL已导入端口被占用8080被其他进程占用改SpringBoot的server.port或杀掉占用进程前端请求接口报跨域前后端不在同源下后端配置CorsFilter或使用代理转发Token登录后接口仍401拦截器放行路径配置错误检查拦截器注册逻辑确认登录接口路径被放行图片上传后刷新消失存了绝对路径统一改为相对路径并配置静态资源映射启动时报Time zone错误MySQL时区不一致在JDBC URL加serverTimezoneAsia/Shanghai如果启动成功后想快捷验证所有接口正常强烈建议引入SpringDoc或Swagger启动项目后访问/swagger-ui/index.html查看接口清单和参数说明。这不仅能帮你快速调试在论文中也可以截图展示API文档答辩时显得项目更规范。7.3 关于免费毕设源码的使用态度免费毕设源码的核心价值是参考和学习不建议你直接原封不动提交那样既不符合学术诚信要求也无法回答老师的追问。拿到源码后你应该先读懂它的核心流程然后选择一个模块自己动手重构比如把订单模块从简单状态更新改成状态机模式把商品模块从前端写死的热门推荐改成后台可配置的推荐管理增加一个药品效期提醒功能。改造过之后再提交代码是你自己写过的答辩时才敢说“这个我知道怎么改”。8. 可扩展方向与我的个人实操体会8.1 四个值得做的高性价比扩展如果时间充裕下面是几个改动量不大但效果很好的扩展方向第一个是药品有效期管理。在商品表中增加生产日期和有效期字段后台新增“临期药品预警”列表对在90天内到期的药品高亮显示用户端对临期药品在详情页进行提示。这个功能贴合药品行业特性比通用商城更能体现出专业性。第二个是处方药购买流程。加一张用户处方单表用户购买处方药时需要上传医生处方图片管理端在后台审核通过后允许发货。虽然比普通商城多了几步但改动范围集中在订单逻辑和后台模块能够体现你对业务规则的思考。第三个是库存日志与出入库记录。在库存变动时插入一条记录记录操作类型加购下单、后台修改、取消订单回补、变动数量、操作来源。这个日志表对追溯问题很有帮助也是数据分析和管理功能的重要补充。第四个是数据看板用ECharts在管理后台展示近7日订单趋势图、分类销售饼图、热销药品榜。前端Vue中引入ECharts相当方便后端只需要提供几个统计接口视觉效果却非常显著答辩时演示这个页面往往会让老师眼前一亮。8.2 这个项目过程中我踩过的坑我在做类似药品商城项目时最深刻的一个教训是过于追求功能全结果导致每一块都做得很浅。最初我给自己规划了优惠券、积分、物流查询、留言板、消息通知等一堆功能开发到一半发现订单模块的事务逻辑一直没有仔细处理在演示时出现过一次“重复提交订单导致同一种药被扣了两次库存”的情况。所以后来我把范围收缩先确保基础链路稳定可靠再把有余力的部分作为扩展功能介绍。你会发现一个打磨细致的主流程比十个半成品功能更经得起推敲。另一个教训是数据库字符集没有在一开始就统一。药品名称里包含中文括号、特殊符号如果表结构是latin1或者utf8mb4配置混乱导入数据时会莫名报错或出现乱码。建议所有表和字段统一使用utf8mb4并在JDBC连接串中显式指定characterEncodingutf8这样从源头避免编码问题的干扰。8.3 给准备答辩的几个小建议如果你准备把药品商城项目作为答辩题目有几个地方建议提前准备第一一定要能完整讲清楚数据表关系最好手画一张E-R图放在论文里第二要能说明订单状态如何流转把你的状态机文字描述一遍第三要能回答“你的项目有什么不足”这个问题不要说没有不足而是说“当前版本在并发处理上只采用了数据库条件更新方式如果后续要支撑更高并发可以引入分布式锁和消息队列来削峰”这个回答会显示你知道系统的边界。最后再分享一个小技巧演示时准备一组真实感强的数据比如药品价格尽量接近实际药价而不是清一色的9.9元用户账号和订单数据保持多条并且有不同的状态后台数据统计展示出的金额最好有变化趋势。好的演示数据会让整体项目看起来更像一个“被认真使用过的系统”这一点的印象分有时候比你写几百行代码还重要。