最近帮一个朋友调试他做的微信小程序农产品商城项目前后折腾了好几个晚上从登录鉴权到支付回调从商品图上传到订单状态机几乎把小程序商城开发的坑都踩了一遍。这里把整个项目的设计思路、核心代码实现和调试过程中遇到的问题整理成文给正在做类似项目的开发者一点参考。这个项目不是什么花哨的Demo就是一个标准的基于微信小程序的农产品自主供销商城系统里面包含农户自主上架农产品、消费者在线下单、后台管理员审核与统计这三条核心链路。既然带了文档、PPT和源码意味着它大概率是一个毕业设计级别的完整交付物。我下面会按照实际开发的顺序来拆解为什么选这个方向、系统怎么设计、核心功能怎么实现、文档和PPT怎么组织、踩了哪些坑。1. 为什么选这个题目农产品商城的真实需求1.1 从场景痛点切入做系统之前先要搞清楚一个事农产品供销商城到底在解决什么问题如果这个定位没想清楚后面做出来的东西往往就是又一个商城Demo答辩时也很难说清楚价值。农产品的销售链条一直有个老毛病——中间环节多。产地农户的收购价被层层压得很低城市消费者买到的价格又高同时还不一定新鲜。传统电商平台虽然也有农产品频道但入驻门槛、佣金比例、流量规则对普通农户并不友好尤其是个体农户你让他去运营一个店铺学不懂也耗不起那个时间。微信小程序的出现在很大程度上改变了这个局面。用户不需要下载安装App扫码即用微信生态内直接完成从浏览、下单到支付的全流程这个门槛对农产品消费者来说足够低。对农户来说小程序后台的上架操作也比管理一个淘宝店铺简单直观得多。所以这个系统的核心定位就清晰了它是一个去中间商的撮合平台农户自主入驻、自主定价、自主上架消费者直接下单购买平台管理员做审核与监管。这个自主两个字是整个系统设计的灵魂后面所有模块都是围绕它展开的。1.2 微信小程序选型对比确定方向后技术选型是一个绕不开的问题。市面上做商城类应用可选方案无非这么几类原生App、H5网页、微信公众号H5商城、微信小程序。我给我的建议是如果目标用户群体以微信活跃用户为主且交付周期有限小程序几乎是最优解。理由三条开发成本适中前端用微信自家的WXML WXSS JS语法学习曲线比原生Android/iOS开发平缓得多一个人能同时搞定前后端。获客成本低微信扫一扫或者搜索就能进入不用引导用户去应用商店下载安装。微信支付和微信登录是现成的不用自己对接第三方支付平台支付流程的信任成本极低。当然小程序也有缺点比如包体积限制2MB主包、审核规范严格、某些接口需要企业主体资质。但这些在农产品商城这个场景下基本都能接受属于可控风险。1.3 技术栈与整体架构确定用小程序之后后端技术选型也要定下来。我当时帮他选的是Java Spring Boot MySQL原因不是因为它新而是因为它稳、资料多、招人也会。前端微信小程序原生框架自定义组件实现商品卡片、订单列表、分类导航。后端Spring Boot 2.x提供RESTful API统一返回JSON。数据库MySQL 8.x存储用户、商品、订单、评论等核心业务数据。文件存储本地文件上传目录作为图片存储通过Nginx映射访问路径。这里有一个设计要特别说明为什么不直接用云开发微信云开发确实省事数据库、存储、云函数都不用自己搭对新手极其友好。但考虑到这是一个带文档源码的完整交付项目很多院校的评审更看重传统单体架构的完整度Spring Boot MySQL的搭配在系统架构设计这一章可以写的东西更多数据库表设计、接口设计、事务处理都有内容可讲。所以最终用了传统前后端分离的方式。2. 系统整体设计从需求到模块划分2.1 角色与业务流程这个系统里有三类角色先捋清楚他们各自干什么消费者普通用户浏览商品、搜索、加购物车、下单支付、查看订单、评价商品。农户商家角色注册入驻、上架农产品、管理库存、处理订单发货/自提核销、查看销售额。系统管理员审核农户入驻申请、审核商品上架、管理商品分类、全局数据统计。为什么农户和普通用户要分开这是农产品供需场景的一个特点同一个微信用户他既可能是买菜的消费者也可能有自家的果园要卖。如果系统强制用户注册时选死身份体验就很僵硬。所以这里做了一个用户-商家的关联切换机制一个账号可以同时拥有消费者身份和农户身份登录后在个人中心可以切换也可以用同一个账号在小程序端买东西在商家后台卖东西。业务流程的主线是这样的农户提交入驻申请填姓名、手机号、身份证号、农产品品类等信息。管理员审核通过后该用户获得商家身份可以进入商家管理后台。农户创建商品填名称、分类、价格、库存、产地、图片、描述。管理员审核商品通过后商品在小程序端上架展示。消费者浏览下单生成待支付订单。用户支付成功后订单状态变为待发货快递或待自提。农户处理订单发货后填物流单号或用户到自提点出示核销码。用户确认收货后订单完成可以评价。2.2 前端页面结构与后端接口小程序端我习惯先画一遍页面清单再动手写代码。页面清单后面会直接变成答辩PPT里的系统功能结构图。用户端页面首页轮播图、分类导航、推荐商品列表、公告栏。分类页左侧分类树右侧商品列表。搜索页关键词搜索、筛选价格区间、产地、销量排序。商品详情页图片轮播、价格库存、规格选择、加入购物车/立即购买、商品评价列表。购物车页勾选商品、修改数量、结算。订单确认页选择收货地址、配送方式快递/自提、优惠计算。订单列表页按状态分Tab待付款、待发货、待收货、已完成、退款。个人中心页头像昵称、订单入口、地址管理、收藏列表、身份切换入口。商家端页面商家工作台数据概览今日订单数、今日销售额、商品总数。商品管理商品列表、上架/下架、编辑、库存调整。商品发布页表单填写商品信息、上传图片。订单处理页待发货订单列表、发货操作、核销操作。入驻申请页提交审核材料。后台管理页面Web端登录页。用户管理用户列表、封禁/解封。商家审核审核入驻申请、驳回并填写原因。商品审核审核商品、下架违规商品。分类管理增删改商品分类。订单管理全量订单查询、退款处理。数据统计近7日销售额折线图、分类销售占比饼图、TOP10商品排名。后端接口按模块划分大致是这样一组模块接口示例说明认证/api/user/login微信登录code换openid用户/api/user/info、/api/user/address用户信息与地址管理商品/api/goods/list、/api/goods/detail商品查询购物车/api/cart/add、/api/cart/list购物车操作订单/api/order/create、/api/order/list订单相关支付/api/pay/wxpay微信支付下单商家/api/shop/apply、/api/shop/goods商家业务管理/api/admin/audit/goods后台审核2.3 数据库表设计思路商城类系统的数据库表设计是有套路的但农产品商城有几个自己的特殊点需要注意。核心的表有这些用户表、商家信息表、商品分类表、商品表、购物车表、订单表、订单明细表、收货地址表、评价表、轮播图表、公告表。用户表设计时要把用户-商家身份的问题解决掉。我是用一主一辅的方式user表存所有用户的公共信息包括openid、昵称、头像、手机号单独的merchant表存商家的审核状态、入驻材料、店铺名称、店铺简介。user和merchant通过user_id关联。这样普通用户和商家在逻辑上解耦一个用户可以有0条或1条merchant记录操作起来很灵活。商品表里有几个字段容易漏on_sale上架状态0下架 1上架 2待审核。stock库存每次下单扣减要配合乐观锁防止超卖。sales销量冗余字段下单成功后累加避免每次算count。origin产地农产品很看重产地信息这个字段既是卖点也是筛选维度。is_recommend是否推荐首页推荐位。delivery_type配送方式1快递 2自提 3两者都支持。订单表设计要特别注意状态字段。农产品订单和普通电商订单有一点不同支持自提。所以订单状态机比普通商城多了一个分支。订单状态我用了一个整型字段status从0到50 - 待付款 1 - 待发货已付款快递配送 2 - 待自提已付款自提配送 3 - 待收货已发货快递运输中 4 - 已完成确认收货或核销完成 5 - 已取消 / 退款中订单明细表是必须单独拆出来的因为一个订单可能包含多种农产品而每一种的数量、单价、小计都不一样。订单主表存订单号、总金额、支付状态、配送方式、收货信息订单明细表存每一件商品的快照信息。为什么要存快照因为商品表的价格和名称是可能变化的如果用户在历史订单点开查看详情看到的价格和他下单时不一样那就是数据一致性事故。做快照是一个经验之谈。3. 核心功能实现细节边做边踩坑3.1 微信登录与用户身份绑定微信小程序的登录逻辑和传统网站的账号密码登录完全不一样。它的核心是通过wx.login获取一个临时code把code发给后端后端再拿code去微信接口换openid和session_key。openid是用户在某个小程序下的唯一标识注意是某个小程序下同一个微信用户在不同小程序下的openid是不同的。后端的登录处理逻辑是这样的PostMapping(/api/user/login) public Result login(RequestBody LoginDTO dto) { // 1. 用code调用微信接口换取openid String url https://api.weixin.qq.com/sns/jscode2session ?appid appid secret secret js_code dto.getCode() grant_typeauthorization_code; String response httpClient.get(url); String openid parseOpenid(response); // 2. 根据openid查用户没有就自动注册 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setNickname(微信用户 random(4)); user.setAvatar(Constants.DEFAULT_AVATAR); userMapper.insert(user); } // 3. 生成自定义登录态token返回给前端 String token JwtUtil.createToken(user.getId()); return Result.success(token); }这段代码里有一个很容易忽略的点普通用户是静默登录的不需要授权手机号。但很多新手一上来就调用wx.getUserProfile或者getPhoneNumber结果被微信审核拒绝理由是诱导授权。在这个项目里我建议把手机号的获取放到用户主动填写的场景里比如下单时填手机号而不是一登录就弹窗要授权。微信2022年之后对用户隐私授权的规范很严凡是超过必要范围的授权都会被驳回。这一点我在文档的系统测试部分也专门写了就是为了防答辩时被问到。登录态方面我没有用传统的Session而是用JWT生成token请求头加Authorization字段后端用拦截器做统一校验。这个方案在小程序场景里很顺手避免了自己管理Session的生命周期。3.2 农产品发布与库存管理农产品的商品发布和普通商品有个很大的不同库存的粒度。电商卖服装一个SKU是一个尺码加颜色农产品卖水果一个SKU通常就是一箱5斤、一箱10斤的规格差异。如果做成规格组合商品表就要加规格表复杂度上去了。考虑到毕设体量这个项目做的是简化版商品只有一个默认规格价格和库存都是单值页面显示每份约5斤这样的描述性信息。这不是偷懒而是农产品SKU的差异往往在斤数和包装上用文字描述比用严格的规格体系更贴近实际交易习惯。库存扣减要防止超卖。我在订单创建时用了乐观锁UPDATE goods SET stock stock - #{count} WHERE id #{goodsId} AND stock #{count}如果更新影响的行数为0说明库存不足直接给前端返回库存不足的提示。这个写法比先查库存再更新要安全得多避免了并发下两个用户同时买走最后一件商品的问题。另外还有一个经验库存字段不能减为负数。上面那条SQL里的stock #{count}条件已经保证了这一点但要记得在事务里同时更新订单表否则出现订单创建成功但库存没扣的情况对账时就会很头疼。3.3 购物车、订单与支付流程购物车模块不复杂就是一个对购物车表的增删改查。但有一个用户体验层面的小细节加入购物车时要判断商品是否已下架、是否已删除如果商品已经下架用户还在购物车里看到并提交订单后端必须在订单创建前再次校验商品状态和价格。订单创建是核心中的核心。我把它做成了一个带事务的接口流程如下校验购物车勾选的商品逐条检查商品状态和库存。计算订单总金额包含商品金额、运费、满减优惠。生成订单号插入订单主表和明细表。扣减库存。清空购物车中已结算的商品。这里有一个设计决策要说清楚订单创建和微信支付是分开的。先创建订单为待付款状态然后前端调用微信支付接口支付成功后再回调通知后端把订单状态从待付款改成待发货或待自提。微信支付接入有三个环节容易出问题统一下单后端调用微信支付API传入订单号、金额、回调地址拿到prepay_id。前端调起支付小程序端通过wx.requestPayment传入时间戳、随机串、签名等信息。支付回调微信服务器异步通知后端这个回调地址必须是公网能访问的HTTPS地址。我在调试时遇到的最典型的问题是签名错误。微信支付的所有签名都用MD5或HMAC-SHA256参数要按照字典序拼接空参数不参与签名key是商户API密钥。一旦提示签名错误不要急着反复提交先在本地把参与签名的参数按字典序列出来逐个排查。九成情况是大小写不一致或多拼了一个空字符串。支付回调还有一个坑因为回调可能重复调用所以处理回调逻辑时要做幂等判断。我加了这样一个保护// 如果订单已经是已支付状态直接返回成功不再重复处理 if (order.getStatus() ! 0) { return Result.success(SUCCESS); }这样即使微信重复回调也不会把订单状态打乱不会出现同一笔订单被处理两次的情况。3.4 自提核销与物流发货自提是农产品商城的一个特色功能。城市社区团购的农产品很多是到店自提模式用户下单后去线下提货点拿菜。这个场景在小程序里要解决的问题是用户怎么证明他买过商家怎么确认他来拿了我的实现方案是已完成付款的自提订单生成一个6位核销码用户用小程序扫码或出示核销码商家在小程序商家端输入核销码校验通过后订单变为已完成。核销码生成规则// 用订单号和随机数生成6位数字核销码 String code String.valueOf(Math.abs(orderId System.currentTimeMillis())).substring(0, 6);这个方案够用但有一个效率问题查核销码时要对核销码字段建立索引不然订单多了之后数据库查询会越来越慢。这个我在后面性能优化里会单独说。物流发货环节就简单了商家在订单列表点击发货填写物流公司名称和运单号系统记录发货时间订单状态变为待收货。用户确认收货或系统自动确认收货发货后15天自动完成后订单结束。自动确认收货是避免订单堆积的关键。没有自动收货的话很多用户收到货之后根本不会主动点确认订单会永远卡在待收货状态商家的资金结算和数据统计都受影响。我在后端用了一个简单的定时任务每天凌晨扫描发货超过15天的订单自动置为完成状态。3.5 供销数据统计与后台管理后台管理系统的数据统计页是答辩时最容易被提问的地方。因为评委一看这个页面就会问这个数据是怎么算出来的。我做的统计包括三个维度销售额统计按日聚合订单表中已支付订单的金额求每天的销售总额和订单量。SQL大概是SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, SUM(pay_amount) AS total_amount, COUNT(*) AS order_count FROM orders WHERE status IN (1,2,3,4) AND pay_time IS NOT NULL GROUP BY DATE_FORMAT(create_time, %Y-%m-%d) ORDER BY day DESC LIMIT 7分类销售占比针对订单明细表和商品分类表做联查统计不同分类下的销量和金额占比。商品排行按销量字段排序取前10名。这里有一个经验统计报表的数据不应该实时去查全量订单。虽然毕设阶段订单量小实时查没毛病但答辩时如果评委问如果数据量大了怎么办你得能接住。标准答案是这样的给统计表增加一个日汇总表每天定时任务把当天的订单数据汇总进一张统计表报表只查汇总表查几百行和查几百万行的速度天差地别。后台管理还有一个容易被忽视的点权限校验。管理员登录后生成的管理员token一定要和后端普通的用户token区分开我在JWT的payload里加了一个role字段普通用户是user管理员是admin拦截器里判断role字段是否为admin不是就直接拒绝。否则任何人拿一个普通用户token就能访问后台接口数据库就裸奔了。4. 文档PPT源码交付三件套怎么组织4.1 项目文档的写作结构很多开发者代码写得飞起一写文档就头大。这里我分享一下我帮他整理的文档结构评审老师反馈很顺。文档建议按这样的顺序组织第一章 绪论项目背景、国内外研究现状、研究内容与意义。第二章 相关技术介绍微信小程序、Spring Boot、MySQL、微信支付、Vue。第三章 系统分析可行性分析、需求分析、用例图、业务流程。第四章 系统设计系统架构图、功能模块设计、数据库设计ER图 主要表结构、接口设计。第五章 系统实现关键功能截图 核心代码块 实现说明。第六章 系统测试测试环境、功能测试用例表、测试结果、兼容性测试。写文档的时候有两个坑要避开。第一不要贴大段代码。文档是给老师看的不是给代码仓库看的每段代码只贴核心逻辑10行以内足够。第二数据库设计部分不要只贴建表SQL一定要配ER图我用的是某免费在线画图工具把表关系画出来视觉上专业度直接提升一个档次。在需求分析章节我建议采用用例图加用例描述的写法。比如登录用例描述主流程、前置条件、后置条件、异常流程这样三条链路用户、商家、管理员各写几个用例内容就很充实了。4.2 答辩PPT的结构安排PPT我是按15-20页去规划的这个篇幅正好覆盖15分钟左右的答辩展示。页数分配大概这样封面页项目名称 题目类型 答辩人信息占位。目录页。项目背景页图文各半讲清楚农产品滞销、中间环节多等痛点。需求分析页三个角色各自的需求要点用一个三列布局。技术选型页为什么选微信小程序、Spring Boot、MySQL可以做一个小表格对比。功能结构图页树状图展示用户端、商家端、管理端的功能。页面展示页小程序端关键页面截图4-6张加一句功能说明。订单流程页用泳道图展示用户、商家、系统三者的交互。支付流程页用户、小程序端、后端、微信支付的调用顺序。数据库设计页放核心表结构列表和ER图。核心代码讲解页贴登录鉴权和订单创建的关键代码块每块代码配一段文字说明。系统测试页放测试用例表包括功能测试和兼容性测试的结果。总结与展望页总结已完成的功能展望未来可以加什么推荐算法、拼团、直播带货。答辩的时候最怕什么最怕被问到一个自己没做过的功能站在那里编。所以PPT上每个功能点你都要能说清楚它在前端哪个页面、后端哪个接口、数据库哪张表。这个在准备的时候要过一遍别等到台上才发现自己对不上号。4.3 源码目录组织和部署说明源码的目录组织直接反映了你的工程素养。我建议的目录结构是这样的project/ ├── frontend/ # 微信小程序前端代码 │ ├── pages/ │ │ ├── index/ # 首页 │ │ ├── category/ # 分类页 │ │ ├── cart/ # 购物车 │ │ ├── order/ # 订单 │ │ └── mine/ # 个人中心 │ ├── components/ # 自定义组件 │ ├── utils/ # 请求封装、工具函数 │ └── app.js ├── server/ # Spring Boot后端 │ ├── src/main/java/ │ │ ├── controller/ │ │ ├── service/ │ │ ├── mapper/ │ │ ├── entity/ │ │ └── config/ │ └── src/main/resources/ │ ├── mapper/ # MyBatis的XML │ └── application.yml ├── database/ # SQL建表脚本与初始化数据 ├── docs/ # 项目文档与数据库设计说明 └── README.md有一个细节我特意做了数据库脚本scripts文件夹下放两个SQL文件一个建表一个插入初始化数据。这样别人拿到源码之后能一键复现不需要自己在那里手工补数据。部署方面因为这个项目要演示小程序端需要一个真机或微信开发者工具。后端部署有两种选择本地跑 内网穿透或者部署在云服务器上。考虑到演示时的网络稳定性我建议直接把后端部署到云服务器小程序里的API地址填服务器的公网IP加端口。用微信开发者工具调试时注意小程序必须在后台配置request合法域名否则开发调试时会报域名不合法。5. 常见问题与排查技巧实录5.1 开发调试期白屏、请求异常小程序白屏是最常见的问题百分之八十是网络请求就失败了。排查步骤我建议这样走打开微信开发者工具的调试器切到Network面板看请求返回什么。如果报url not in domain list说明request合法域名没配置在微信公众平台后台添加即可开发调试阶段也可以勾选不校验合法域名。如果报connect to server failed先确认后端服务是否启动、本地ip地址是否写对了。有个新手经常踩的坑是在真机预览时代码里的API请求地址写的是localhost。真机上的localhost指的是手机自己不是你电脑所以一定连不通。正确做法是写电脑在局域网内的IP或者干脆用云服务器地址。5.2 微信支付时签名错误或支付成功但订单未更新支付调通的标志是能拉起支付界面并付款成功但很多人在回调环节出问题。我在调试时遇到过一例支付成功后订单状态没变。排查思路是先看后端日志确认微信有没有请求回调接口如果回调根本没到检查回调地址是否是公网可访问的HTTPS且路径要和统一下单时传的notify_url完全一致如果回调到了但订单没更新看代码里是否加了幂等判断是不是订单状态已经变成已支付但又执行了一次更新逻辑被覆盖了。再补充一个细节微信支付的回调接口返回给微信服务器的应答必须是纯文本SUCCESS或FAIL不能是JSON否则微信会认为回调失败反复通知你。5.3 图片上传失败或图片不显示农产品商城对图片的依赖很高水果卖相好不好直接影响下单。图片上传用的是wx.chooseMedia选择图片然后wx.uploadFile上传到后端。不显示图片的排查顺序确认上传请求返回的URL是否正确。确认图片访问路径是否被后端拦截器拦截有些后端项目会对静态资源也做token校验导致图片加载失败。确认Nginx或Tomcat的静态资源映射是否正确。我遇到过一个很冤的问题图片上传成功数据库里存的路径也对但前端图片死活不显示。最后发现是路径少了斜杠数据库存的是upload/xxx.jpg但访问URL应该是/upload/xxx.jpg少了根路径斜杠Tomcat的默认映射就匹配不上。5.4 订单状态混乱与超卖问题如果订单状态出现跳变异常比如已取消的订单还能去支付、已完成的订单还能申请退款那问题通常出在状态更新时缺少条件过滤。我写的每条状态更新SQL都带上了前置状态条件UPDATE orders SET status 3 WHERE id #{orderId} AND status 1这样即使前端重复点击确认收货第二次更新的影响行数是0不会把已完成订单再次变成待收货。超卖问题的解决方案前文已经提过用库存乐观锁。如果你用了这个方案但测试时仍然超卖多半是事务没生效。检查一下Service类上有没有加Transactional注解以及方法是不是被同类内部的调用绕过。Spring事务是基于代理的同类内部调用不会走代理事务就不生效。5.5 小程序审核被驳回的高频原因这个项目大概率要提交审核才能正式上线即使是毕设演示也可能遇到审核。根据我的经验农产品类小程序审核被驳回的高频原因有三个类目选择不对销售农产品属于电商平台类目需要提供相应资质。如果是毕设不用实际上线但文档里要说明这一点。诱导分享页面里出现分享给好友得优惠这类诱导文案会直接驳回。授权弹窗过度登录就弹手机号授权、地理位置授权触碰隐私政策底线。建议在用户真正需要时才申请权限并写好隐私保护指引。6. 几个值得留意的经验做这类系统有些东西是代码之外但直接影响项目评分的我单独拎出来说一下。第一个是关于开发环境的。如果你用的是新版微信开发者工具它会强制检查代码里的隐私接口调用比如getUserProfile、chooseAddress这些。建议在app.json里配置好permission字段和隐私协议说明否则调试阶段就会被卡住。第二个是要重视测试用例的设计。很多开发者的测试就是手工点点点但文档里的测试用例表需要填写得很正式。每条用例包含编号、功能模块、测试步骤、输入数据、预期结果、实际结果、是否通过。按照这个格式写满15-20条用例系统测试章节的加分效果非常明显。第三个是版本管理。整个项目从开始到交付我一直在帮他维护Git提交记录每完成一个功能模块就提交一次提交信息写清楚完成商品上架功能还是修复购物车数量BUG。最后交付的源码里保留了完整的提交历史这个在导师那里会很加分说明开发过程是有记录、有节奏的。第四个是关于README。拿到源码的人第一眼看的就是README建议里面写清楚项目介绍、技术栈、目录说明、快速启动步骤、默认账号密码、常见问题。给别人省时间就是在给自己省麻烦。最后做一个小的功能扩展建议。如果时间充裕可以给系统加上一个简单的消息通知模块用户下单后通过微信订阅消息通知农户发货订单发货后通知用户收货。微信订阅消息的一次性订阅机制做起来不复杂在用户下单或操作时主动申请订阅授权后端再调用发送接口就行。这个功能既贴近真实需求又能在答辩时体现你对用户体验的思考。整个项目做下来我最深的体会是一个能演示、能讲清、能落地的系统比一个堆砌了很多炫技代码但跑不通的系统有价值得多。农产品供销这个方向本身不复杂难的是把自主供销这个核心逻辑从头到尾走通——农户能自主上架用户能自主下单管理员能把控全局三条链路闭环了这个项目的底子就稳了。希望这篇拆解能给正在做类似项目的朋友一些参考。