这两年我陆续帮人评审过几十个购物类小程序相关的项目，发现"智能购物助手小程序"这类题目在校园里出现的频率特别高，但很多同学一上来就被技术栈选择卡住了：Java、PHP、Python、C#到底该用哪个？微信小程序端又该怎么搭配？还有人直接拿了一套"毕设成品"代码，却不知道从哪下手改造。这篇文章我会结合真实的项目经验和踩坑记录，把智能购物助手的核心功能、后端语言选型、小程序端开发难点、以及成品代码二次开发的思路一次讲透。
不管你是准备做毕设，还是想自己上手做一个购物助手类小程序来练手，这篇内容都值得你花十分钟认真看一遍。
1. 先别急着写代码：购物助手不是简单商城
我见过太多人把"智能购物助手"做成一个普通商城，最后答辩时被老师一句"你的助手体现在哪里"问得哑口无言。这个问题的根源在于没有搞清楚：购物助手和商城是两种完全不同的产品。
1.1 核心差异：决策工具 vs 交易闭环
商城的核心是商品管理、下单、支付、库存、物流，它要完成的是"交易闭环"。而购物助手的核心是帮助用户做"购物决策"，重点在找商品、比价格、管清单、收优惠、提醒降价。
举个例子：用户想买一台空气净化器，打开购物商城，他需要在搜索框里输入关键词，然后逐一点开商品详情、比价，最后决定买不买。这一过程其实很耗时。而购物助手要做的是：把多个来源的价格汇总成一张对比表，告诉用户某商品的历史价格走势，支持把意向商品加入购物清单，等价格降到用户的心理价位时主动推送提醒。
这两个方向对应的功能设计和数据库表结构完全不同。如果你把项目定位成"商城+购物助手"的混合体，工作量会翻倍，而且容易出现业务边界模糊的问题。我的建议是：除非论文题目明确要求做交易闭环，否则把重心放在"智能决策"上，这样更容易做出亮点。
1.2 智能购物助手的核心功能清单
结合我手里的实际项目经验，一个能顺利通过评审的智能购物助手，至少应该具备以下模块：
| 功能模块 | 核心能力 | 用户价值 |
|---|---|---|
| 微信登录 | 授权登录、session管理 | 识别用户身份 |
| 商品检索 | 关键词搜索、分类筛选、排序 | 快速找到目标商品 |
| 购物清单 | 收藏、加入清单、备注、数量调整 | 管理意向购买商品 |
| 比价展示 | 多平台/多商家价格对比 | 帮用户找到最低价 |
| 价格走势 | 历史价格记录和趋势分析 | 判断当前是否值得买 |
| 优惠信息 | 优惠券、促销活动聚合展示 | 降低购买成本 |
| 降价提醒 | 订阅消息推送、定时任务扫描 | 自动盯住价格变化 |
| 个人中心 | 浏览记录、收藏夹、设置 | 沉淀用户行为数据 |
你可以在这些模块里挑选3-4个作为核心，其他作为扩展。比如毕设时间紧张，做"商品检索 + 购物清单 + 价格走势 + 降价提醒"就是一套完整且能讲清楚的故事。
1.3 动手前先回答四个问题
很多同学拿到题目后直接开写代码，结果写了一半推翻重来。我在项目规划阶段一定会让他们先回答几个问题：
- 商品数据从哪里来？是后台手动录入、爬虫采集，还是调用第三方开放API？
- 价格多久更新一次？每次更新需要保存历史记录吗？
- 用户登录态怎么管理？token过期时间设多长？
- 系统里有没有真实支付流程？如果没有，订单模块怎么简化？
这四个问题决定了数据表数量、接口数量和工作量。尤其是第一个问题，我后面会单独讲，因为它是整个项目最容易被卡住的地方。
2. 后端选型：Java、PHP、Python、C# 到底选哪个
项目标题里提到了一连串技术栈，这正是毕设圈最常见的纠结。作为一个看过Java、PHP、Python、C#四套代码的人，我可以负责任地告诉你：没有绝对的最好，只有最匹配你目标和时间的方案。
2.1 四种后端语言的横向对比
| 技术栈 | 框架代表 | 上手难度 | 开发效率 | 资料丰富度 | 适合人群 |
|---|---|---|---|---|---|
| Java | Spring Boot | 偏高 | 中 | 极高 | 想系统学习工程化、有2个月以上时间 |
| PHP | ThinkPHP / Laravel | 低 | 高 | 高 | 想快速出Demo、重点做前端 |
| Python | Flask / FastAPI / Django | 低 | 高 | 高 | 想做推荐算法、数据采集等智能亮点 |
| C# | .NET Core Web API | 中 | 中 | 中 | 导师或团队使用.NET体系 |
先说Java。Spring Boot是后端的"标准答案"，网上教程多到看不完，遇到问题一搜就有解决方案，而且简历和面试题里Java相关的内容也是最多的。缺点是项目本身偏重，一个空项目跑起来就要装Maven、配数据库、写一堆配置类，如果只剩三周时间，会很紧张。
再说PHP。注意这里的PHP不是老式的那种写在一堆HTML里的写法，而是基于ThinkPHP或Laravel框架的API开发。PHP部署简单，很多虚拟主机直接支持，开发效率也很高。不过现代小程序后端要用JSON接口，PHP在这方面的生态虽然够用，但语言本身的工程化能力比Java弱一些，一个大型项目后期维护会有点痛苦。
Python是我个人在"智能购物助手"这类项目中最推荐的选择。理由很简单：你要做"智能"，就绕不开数据处理。Python的requests库做价格采集非常方便，pandas做价格趋势分析几乎是零成本，FastAPI写接口的效率更是接近写伪代码。而且如果后续想加推荐算法，Scikit-learn可以直接用。缺点是你需要对Python的虚拟环境和依赖管理有基本认识。
C#比较特别。从热词里可以看到，C#在很多课程设计里都在工控上位机、USB摄像头、串口通信这些方向出现，它在Windows桌面和工业控制领域确实很强。但拿它做小程序后端，尤其是要调用微信支付、微信订阅消息这些能力时，官方文档和示例多半是Java/PHP/Node/Python的，C#的样例相对少，需要自己照着手写签名和加密逻辑。我见过有个同学用C#做微信登录，调code2Session接口本来很简单，但因为验签细节没处理好，折腾了两天才通。所以除非你导师指定C#，否则优先考虑前三个。
2.2 赶时间选Python，求稳选Java
如果你问我"就两天时间应该选什么"，我会毫不犹豫告诉你Python FastAPI。一个最简单的购物助手后端只需要实现几个接口：登录、商品列表、商品详情、添加清单、获取价格趋势。用FastAPI加SQLite，一个晚上就能把核心接口全部写完。
但如果你想在项目里体现工程化，并且答辩时能讲出"缓存、事务、权限控制"这些专业词，Java Spring Boot更合适。Spring Boot自带丰富的starter，集成Redis、MyBatis-Plus都很顺。唯一的代价是开发周期。以我指导过的一个同学为例，他用Java从零搭后端，加上数据库设计和接口调试，花了大概三周；同水平的另一个同学用Python FastAPI，一周就把同样的功能做完了，剩下的时间全花在小程序端打磨UI和写论文上。
2.3 前后端交互方式：小程序天然是前后端分离
小程序端的运行机制决定了它不能像传统网站那样由后端渲染HTML页面。小程序里只有wx.request可以发请求，后端只需要提供JSON格式的接口。这其实降低了后端语言的绑定程度——你甚至可以先写一个简单的Node.js Mock服务器，把小程序端调通，再决定正式后端用什么语言。
有一个很多新手混淆的点：小程序里发请求不需要处理跨域问题，因为微信客户端内部没有浏览器同源策略的限制。真正要注意的是在小程序管理后台配置request合法域名，否则真机调试会白屏或报错。比如你在本地开发时后端跑在http://localhost:8080，电脑上用开发者工具打开可以勾选"不校验合法域名"，但手机上预览就必须填一个HTTPS的正式域名。这个我第一次就踩过，后来为了省事直接买了云服务器部署，一天的功夫都在折腾域名备案，费了不少精力。
3. 核心功能模块的落地细节：从登录到降价提醒
确定了整体架构后，真正决定项目质量的是一个个模块的具体实现。这一章我会按照一个智能购物助手的真实数据流，把登录、商品、推荐、比价、清单、提醒这几个核心模块的技术细节串联起来。
3.1 微信登录：code换openid，别把session_key下发到前端
微信小程序登录不是让你拿用户名密码，而是靠微信的code2Session机制。小程序端调用wx.login()拿到一个临时code，把它发给后端，后端再用这个code去微信接口换openid和session_key。
我见过一个常见错误：有些教程直接把session_key返回给前端存起来。这是不对的。session_key是微信用来解密手机号、运动数据等敏感信息的会话密钥，它只应该留在后端。正确的做法是后端拿到openid后，确定用户身份，然后生成你自己的token（可以是UUID，也可以是JWT）返回给前端。前端后续所有请求都带上这个token，后端通过它识别是哪个用户。
核心登录流程如下：
# Python FastAPI 示例 @app.post("/api/login") async def login(code: str): # 1. 用 code 换 openid 和 session_key resp = requests.get( "https://api.weixin.qq.com/sns/jscode2session", params={ "appid": APPID, "secret": APP_SECRET, "js_code": code, "grant_type": "authorization_code" } ).json() openid = resp.get("openid") if not openid: raise HTTPException(status_code=400, detail="登录失败") # 2. 查数据库，不存在则创建用户 user = db.query(User).filter(User.openid == openid).first() if not user: user = User(openid=openid, nickname="微信用户") db.add(user) db.commit() db.refresh(user) # 3. 生成自定义 token token = uuid4().hex # 存 Redis，设置过期时间，比如 7 天 redis.set(f"token:{token}", user.id, ex=7 * 24 * 3600) return {"token": token, "user_id": user.id}还有一个细节：微信现在不再默认向我们开放用户的头像和昵称，需要用户在页面上点击头像昵称填写组件来主动授权。这就意味着你登录后不能想当然地显示"获取用户头像"，要做一个引导用户填写的表单。
3.2 商品数据：自建表加采集，别把爬虫放进主链路
智能购物助手没有真实商品数据就没有灵魂，但商品数据恰恰是最麻烦的。我建议把商品数据来源分成三层：
第一层是管理后台手动录入，这是毕设和中小型项目的安全底座。你可以自己往数据库里灌二三十条演示商品，每条商品有标题、图片URL、类目、价格、商家等字段。第二层是定时采集，写一个独立的Python脚本去模拟浏览器请求网页，解析价格后写入数据库。第三层才是第三方开放API，但这需要申请权限，通常不是学生能轻松拿到的。
在动手写代码之前，需要先设计商品和价格两张表。下面是我常用的简化版表结构：
CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(255) NOT NULL, category_id BIGINT NOT NULL, image_url TEXT, detail TEXT, price DECIMAL(10,2), source VARCHAR(32) DEFAULT 'manual', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE price_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, price DECIMAL(10,2) NOT NULL, record_date DATE NOT NULL, source VARCHAR(32), UNIQUE KEY uk_product_date (product_id, record_date) );price_record表专门用来记录历史价格，这是做价格趋势图和"建议购买指数"的数据基础。每当你从采集源拿到一个新的价格，就往price_record插入一条，同时更新product表里的当前价格。这样很容易就能画出一条价格曲线。
有的同学想用爬虫爬真实电商平台的价格，我必须提醒一句：电商平台都有严格的反爬机制，包括验证码和IP封禁，而且把外部抓取写进主链路会让整个系统变得极不稳定。最稳的做法是：采集脚本独立运行，采集结果落到数据库，小程序端永远只读数据库里的数据。即使采集失败，也不会影响前端展示。
3.3 "智能"推荐：不一定要深度学习，把逻辑讲清楚就行
很多同学看到"智能"两个字就想到人工智能，觉得自己必须搞一个神经网络模型。实际上本科毕设里，一个结构清晰的推荐逻辑比黑盒模型更容易拿分。
我推荐一个能快速落地的推荐方案：基于用户行为的标签加权。给每个商品打上标签，比如"数码""小家电""4000-5000元档""高性价比"，然后记录用户浏览、收藏、加入清单的行为，统计用户对各类标签的偏好权重，最后根据权重排序推荐商品。
举个例子：用户A浏览了3次扫地机器人、收藏了2件智能家居产品、把一款吸尘器加入了购物清单，系统就会计算出用户对"智能家居"类目的偏好度高，推荐时把同类商品排到前面。代码实现很简单，核心就是统计和排序，几分钟就能写完，但答辩时你可以清楚讲出"特征来源-权重计算-排序结果"的完整链路。
如果想更进一步，可以把价格因素也纳入进来。比如计算商品当前价格与历史平均价的比值，越低越优先展示，这在购物助手里就是硬核功能了。用Python写这样一个推荐引擎不复杂，核心逻辑不超过50行。
3.4 购物清单：推荐用清单表加详情表
购物清单和购物车看起来一样，但设计意图完全不同。购物车面向"即将结算"的购买流程，强调数量和勾选状态；购物清单面向"我可能想买"的意向管理，强调备注和排序。如果不需要下单支付，用下面这套表就够了：
CREATE TABLE shopping_list ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, name VARCHAR(100) DEFAULT '默认清单', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE list_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, list_id BIGINT NOT NULL, product_id BIGINT NOT NULL, remark VARCHAR(255), sort_order INT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );一个用户可以有多个清单，比如"家电清单""送人的礼物清单"，每个清单下挂多个商品。这样比传统购物车灵活得多，也更能体现"购物助手"的产品定位。
3.5 比价展示与优惠券聚合：注意数据的时效性
比价功能要展示同一商品在不同平台的价格，最简单的实现方式是给product表增加source和price字段。更完整的设计是有多个vendor_price记录，按商品ID和时间维度存储。
比价数据必须有时间戳，因为价格是动态变化的。我建议在接口返回时带一个"更新时间"，前端展示"3小时前更新"之类的文案。优惠券聚合这块，因为电商平台的优惠券接口不公开，实操上最好是做"演示数据"。明确标注数据是模拟的，不要伪造真实的优惠信息。
3.6 降价提醒：微信订阅消息的"一次性"限制
降价提醒是购物助手的点睛功能，但很多同学卡在了微信订阅消息的机制上。用户需要先主动点击"订阅提醒"按钮，授权后，你的后端才能给他发一次订阅消息。发完一次，这个授权就失效了，用户需要再次订阅才能收到下一次提醒。
所以正确的产品逻辑是：用户设置"目标价格" -> 用户点击授权订阅 -> 定时任务扫描价格 -> 价格低于目标价时发送一条订阅消息。这里有一个很关键的表design：
CREATE TABLE price_alert ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, product_id BIGINT NOT NULL, target_price DECIMAL(10,2) NOT NULL, status VARCHAR(20) DEFAULT 'active', created_at DATETIME DEFAULT CURRENT_TIMESTAMP );定时任务用Spring Boot里的@Scheduled或者Python的APScheduler都可以。扫描时只需要查目标价大于等于当前价格的记录，然后调用微信接口发订阅消息。注意订阅消息的模板ID需要在小程序管理后台申请，而且模板里的字段名必须和代码里传的参数一致，否则发送会报错。
4. 小程序端开发：列表加载、自定义导航和抓包调试
后端接口写好后，小程序前端的开发质量直接决定了项目观感。这一部分我整理了小程序开发中几个最容易出问题、也最常被问到的技术点。
4.1 页面列表加载更多：onReachBottom的经典坑
"加载更多"几乎是每个列表页的标配。微信小程序里最简单的分页逻辑就是在onReachBottom事件里请求下一页数据。这个原理很简单，但实操时至少有三个坑：
第一个是并发锁缺失。用户快速上拉时，onReachBottom可能连续触发多次，导致同一页数据重复请求。解决办法是加一个isLoading标志，在请求完成前直接return。第二个是页码错乱。正确做法是请求发出前记录当前page，成功后再setData拼接数据。第三个是数据去重。用page和size分页时，如果数据在请求间隙发生了变化，可能出现重复项，推荐在拼接前用product_id做一次过滤。
一个稳妥的加载更多逻辑大概是这样的：
let page = 1; let isLoading = false; let hasMore = true; async function loadProducts() { if (isLoading || !hasMore) return; isLoading = true; wx.showLoading({ title: '加载中' }); const res = await request.get('/api/products', { page, size: 10 }); const list = res.data.list; this.setData({ products: this.data.products.concat(list) }); hasMore = res.data.hasMore; page += 1; isLoading = false; wx.hideLoading(); }还有搜索功能的用户体验问题。我在一个实际项目里看到，搜索接口连一个空输入都不处理，用户一按搜索就报错。搜索一定要做参数校验、模糊匹配（数据库里用LIKE %关键词%），还要有"无结果"的空态提示。
4.2 自定义导航栏：标题往哪放、胶囊按钮怎么对齐
小程序默认导航栏只能显示标题文字和返回箭头，样式很受限。想要更美观的设计，通常需要自定义导航栏。配置方式是在页面JSON里加"navigationStyle": "custom"，然后就代表导航栏完全由我们自己画。
此时要注意：自定义导航栏需要预留状态栏高度。不同手机状态栏高度不同，要用wx.getWindowInfo()获取statusBarHeight，还要用wx.getMenuButtonBoundingClientRect()获取右上角胶囊按钮的位置。胶囊按钮无法隐藏，所以做自定义导航时一定要把标题放在不遮挡胶囊按钮的地方。处理不好，标题会和胶囊按钮挤在一起，特别难看。
4.3 Charles抓包调试：怎么把它用在开发冲刺阶段
开发小程序时，经常需要看小程序到底向后端发了什么请求、收到了什么响应。Charles是一个非常经典的抓包工具，网上教程也很多。要用它抓小程序的HTTPS请求，需要在小程序端和电脑同时配置代理，再安装Charles的SSL证书。
如果抓不到包，先检查这几项：代理是否设对了端口（默认8888）、SSL Proxying是否开启了、系统是否拦截了证书。还要注意，小程序开发者工具本身有Network面板，其实不借助Charles也能看大部分请求。只有在真机调试、需要看第三方SDK发出的请求时，Charles才更有效。调试完记得关闭代理，否则手机会无法上网。
这一节我不想写太多细节，因为工具的使用方法到处都能搜到，我真正想提醒的是：抓包只能用于调试自己开发的项目或自己参与的接口调试，不要在线上环境去抓取无关服务的敏感数据。
4.4 uniapp打包微信小程序的配置细节
如果你不是用原生的微信小程序开发，而是用uniapp写了一遍代码，再打包成微信小程序，有几个配置必须提前检查。
manifest.json里要填正确的微信小程序appid，不然开发者工具打不开。tabBar的图标路径必须是本地路径，不能是网络URL。手机预览时，如果后端接口用的是HTTP且没走证书，需要在微信开发者工具的右上角详情里勾选"不校验合法域名"。还有一个经典坑：uniapp的样式在小程序端会有样式隔离，使用rpx做单位时，不同设备的渲染结果会有差异，尽量在真机和开发者工具两边都过一遍。
在"腾讯应用宝获取通用小程序code"这个热词背后，其实是关于小程序code获取场景的疑问。普通微信生态里，wx.login获取code就够了；应用宝里的"通用小程序"是另一个入口，需要走专门的JS-SDK，跟普通小程序开发不是同一套流程。这个问题偶尔会在答辩时被问到，知道区别就行了。
5. 毕设定制与成品改造：如何让代码变成自己的
项目标题里特意提到了"毕设程序定制/毕设成品"，针对的正是那种不想从零做起、想拿一套成品代码改造的同学。我可以直接说：成品代码能不能用，取决于你会不会读代码、敢不敢动手改代码。直接跑通就交差，危险很大。
5.1 拿到成品代码后的第一步：按这个顺序读代码
我拿到任何一套陌生代码，第一件事不是npm install，也不是启动项目，而是按顺序读三类东西：
- 数据库建表脚本。所有表的字段和注释能让你最快理解业务模型。
- 后端路由接口清单。每个URL对应哪个Controller，请求参数是什么。
- 小程序端的请求封装。api目录下的request.js或utils如何管理baseURL和token。
先把这三件事做完，再去看登录流程和核心业务模块。这样你能在30分钟内建立起"页面-接口-数据库"的完整映射关系，答辩时老师点到任何一处都能接上话。
5.2 消除代做痕迹的五个操作
很多成品代码都有明显的模板痕迹，不改的话一眼就被看出来。我通常会执行以下五个步骤：
- 全局搜索替换项目英文名。把模板里的项目缩写换成自己的项目名，包括package名、数据库名、页面Title。
- 清理文件头注释。把作者信息、原始链接、模板说明删掉。
- 简化无用的复杂代码。尤其是那种明显是炫技但用不到的功能，删除前记得先确认没有接口引用。
- 给核心代码加中文注释。注释不是说废话，而是写清楚"这段代码的作用是什么、为什么这样写"，这能逼自己真正理解代码。
- 统一代码风格。把缩进、命名、换行改成一致的规范，至少看起来是自己日常写的。
5.3 答辩前必须能回答的三个问题
第一个问题："整个项目的数据流程是什么？"你要能讲清楚用户在小程序里点了一个按钮，请求走到哪个Controller、操作哪张表、返回什么数据。
第二个问题："你的数据库为什么这样设计？"每一张表的存在理由都要说得出来。比如price_record就是为了保存历史价格，支撑趋势图。
第三个问题："你项目的亮点功能核心逻辑是什么？"如果是推荐功能，就讲标签加权怎么算；如果是比价，就讲价格数据来源和更新策略。老师真正想听的，是你真的理解自己的核心代码。
5.4 低成本加一个亮点模块，让答辩有得聊
我发现，最容易让答辩老师眼前一亮的，往往不是功能多复杂，而是"想清楚了一个小问题"。这里分享一个我强烈推荐的亮点思路：建议购买指数。
这个指数可以这样定义：假设某商品历史平均价是3000元，当前价格是2600元，那建议购买指数就是（1 - 当前价/历史均价）的百分比，或者反过来。指数高于一定阈值时，小程序里显示"建议入手"的标签。用一张折线图展示给用户，同时后端只需要一个聚合查询就能算出历史均值和标准差，代码量极小，但可以展示数据分析和产品设计能力。
6. 实测走过的弯路：并发、第三方依赖和日志
最后一章，我想写几个真正影响过项目稳定性的细节。这些不是教科书里的内容，而是我在实际项目里花过时间才想明白的东西。
6.1 "抢券"的并发：没有锁一定会超卖
如果你的购物助手里有优惠券领取、限时抢购功能，就一定会遇到并发问题。最简单的场景：库存剩1张券，两个用户同时点领取，都可能领到，最后库存变成-1。解决办法是用乐观锁。更新库存时带上版本号：
UPDATE coupon_stock SET stock = stock - 1, version = version + 1 WHERE id = 1 AND version = 5 AND stock > 0;如果更新的影响行数为0，说明版本号不匹配，就返回"数量不足"。乐观锁在低并发场景下完全够用，也比引入Redis分布式锁简单得多，很适合毕设项目的体量。
6.2 外部接口永远不要放在主链路里
曾经有人把价格采集直接放在商品详情的同步调用里，用户一进详情页，后端就去抓第三方网站，结果第三方网站超时，整个小程序接口卡了20秒。这种设计就是给自己埋雷。外部接口应该通过定时任务异步更新数据，更新结果写进本地数据库，小程序端永远只查本地库。哪怕某个外部接口连续几天失败，本地数据仍然是可用的。
如果你打算做数据采集，热词里提到的"php ocr识别验证码"这一类技术可以作为论文创新点来写，但不要把它做进核心购物流程。因为验证码识别本身就有不确定性，一旦失败率太高，逻辑链就断了。
6.3 统一返回结构：代码里最值得抄的规范
最后一个保命技巧，是约定一个统一的接口返回结构。我习惯用这样一套：
{ "code": 200, "message": "ok", "data": { } }code为200表示成功，其他都是业务错误。小程序端在request封装里统一拦截：
function handleResponse(res) { if (res.data && res.data.code === 200) { return res.data.data; } else { wx.showToast({ title: res.data.message || '请求失败', icon: 'none' }); throw new Error(res.data.message); } }这样写的好处是错误处理逻辑只写一次，所有接口都复用。后端不管哪个接口出错，返回格式也是一样的。我在给项目做代码评审时，第一眼看的就是返回结构是不是统一。统一的项目，维护起来会舒服很多，答辩时也能当做一个工程化亮点来讲。
还有一个调试保命技巧：在微信开发者工具里开启vConsole。真机上出现白屏或者请求异常时，vConsole能看到前端日志和网络请求返回，比盲猜快太多了。后端接口层一定要打日志，记录请求入参、处理耗时、返回状态。没有日志，出了问题就像黑箱排查，会非常痛苦。
