直接代入一个场景：打开选题列表，一眼扫过去全是"XXX管理系统的设计与实现"，而"优选农产品销售管理系统"这类带电商属性的题，多半是被导师推荐或者自己在教务系统里挑的。SSM加Vue的组合在学生项目里出现频率高到不能再高，几乎成了JavaWeb毕设的固定搭配。这篇文章就围绕这个项目展开，从技术选型、数据库设计、代码组织到答辩准备，把整个系统的来龙去脉讲清楚，目标是让准备做同类项目的人少走弯路，既能让代码跑得起来，也能在答辩时把技术点讲得明明白白。无论你是完全零基础的小白，还是已经写过几个项目的进阶选手，接下来的内容都能给你提供一套可落地的方案。
1. 这类毕设项目真正考察的点是什么
1.1 为什么SSM+Vue是毕设场景里最稳的组合
先回答一个很直接的问题：都2025年了，为什么还要用SSM而不用Spring Boot？很多人有这个疑问，我给出的答案是：在毕业设计这个特定场景里，SSM不是落后，而是"合适"。
SSM是Spring、SpringMVC、MyBatis三个框架的组合。这一套东西在高校课程体系里地位非常稳固，绝大多数学校在大三、大四阶段都会系统讲授。用Spring Boot确实省事，自动配置帮你把所有东西都藏起来了，但问题是，答辩时导师问一句"Spring的IoC容器是怎么建立的"，如果你答不上来，就非常尴尬。而用SSM，你至少需要在配置里显式声明数据源、扫描包、事务管理器，这些XML或者注解配置本身就是一个很好的"技术点展示面"，证明你理解容器和Bean的装配过程。
Vue这个选择也讲究。Vue 2虽然官方维护已经进入收尾阶段，但语法简单、生态文档丰富，社区里随便一搜就是一堆实例，对用来做毕设后端的Java同学来说学习成本远比React低。更重要的是，Vue脚手架工具生成的前端工程结构非常清楚，路由、组件、状态管理各司其职，配合axios请求后端接口，天然就是前后端分离的实践。一个毕设里同时用到主流后端框架和主流前端框架，项目复杂度不会太高，但该体现的工程化思路都有了，评分上去是水到渠成的事。
1.2 优选出题方向背后的业务逻辑拆解
"优选农产品"这个题眼实际上比"通用电商系统"更容易做出特色。普通商品销售系统就是标准的增删改查，很难体现业务思考。而农产品有非常明显的行业特征：非标品、按斤按件混合计重、时令性强、产地直供、生鲜需要特殊物流配送提示。这些特性都可以直接映射到系统功能上：
- 商品规格设计：同一个农产品有多种规格，比如"猕猴桃5斤装""猕猴桃10斤装"，价格、库存都不一样。这决定了数据库不能简单用一个商品表加一个价格字段，而要把商品和规格拆开设计。
- 时令标签和推荐位：农产品讲究"当季"，系统可以在首页做轮播图推荐和时令商品专区，这部分涉及公告、配置表、推荐位管理等。
- 订单状态流转：农产品发货周期和物流时效跟普通商品不同，订单可能需要"待采摘""已发货"这类状态说明，在状态机设计上可以体现业务敏感度。
- 会员与积分：农产品看重复购，可以设计积分规则，比如下单送积分、积分抵扣金额，把用户粘性这个维度加进去。
做项目的时候把这类业务细节讲出来，不需要很复杂，但能让导师迅速get到你不是在机械地写CRUD，而是真的思考过"这个系统要解决什么问题"。
2. 数据库设计：先把表的骨架搭对
2.1 核心数据表结构与字段设计详解
数据库设计是一个毕设项目最不能偷懒的环节。表建错了，后面代码写再多都要翻工。我自己在做这类系统时，核心表会控制在10张左右，一套标准电商系统的字段风格，不多不少刚好够用。
用户表、角色表、商品分类表、商品表、商品规格表、购物车表、订单表、订单明细表、收货地址表、轮播图表，这几张表基本就是骨架。商品分类表建议做成父子级结构，父级是"水果""蔬菜""粮油副食"这种大类，子级是"猕猴桃""苹果""土豆"这种具体的品类，用parent_id字段自关联实现无限级分类。这样做的好处是导航菜单的二级联动非常自然，代码里只需要递归遍历数据即可。
重点说说商品表和商品规格表为什么要分离。很多基础薄弱的人会把规格做成商品表里的一个字符串字段，用逗号拼接各种规格，这是典型的反面案例。假设你在页面上选择"购买2斤装猕猴桃"，那前端就需要把"2斤装"这个字符串回传给后端，后端再手写逻辑去解析字符串，又慢又容易错。正确做法是建一张商品规格表，每个规格一行记录，里面有价格、库存、销量、是否上架这些字段；商品主表只放商品的通用信息，比如标题、封面图、描述、产地、时令标签。这样在选择规格时，后端只需要根据规格id精确查询价格和库存，清爽得很。
订单表和订单明细表的结构也是老生常谈但非常关键。订单表记录订单整体信息，订单编号、用户id、总金额、状态、收货人、电话、地址、下单时间、付款时间、发货时间、完成时间。订单明细表记录商品快照，因为用户买完东西后商品改名或者改价了，订单里不应该跟着变，所以明细里要冗余存当前商品标题、图片、单价、数量、规格文本。这个"订单快照"的设计在答辩时非常加分，能体现你懂业务数据的不可变性。
我整理一个核心字段速查表放在这里，照着建库完全够用：
| 表名 | 关键字段 | 作用说明 |
|---|---|---|
| user | id, username, password, nickname, phone, avatar, role, points | 统一用户表，通过role字段区分管理员和普通用户 |
| category | id, parent_id, name, sort, is_delete | 商品分类，parent_id支持多级 |
| product | id, category_id, name, cover_img, description, origin, season, status | 商品主表，status控制上下架 |
| product_sku | id, product_id, spec_name, price, stock, sales, status | 商品规格SKU表 |
| cart | id, user_id, sku_id, quantity, checked | 购物车条目 |
| orders | id, order_no, user_id, total_amount, receiver_name, receiver_phone, receiver_address, status, create_time | 订单主表 |
| order_item | id, order_id, sku_id, product_name, product_img, spec_name, price, quantity | 订单明细快照 |
| address | id, user_id, name, phone, province, city, district, detail, is_default | 收货地址 |
| banner | id, img_url, link_url, sort, status | 首页轮播图 |
2.2 订单状态机设计与防超卖处理
农产品销售系统的订单状态流转是整个项目里最值得讲清楚的逻辑。我的设计是五个状态：待付款(0)、待发货(1)、待收货(2)、已完成(3)、已取消(4)。有些系统还会拆出"退款中""已退款"等状态，但毕设场景五态足够，讲起来也简洁。
状态的推进路径要清晰：用户下单后生成待付款订单，模拟支付成功后状态变为待发货；管理员（或供应商角色）在后台点击发货后进入待收货；用户确认收货后变为已完成。取消操作则有讲究，待付款状态用户可以直接取消，待发货状态则应该判断是否已经发货运单，没发才能取消。代码里不要把所有状态流转逻辑散写在各个Controller里，而是封装成一个OrderStatusUtil或者直接写在OrderService里，通过一个状态变更方法统一处理，这样能避免很多意外bug。这个设计我强烈建议在论文架构图里画出来，是答辩时逻辑展示的亮点。
防超卖这个问题，很多同学第一次做电商系统都会忽略。后果很直观：库存剩最后1件，两个用户同时下单，数据库两条订单都扣了库存，最后库存变成-1。解决办法不是靠Java代码的if判断，因为两个请求可能同时通过了if判断才去更新。需要在SQL层做控制：执行UPDATE product_sku SET stock = stock - #{quantity} WHERE id = #{skuId} AND stock >= #{quantity}，利用MySQL的行锁保证同一时刻只有一个事务能成功更新，然后通过受影响行数判断是否扣减成功，如果返回0说明库存不足，直接回滚订单。这个点在论文里写出来，懂行的人一眼就知道你的水平在线。
2.3 权限设计：别一上来就做完整RBAC
权限这块最容易犯的毛病是过度设计。很多参考项目一上来就是五张表：用户表、角色表、权限表、用户角色关联表、角色权限关联表，然后搞一套完整的RBAC权限模型。思路没错，但毕设项目里十有八九只有两种角色——管理员和普通用户，这种体量下关联表方案属于杀鸡用牛刀。
我推荐的方案是用户表加一个role字段（int类型，比如0表示管理员，1表示用户），访问控制交给后端拦截器来处理。管理员访问后台管理页面时拦截器判断role值，非管理员直接重定向或返回404即可。真正要讲思想和可扩展性时，可以说"本系统预留了角色扩展字段，后续如有多种角色需求可平滑迁移到RBAC模型"这句话，既简单又留有余地。
当然，如果你有余力，单独建一张角色表再让用户表存role_id，结构也不算复杂，答辩时还能多讲一个关联查询的点。我的建议是，除非你想往"多角色系统"方向扩，否则别让关联表拖慢你的开发进度。
3. 后端SSM代码如何组织才不乱
3.1 分层架构与包结构最佳实践
SSM项目后端代码组织的好不好，直接看出你是否有工程素养。一个标准的包结构是这样的：com.xxx.controller、com.xxx.service、com.xxx.service.impl、com.xxx.dao、com.xxx.entity、com.xxx.config、com.xxx.common、com.xxx.util。
层次之间严格遵循依赖方向：Controller层只负责接收参数和返回结果，不写业务逻辑；Service层定义业务接口，Impl里实现具体逻辑，事务注解加在这层；Dao层是MyBatis的Mapper接口，与XML文件一一对应；Entity类与数据表字段映射，配置里开启驼峰转换，数据库的create_time自动映射到实体类的createTime。很多同学的代码乱就乱在Controller里直接new了一个Mapper开始查询，看起来省事，但Service层的业务封装和事务控制完全失效，后面加需求时痛苦加倍。
还要注意统一返回结果。在com.xxx.common里定义一个Result类，包含code、msg、data三个字段，成功返回code=200，失败返回code=500，这样前端axios拦截器拿到code就能统一判断，不用每个接口单独处理200/404/500等HTTP状态码。这是个很小但极其能提升开发效率的小工具，几乎所有完整的源码项目都会这么做。
3.2 登录鉴权与拦截器实现细节
毕设系统不要引入JWT，虽然JWT听起来高级，但Session加拦截器在Tomcat部署场景下完全够用，而且学生用Session实现登录鉴权更贴近课程里学的内容，答辩时也更好解释。
登录接口做的事情很清晰：接收用户名和密码，调用Service层根据用户名查用户，然后用MD5加盐的方式对比密码（数据库里不要存明文密码）。密码一致就通过，把用户信息保存进Session，返回给前端一个标识。不需要返回"token"字符串，只需要告诉前端登录成功，前端的axios封装里设置withCredentials为true，浏览器就会自动维护Session cookie。
拦截器是鉴权的核心载体。自定义一个HandlerInterceptor实现类，preHandle方法里先从Session里取用户信息，取不到就拦截并把"请先登录"的错误码返回给前端。然后考虑哪些路径需要拦截哪些路径放行：首页、商品列表、商品详情、登录注册这些肯定要放行；购物车接口、订单接口、用户中心接口必须拦截；管理员后台的所有接口除了拦截登录还要拦截角色。放行名单在配置类里写清楚，同时注册拦截器的时候把静态资源路径也排除掉，不然后端页面的静态文件都无法访问。这块最容易被忽略的地方就是路径匹配规则，写/**把所有接口都拦了，然后自己访问登录页就报错，排查半天发现是拦截器路径配置问题。
<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/register"/> <mvc:exclude-mapping path="/index"/> <mvc:exclude-mapping path="/product/**"/> <mvc:exclude-mapping path="/category/**"/> <mvc:exclude-mapping path="/banner/**"/> <mvc:exclude-mapping path="/static/**"/> <bean class="com.xxx.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>写XML配置的拦截器时注意，SpringMVC的XML头版本不同，标签里面的子标签名称可能有差别，最常见的坑是mvc:interceptors写成interceptors导致启动报错，照着Spring官方schema写就没问题。
3.3 MyBatis动态SQL与分页查询
商品列表页的筛选条件是典型的动态SQL场景。用户可能在页面上同时选择分类、输入关键词、勾选"时令"标签、设定价格区间，这些条件任意组合，固定SQL根本写不出。MyBatis的 加 标签组合能优雅解决这个问题： 标签会自动去掉多余的AND或OR， 负责逐个条件判断，多条件查询几十行XML就搞定，不需要字符串拼SQL，天然防SQL注入。
分页推荐直接使用PageHelper插件。引入依赖后在配置类里设置方言为mysql，Service层查询前调用PageHelper.startPage(pageNum, pageSize)，紧接着的查询会自动加上LIMIT，并生成Page对象包含总条数、总页数信息，返回给前端的分页数据直接封装成PageResult就行。PageHelper用的时候有两点要特别注意：startPage方法必须紧跟要分页的查询语句，中间不能有其他查询；写动态SQL时确保PageHelper能解析到正确的count语句，有时候多表联查会出现count计错，这时候可以用手写count方法替换。
PageHelper.startPage(pageNum, pageSize); List<ProductVO> list = productDao.selectProductList(queryMap); PageInfo<ProductVO> pageInfo = new PageInfo<>(list);3.4 文件上传与富文本图片处理
后台管理里商品图片、轮播图肯定要用到文件上传。SpringMVC的CommonsMultipartResolver配置解析器，设置文件大小上限，比如10MB。上传接口里把MultipartFile转存到服务器指定目录，文件名用UUID重命名防止重复和中文乱码，图片访问路径返回给前端直接用。有个细节：实际部署时Tomcat不推荐直接把图片存到工程目录里，因为重新部署会把图片搞丢，更稳的方式是存到一个独立的upload目录，然后在SpringMVC配置里添加一个资源映射，把/upload/**路径映射到那个物理目录。项目开发时图省事存到webapp下也行，但答辩时如果能说出来"图片外置存储"这个点，算是给系统做了一层工程化加固。
富文本编辑器一般用UEditor或者wangEditor，集成到后台发布公告、编辑商品详情时很方便。集成富文本后的一个经典坑就是图片上传路径和访问路径不一致，导致编辑时图片能显示、但前台页面图片挂掉。解决办法是给富文本配置自己的图片上传接口，接口返回的图片路径用绝对URL格式，保持一致。
4. 前端Vue部分：从搭建到联调的完整思路
4.1 Vue工程初始化和路由划分
前端工程用Vue CLI创建，版本选2.x即可。创建完先装依赖：axios、vue-router、vuex、element-ui，Element UI做后台管理界面非常成熟，表格表单组件直接套用能省大量时间。
目录结构按功能模块组织：src/views存放页面组件，再细分admin和front两个子目录；src/router存放路由配置；src/store存放Vuex状态；src/utils存放axios封装；src/api里按模块定义接口请求函数，比如product.js、order.js。把api请求单独抽出来很重要，页面组件里不直接出现axios.get这些调用，统一从api文件导入函数，后期接口地址变了只改一个文件，这种习惯在答辩讲代码时也可以作为工程化亮点。
路由设计要分前端展示区和后台管理区两块。前端商城页面有首页、商品列表、商品详情、购物车、确认订单、我的订单、登录注册等页面，用懒加载方式导入组件。后台管理页面有商品管理、分类管理、订单管理、用户管理、轮播图管理、公告管理等，统一放在AdminLayout布局组件下，左侧菜单栏、右侧内容区这种经典后台布局。路由守卫是可选的加分项，在beforeEach里判断本地存储是否有管理员标记，没有就跳登录页。但注意，前端路由守卫只是体验优化，真正的权限校验千万别指望它，安全边界必须由后端拦截器守住。
4.2 axios封装与请求拦截器使用
axios封装是前后端联调的基础设施。先创建一个axios实例，设置baseURL为"/api"，timeout为10000；请求拦截器从本地存储里取用户登录态，有就加到请求头里（如果用Session方案，这里主要是确保withCredentials开启）；响应拦截器统一处理后端返回的Result结构，code为200时直接返回data部分，code为500时弹出错误提示，HTTP状态码401时跳转登录页。这套封装写好之后，页面里调用接口的代码会非常清爽，两三行就完成一次带错误处理的请求。
前后端分离开发时跨域问题必然会遇到。后端接口在8080端口，前端devServer在3000端口，前端页面直接请求后端接口会被浏览器拦截。解决方式分两种：开发阶段用vue.config.js里的devServer.proxy配置把"/api"前缀的请求代理到target http://localhost:8080，同时关闭secure校验开启changeOrigin，这样浏览器里看到的是同源的，完美避开跨域；部署阶段前端打包成静态文件放后端工程目录里，Nginx做一下反向代理把动态请求转发到Tomcat，也完全无跨域烦恼。很多同学开发时后端接口写CORS跨域注解给前端放行，也能跑通，但正规做法还是代理或者同域部署，这一点在答辩时可以好好提一下。
4.3 购物车与订单确认页前端实现方案
购物车设计有一个关键决策：数据存本地还是存后端。把购物车存localStorage里确实简单，刷新不丢失，但换了设备购物车就空了，而且用户注销登录时数据得手动清空，如果后面想增加"购物车商品数量角标"这种功能，还得每个页面都去读本地存储。所以我建议购物车走后端接口，登录状态下加购、查询、删改都有对应API。前端用Vuex管理购物车状态，登录后进入商城页面时拉取一次购物车列表存到Vuex，商品数量变更后调用后端接口并同步更新Vuex。这样页面角标更新是响应式的，体验顺畅。
订单确认页的数据流是：从购物车勾选商品→跳转确认页→确认页展示商品列表、金额合计、收货地址→提交订单。这一页前端要做的事不少：从Vuex读取勾选中的商品数据和数量；调用地址接口列出用户已有地址，默认选中默认地址或第一条；计算总金额时价格和运费都要展示，运费规则可以简单做成满多少包邮，也可以全免邮，看业务需要；点击提交按钮后组装参数回调后端下单接口，成功跳转到订单支付页。这个流程里最需要小心的是金额计算必须以后端返回为准，前端算的总价只是展示用，后端下单时会重新校验，防止有人篡改请求参数把价格改成0.01。
4.4 页面布局与Element UI组件使用技巧
商城前端页面建议采用经典电商布局：顶部导航栏包含Logo、分类菜单、搜索框、购物车入口；中间主体区域按路由渲染对应页面；底部页脚放网站信息和备案信息。Element UI的Container布局组件提供Header、Aside、Main结构，后台管理用起来尤其顺手，前端商城页面更推荐手写或者用简单的flex布局自由搭建，不然会有一股"后台系统感"。
商品卡片列表、分页组件、弹窗确认这些用Element UI组件基本不会出问题。需要提醒的一点是日期格式化、金额格式化的统一处理，建议写一个filter.js工具，把价格保留两位小数、时间戳转成yyyy-MM-dd HH:mm:ss格式，全局注册过滤器，页面里直接用管道语法过滤，比每个组件里单独处理可靠得多。还有购物车数量加减功能，注意InputNumber组件结合自定义最小值限制，避免用户手输0或负数，后端接口同样要校验数量必须大于0，双保险。
5. 打包部署与答辩准备的完整实录
5.1 前后端打包与统一部署
项目开发完成后的部署环节，我用的是前后端打包到同一个Tomcat的方式，省事且不易出问题。
前端在项目根目录执行npm run build，构建完会生成dist文件夹，里面是静态资源文件。后端项目用Maven执行package命令生成war包，然后把dist里的内容原样复制到后端的webapp目录下（或者直接放入resources/static下），最后再把war包放到Tomcat的webapps目录启动即可。这样的好处是浏览器访问http://localhost:8080/就能看到商城首页，所有API请求都走同源，天然没有跨域问题。
部署前记得改几个配置项：后端的数据库连接、本地文件上传路径、前端里写死的接口地址改成相对路径。数据库建议用MySQL，连接参数放在jdbc.properties里，部署时只需要改这一个文件。如果预算允许，可以在阿里云或腾讯云上一台轻量服务器，装好JDK、Tomcat、MySQL，把war包扔上去，手机浏览器打开访问，演示效果比本地强太多。不少同学答辩前才想起来没试过在服务器上跑，结果各种路径问题、端口问题暴露出来，临时手忙脚乱。提前一个礼拜把部署流程走一遍，绝对值得。
5.2 真实开发中踩过的常见坑排查记录
这里把我在做这套系统时遇到的最高频问题整理成速查表，遇到了可以直接对着查：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 启动报错找不到数据源 | jdbc.properties配置错误或数据库未启动 | 检查URL、用户名、密码，确保MySQL服务已开启 |
| Mapper接口绑定异常 | XML文件的namespace与接口全限定名不一致 | 检查XML里的namespace和mapper接口包名路径是否一致 |
| MyBatis日志只显示 Preparing 不显示参数 | 缺少log4j或slf4j依赖 | 检查pom中是否有日志依赖，并在配置中开启trace级别 |
| 前端页面请求一直404 | 拦截器把路径拦了或Controller路径拼写错误 | 先看控制台拦截器日志，再看请求URL与@RequestMapping是否匹配 |
| 跨域请求被浏览器拦截 | 开发环境未配置代理或者后端未允许跨域 | 开发用devServer proxy，部署用同域方式 |
| 富文本图片上传后前台不显示 | 图片访问路径是绝对路径或磁盘路径 | 统一配置静态资源映射，图片地址用可访问的相对路径 |
| 前端部署后刷新出现404 | Tomcat没有配置SPA路由回退 | 在web.xml配置error-page跳转index.html，或后端加路由转发 |
| 用户管理页面删除报外键约束错误 | 用户表有关联数据未被清理 | 删除前先确认该用户是否有关联的订单、评论等数据 |
这8个问题基本覆盖了毕设开发周期的80%疑难杂症。记录下来不是为了背答案，而是想说明一个道理：这类问题大部分都能靠"分级排查"的思路解决，先看日志、再查配置、最后断点调试，别一开始就怀疑框架本身有问题，框架大部分时候是没问题的。
5.3 答辩讲解的切入技巧与高频追问应对
答辩是毕业设计的临门一脚，功能演示和代码讲解要有节奏。我的建议是按以下顺序演示，逻辑最顺：先打开前端商城首页，展示轮播图和商品分类导航，演示商品列表的条件筛选和分页；然后演示用户注册登录，加入购物车、结算下单、模拟支付、查看订单状态；再切换到后台管理，演示添加商品、修改库存、发货操作，然后回到前台刷新订单状态。整个流程要让评委看懂"数据从哪来到哪去"，这是核心。
代码讲解要挑最亮点的地方讲，不需要通篇讲。我一般会选三个点：拦截器的登录与角色校验实现、订单状态变更的事务处理、MyBatis动态SQL多条件查询。每个点用两三分钟讲清楚设计思路即可，不要陷入代码逐行解释的泥潭。
答辩时的高频追问基本集中在几个角度：
- 为什么不用Spring Boot而是SSM？答：课程体系以SSM为主线，且SSM配置更透明，便于理解框架核心机制。
- 密码加密方式？答：MD5加盐，并提一句生产环境推荐BCrypt。
- 如何防止SQL注入？答：使用MyBatis预编译、动态SQL参数化。
- 库存并发问题怎么解决？答：SQL条件更新配合受影响行数判断。
- 前后端交互的鉴权机制？答：Session维护登录态、后端拦截器统一校验。
每个问题回答时都要简洁、自信，最忌讳背书式背诵。提前准备一张"项目架构图"和一张"数据库关系图"，虽然不用花哨，但答辩时问题解释不清楚，直接指着图说思路，效果会好非常多。
6. 这个项目后续还可以怎么扩展
系统做成之后，如果你还想要更高的完成度，有几个方向可以延伸。一是增加评论功能，用户在收到货后可以针对农产品晒单评价，为其他用户提供参考，同时提高平台活跃度。二是增加优惠券模块，后台可以发券、设置满减门槛，用户下单时选择可用券，这块能增强系统的营销属性。三是接入真实的支付沙箱环境，比如支付宝沙箱，环境是开放的，调试起来不复杂但支付回调处理需要认真写，一旦做通，项目的含金量会再上一个台阶。
我个人在实际操作中的体会是，选这类系统作为毕设并不是因为它简单，而是因为它"熟"。大量前人踩过坑、社区里资料丰富，这意味着你遇到问题时几乎总能找到参考，不会卡死在一个bug上三天找不到方向。但同样也要警惕参考代码的陷阱，拿到的源码一定自己动手敲一遍、改一遍、加一个功能进去，哪怕只改一个字段名，也要亲手让项目从零跑通一遍。有人带着完整代码直接提交，答辩时却说不清一行自己在干什么，反而弄巧成拙。找一个安静的时间，把每个模块的请求流程理一遍，画一张数据流转图，你会发现答辩的时候整个人是笃定的。
