微信小程序校园跑腿系统全栈实战指南：从登录到订单管理

这次我们来看一个微信小程序方向的校园跑腿系统。这类项目在毕业设计、课程设计里出现频率很高，核心价值在于完整跑通“用户下单 → 骑手接单 → 配送完成 → 订单管理”的业务闭环，同时还涉及微信登录、用户鉴权、订单状态流转、后台管理等真实工程问题。相比单纯的管理系统，它多了一个小程序前端，更能体现全栈开发能力。

从项目标题能直接看到几个关键信息：基于微信小程序、校园跑腿业务、附带源码和文档报告、提供代码讲解、毕业设计版本还带万字论文和 PPT。这意味着它不是一个只讲概念的 Demo，而是一套可以拿来做毕设答辩、课程设计演示，或者作为自己学习小程序全栈开发的实战项目。如果你正准备选题，或者已经选了跑腿方向但不知道从哪下手，这篇文章可以直接往下看。

本文会围绕这个项目拆开讲：核心能力、适用边界、技术架构、本地环境准备、前后端部署启动、核心功能验证、微信登录与接口调用、资源占用与性能观察、常见问题排查，以及毕设和项目落地阶段的工程建议。整个过程尽量贴合实际开发流程，方便你照着操作。

1. 核心能力速览

能力项	说明
项目类型	微信小程序 + 后端服务的全栈校园跑腿系统
面向场景	毕业设计、课程设计、小程序实战学习
用户角色	用户端、骑手端、管理员端，三端分离
核心业务	在线下单、订单派单、接单配送、订单状态管理
微信能力	微信登录、用户信息获取、小程序端接口调用
交付物	源码、文档报告、代码讲解、毕业设计版含万字论文和 PPT
后端技术栈	常见实现为 Java（Spring Boot / SSM）或 Python（Django / Flask），以实际源码为准
数据库	常见为 MySQL，需按项目源码实际配置
部署方式	本地运行后端 + 微信开发者工具导入小程序前端
是否支持批量任务	业务层面订单批量查询和管理支持，需查看源码实现
是否提供 API	小程序端通过后端 HTTP 接口交互
适合读者	小程序开发者、毕设学生、需要快速搭建跑腿项目的人

这里要特别说明：项目标题没有明确标注后端语言版本，所以上面表格里“后端技术栈”和“数据库”我用了常见实现来表述。拿到源码后第一件事就是看 README 和后端目录结构，确认实际技术栈，再按对应方式启动。

2. 适用场景与使用边界

这个项目最典型的使用场景是两种。

第一种是毕业设计。跑腿业务本身贴近校园生活，需求清晰、模块边界明确，适合在论文里展开写“选题背景、可行性分析、需求分析、系统设计、数据库设计、功能实现、系统测试”这一整套流程。再加上微信小程序这个热点元素，答辩时可以讲的前后端分离、微信登录、接口鉴权、订单状态机这些技术点，属于加分项。

第二种是课程设计阶段的小程序全栈练习。通过源码你能学到：微信小程序端如何请求后端接口、如何处理登录态和 token、后端如何实现用户模块和订单模块、数据库表之间怎么关联。这是学校课程里比较难一次性接触完整的部分。

使用边界同样要讲清楚：

• 校园跑腿涉及用户手机号、位置信息、配送地址等隐私数据，项目仅供学习和课程设计演示，不应该直接用于未经授权的真实运营场景。
• 如果需要上线真实服务，必须确保有学校或相关管理方的合规授权，完成相应的隐私政策、用户协议，并做好数据加密和权限控制。
• 涉及在线支付、收款功能时，不能自己做一个绕过微信支付的支付流程。正规做法是申请微信支付商户号，走官方统一下单、回调、退款接口，毕设项目通常只做订单金额展示即可。
• 小程序上线发布需要微信小程序账号主体认证、ICP 备案、HTTPS 证书配置。本地开发和演示阶段，可以在开发者工具里勾选“不校验合法域名”，但上线前务必改成正式 HTTPS 接口域名。
• 使用源码前确认代码来源和授权范围，不要拿来源不明的项目直接商用。

3. 项目功能模块梳理

在写代码之前，先理解这个校园跑腿系统的业务模块。

从材料标题可以确定，核心是“校园跑腿业务”。跑腿系统通常会把角色分成三类：普通用户、骑手、管理员。围绕这三类角色，功能模块一般可以拆成下面几块。

3.1 用户端模块

用户端是小程序里最核心的入口。常见的功能包括：

• 微信授权登录，获取用户基本信息。
• 浏览跑腿服务类型，例如代取快递、代买零食、代寄文件、代排队等。
• 发布跑腿订单，填写取件地点、送达地点、联系人、联系电话、订单金额或跑腿费。
• 查看自己发布的订单列表、订单详情，跟踪订单状态。
• 对已完成订单进行确认操作，必要时联系骑手。

从材料看，这个项目附带了代码讲解，所以用户端实现时一般会重点演示“怎么调用后端接口来完成一个订单从创建到完成的状态变化”。

3.2 骑手端模块

骑手端解决的问题是“谁能接单、怎么接单、怎么完成配送”。常见功能包括：

• 骑手注册和登录，通常要填写身份信息或学号信息。
• 查看待接单跑腿任务列表。
• 抢单或接单，避免多人同时接同一单。
• 查看已接订单，点击联系用户、确认取货、确认送达。
• 查看自己的接单记录和收益统计。

接单是跑腿系统最容易出问题的模块。订单状态如果不加锁，很容易出现两个骑手同时接到同一个订单的情况。虽然毕设项目可以简化处理，但答辩时被问到“如何避免并发抢单”时，最好能说明数据库如何通过状态字段来控制。

3.3 管理员端模块

管理员端通常是后台管理系统，也有项目直接用小程序管理页面。常见功能包括：

• 查询所有用户和骑手信息，管理账号状态。
• 管理跑腿服务类型和分类。
• 查看所有订单数据，处理异常订单。
• 统计订单量、完成量、退款量等基础数据。
• 对违规用户或骑手进行封禁和解封操作。

管理员端在毕设里主要用来体现系统完整性和数据可视化管理能力。答辩时可以重点介绍订单统计的 SQL 或图表实现方式。

3.4 订单状态流转

跑腿系统最核心的是订单状态机。通常用整型字段表示：

状态码	状态说明
0	待接单
1	已接单
2	配送中
3	已完成
4	已取消
5	异常订单

这套状态流转会在用户端、骑手端、管理端都用到。设计表时要注意“状态”字段不能只存 int，最好在代码里定义常量或枚举，方便维护和排查。

4. 本地开发环境准备

小程序全栈项目和普通的 Java Web 或 Python Web 项目不一样，它需要同时准备小程序工具和后端运行环境。下面给出一套通用准备清单，具体版本以项目源码要求为准。

4.1 需要的软件环境

软件	用途	建议
微信开发者工具	运行和调试小程序前端	官方最新稳定版
Node.js	小程序项目依赖管理、部分工具链	建议 LTS 版本，约 16 或 18 及以上
JDK / Python	后端运行环境，取决于源码技术栈	如果后端是 Java 就装 JDK 8/11/17，Python 则装 3.8+
数据库	存储用户、订单等数据	MySQL 5.7 / 8.0 较常见
数据库管理工具	执行 SQL、查看数据	Navicat、DataGrip、DBeaver 均可
接口测试工具	调试后端接口	Apifox、Postman 均可

4.2 检查本机环境

打开命令行，确认基础命令存在：

# 检查 Node.js node -v # 检查 npm npm -v # 后端如果是 Java java -version # 后端如果是 Python python --version

数据库安装完成后，要能正常连接。创建一个专门的数据库，例如campus_errand，然后执行源码目录下的 SQL 脚本完成建表。

-- 示例：创建数据库，具体语句以源码 SQL 文件为准 CREATE DATABASE IF NOT EXISTS campus_errand DEFAULT CHARACTER SET utf8mb4;

注意，跑腿项目涉及中文地址、备注等字段，数据库字符集强烈建议使用utf8mb4，避免中文乱码。

4.3 准备小程序 AppID

登录微信公众平台，注册一个小程序账号。个人主体账号可以完成本地开发和预览，但部分接口如“获取手机号”可能受限。课程设计阶段使用测试号也可以，不过测试号在部分接口上不如正式 AppID 稳定。

在微信开发者工具导入项目时，需要填写 AppID。项目源码里通常会有占位符，记得替换成自己的 AppID，否则会出现“AppID 不匹配”“无法获取用户信息”之类的问题。

5. 项目部署与启动

这一部分的顺序是：先启动数据库，再启动后端服务，最后用微信开发者工具打开小程序前端。

5.1 导入数据库

找到源码目录下以.sql结尾的数据库脚本文件，用数据库管理工具执行。

# 示例：通过命令行导入 MySQL 数据库，账号密码按本机实际修改 mysql -u root -p campus_errand < campus_errand.sql

导入后检查核心表是否存在，常见的有user、rider、order、category、admin等。如果表名和项目源码不一致，说明不是这套数据库脚本，需要重新确认导入的是正确版本。

5.2 启动后端服务

后端启动方式取决于技术栈。下面给出两种常见情况的通用做法。

如果后端是 Spring Boot 项目：

# 进入后端项目目录 cd server # 打包（跳过测试） mvn clean package -DskipTests # 启动 java -jar target/xxx.jar

如果后端是 Python Django 项目：

# 进入后端目录 cd server # 安装依赖 pip install -r requirements.txt # 迁移数据库 python manage.py migrate # 启动服务 python manage.py runserver 0.0.0.0:8080

启动日志出现“Started”或“running on”字样，说明后端启动成功。默认监听端口需要看配置文件，常见是 8080、8081、8000 或 9090。

5.3 导入小程序前端

打开微信开发者工具，选择“导入项目”，目录选中源码里的miniprogram或frontend文件夹。AppID 选择自己的小程序 AppID。

如果项目使用了 npm 依赖，需要在小程序根目录执行安装：

cd miniprogram npm install

然后在微信开发者工具中点击“工具 -> 构建 npm”。这一步不是所有项目都需要，但如果你打开后提示找不到miniprogram_npm之类的目录，就需要执行。

5.4 修改接口地址

小程序端请求后端接口时，默认地址可能是http://127.0.0.1:8080或者http://localhost:8080。如果后端端口不同，需要在小程序源码里的请求封装文件中修改。

常用的请求配置文件路径类似：

// utils/request.js 或 config.js 示例 const BASE_URL = 'http://127.0.0.1:8080/api'; module.exports = { BASE_URL };

如果使用手机真机预览，需要把127.0.0.1改成电脑在局域网中的 IP 地址，并且保证手机和电脑在同一网络。后端启动时也要注意监听地址，不能只监听127.0.0.1，否则局域网设备访问不到。

更稳妥的方式是后端启动时监听0.0.0.0，例如 Spring Boot 在application.yml中配置：

server: address: 0.0.0.0 port: 8080

本地开发时小程序后台还需要把请求域名加入白名单，或者在开发者工具中勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。真机预览时如果接口不通，优先检查这个选项。

6. 核心功能测试与效果验证

项目跑起来之后，按业务链路去验证功能，顺序建议是：登录 → 发布订单 → 骑手接单 → 骑手配送 → 用户确认完成。

6.1 微信登录测试

测试目的：确认小程序能拿到code，后端能完成登录并返回登录态。

操作步骤：

1. 打开小程序页面。
2. 点击登录按钮。
3. 观察后端日志是否收到登录请求。
4. 观察小程序是否跳转到首页或返回用户信息。

成功标准：项目能正常跳转，不会再停留在登录页。常见失败情况是提示“获取登录后的微信用户失败 wx1cb4398e1413dce7。这类问题通常和 AppID、后端接口返回结构、code 解析逻辑有关，排查方法可以看本文第 9 节。

6.2 用户发布跑腿订单测试

测试目的：验证用户能否创建一个新订单。

输入示例：

• 订单类型：代取快递
• 取件地址：东区菜鸟驿站
• 送达地址：2 号宿舍楼 512
• 联系电话：138xxxx5678
• 备注：下午 5 点之后送

操作步骤：

1. 用户登录后进入下单页。
2. 填写订单表单。
3. 点击提交。
4. 去数据库查询订单表记录。

成功标准：数据库新增一条订单记录，状态为 0（待接单），用户端订单列表能看到这条数据。

失败时排查：

• 字段校验是否有误，例如手机号格式校验。
• 后端是否返回了新的订单 id。
• 数据库表是否缺少必要字段导致插入失败。

6.3 骑手接单测试

测试目的：验证骑手能否看到待接单列表，并成功抢单。

操作步骤：

1. 骑手登录账号。
2. 进入待接单列表页面。
3. 点击接单。
4. 查看订单状态变化和骑手关联信息。

成功标准：订单状态从 0 变为 1，订单表里骑手 id 有值，用户端能看到“骑手已接单”状态。

如果是课程设计答辩，这里可以重点演示：两个骑手同时点击接单，最终只有一个能成功。背后依赖的是订单状态更新语句的条件判断。

-- 示例：条件更新，防止并发重复接单（以实际实现为准） UPDATE errand_order SET rider_id = #{riderId}, status = 1 WHERE id = #{orderId} AND status = 0;

6.4 配送完成测试

测试目的：验证订单从配送中到已完成的状态流转。

操作步骤：

1. 骑手点击“确认取货”，状态变为 2。
2. 骑手点击“确认送达”。
3. 用户端点击“确认完成”。
4. 查询数据库订单状态。

成功标准：订单最终状态为 3，用户端和骑手端显示一致。

6.5 管理员订单管理测试

测试目的：验证管理端能否查看和操作所有订单。

操作步骤：

1. 管理员账号登录后台。
2. 打开订单管理页面。
3. 按时间、状态、用户筛选订单。
4. 尝试对异常订单执行取消或修改操作。

成功标准：筛选和操作都能正确返回并更新数据库。

7. 微信登录与接口 API 调用示例

小程序前后端交互的核心是 HTTP 接口。虽然具体接口路径要以项目源码为准，但登录流程基本是固定的，封装思路也通用。

7.1 小程序端获取 code

小程序端调用wx.login获取临时code，然后发给后端换取 openid 和 session_key。

// 小程序端示例 wx.login({ success: (res) => { if (res.code) { console.log('登录 code：', res.code); // 将 code 发送到后端 wx.request({ url: 'http://127.0.0.1:8080/api/login', method: 'POST', data: { code: res.code }, success: (response) => { // 后端返回 token，前端保存 const token = response.data.data.token; wx.setStorageSync('token', token); } }); } else { console.error('登录失败', res.errMsg); } } });

这里的code是一次性的，有效期很短，后端获取 openid 之后千万别在小程序端反复使用同一个code。

7.2 后端处理登录并返回 token

后端拿到code后，调用微信官方接口换取 openid。

# Python Flask 风格示例 import requests def wx_login(code): appid = "你的小程序AppID" secret = "你的小程序AppSecret" url = "https://api.weixin.qq.com/sns/jscode2session" params = { "appid": appid, "secret": secret, "js_code": code, "grant_type": "authorization_code" } response = requests.get(url, params=params) data = response.json() openid = data.get("openid") session_key = data.get("session_key") # 根据 openid 查询或创建用户，然后生成自己的 token return openid

注意，这里的appid和secret必须和小程序端使用的 AppID 一致。很多登录失败问题就是前端一个 AppID、后端云配置另一个 AppID。

如果后端是 Spring Boot，使用RestTemplate或OkHttp发起同样的请求即可。拿到 openid 后，业务表里保存 openid，同时生成一个自定义 token 返回给小程序端，后续请求都携带这个 token 完成身份认证。

7.3 小程序请求封装

项目中所有接口请求建议统一封装，方便统一处理 token、错误码和加载状态。

// utils/request.js 通用封装示例 const BASE_URL = 'http://127.0.0.1:8080/api'; function request(url, method = 'GET', data = {}) { const token = wx.getStorageSync('token'); return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method, data: data, header: { 'Content-Type': 'application/json', 'Authorization': token ? `Bearer ${token}` : '' }, success: (res) => { if (res.statusCode === 200 && res.data.code === 200) { resolve(res.data.data); } else { reject(res.data); } }, fail: (err) => { reject(err); } }); }); } module.exports = { get: (url, data) => request(url, 'GET', data), post: (url, data) => request(url, 'POST', data) };

后端接口返回格式建议统一，例如：

{ "code": 200, "message": "success", "data": { "token": "abc123", "userInfo": { "nickName": "张三", "avatarUrl": "https://xxx" } } }

统一返回结构的好处是前端解析简单，排查错误时也能从code定位问题。

8. 资源占用与性能观察

毕设项目的性能要求不需要和互联网大厂一样高，但答辩和部署阶段，性能观察依然是加分项。这套系统主要是轻量级业务，资源占用重点看三方面：后端进程内存、数据库连接、小程序端请求响应时间。

8.1 后端进程资源观察

如果后端是 Java Spring Boot，启动后可以通过命令行观察进程：

# Linux / Mac 查看 Java 进程 ps aux | grep java

或者使用 JDK 自带工具：

jps -l

启动阶段内存占用通常较高，稳定后 Java 进程一般会占几百 MB 到 1 GB 左右。如果本机内存紧张，可以在启动时限制堆内存：

java -Xms256m -Xmx512m -jar target/xxx.jar

这样能保证同时打开微信开发者工具、数据库和浏览器时不至于卡顿。

如果后端是 Python Flask / Django，进程占用通常小很多，一般 100 MB 以内。

8.2 数据库连接与慢查询

跑腿系统的核心表是订单表。随着测试数据增加，订单查询会变慢。最直接的做法是给常用查询字段加索引。

-- 示例：给订单状态和创建时间加索引 ALTER TABLE errand_order ADD INDEX idx_status (status); ALTER TABLE errand_order ADD INDEX idx_create_time (create_time);

答辩时可以这样讲：状态下拉筛选高频、按时间排序高频，所以对这两个字段建立索引来提升查询效率。这个点在数据库设计章节里很加分。

8.3 接口响应时间观察

在微信开发者工具的 Network 面板里，可以查看每个接口的耗时。正常情况下，本地开发的小程序接口请求应该在几百毫秒以内。如果超过了 1 秒，优先排查：

• 后端是否有慢 SQL。
• 是否在循环里请求数据库。
• 是否在请求中同步调用了微信接口，比如每次都请求sns/jscode2session。
• 电脑是否运行了太多开发服务导致资源紧张。

有一种常见坏味道：在订单列表接口里，循环查询每个订单的创建人昵称和头像，这就是典型的 N+1 查询。正确做法是使用 JOIN 一次性查出关联数据，或者批量查询再在内存中组装。

9. 常见问题与排查方法

这一节整理微信小程序跑腿系统开发、部署、测试阶段最常见的问题。

问题现象	可能原因	排查方式	解决方案
小程序提示“获取登录后的微信用户失败 wx1cb4398e1413dce7”	前端 AppID 和后端 AppSecret 不匹配，或 code 失效，或后端接口返回格式不兼容	查看后端日志中收到的 code，确认 AppID 配置	统一 AppID 和 AppSecret；确保 code 只用一次；检查后端返回字段是否包含 openid
真机预览接口报net::err_connection_reset	手机访问不到电脑本地服务，或接口地址用了 127.0.0.1	确认手机和电脑同一局域网，后端监听 0.0.0.0，使用电脑局域网 IP	修改 BASE_URL 为局域网 IP，例如http://192.168.x.x:8080/api
开发者工具里请求报“合法域名”错误	本地开发没有配置请求合法域名	没上线的开发阶段可在详情里勾选不校验合法域名	正式上线前配置 HTTPS 域名并设置 request 合法域名
用户登录成功但拿不到头像昵称	微信调整了用户信息授权策略，直接获取头像昵称受限	查看控制台是否有 getUserProfile 相关告警	使用button open-type="chooseAvatar"和昵称填写方式，或引导用户手动上传头像
数据库出现中文乱码	数据库字符集不是 utf8mb4，或连接串没有设置字符集	查看表结构的字符集和连接参数	建库时指定 utf8mb4，JDBC 连接串加characterEncoding=utf8
启动后端提示端口被占用	8080 或其他端口已被占用	查看日志明确报错端口，使用netstat -ano或lsof -i:8080查找占用进程	修改后端端口配置，或关闭占用进程
小程序请求接口后没有反应	后端服务未启动，或请求路径错误	先检查后端日志，再用接口测试工具直接请求接口地址	确认后端启动成功后，确保小程序的 BASE_URL 和接口路径完全匹配
订单并发接单出现重复	订单状态更新没有条件限制	查看骑手接单接口的 SQL 是否带了status=0条件	使用条件更新，或增加数据库唯一约束
前端页面渲染无数据	接口返回数据结构和前端预期不一致	在 Network 面板查看接口返回 JSON	统一前后端字段命名，注意userInfo.nickName和userInfo.nickname这类不一致问题
个别页面卡顿	订单列表一次性加载过多数据，或大量图片未优化	查看接口耗时和返回条数	增加分页查询，控制每次返回 10 到 20 条

这里重点说一下wx1cb4398e1413dce7这类登录错误。微信登录错误的errMsg经常是一长串带编号的字符串，小白看到容易慌，其实只要按链路排查就行：小程序端wx.login是否拿到 code → code 是否成功传给后端 → 后端是否成功调用微信接口换取 openid → 后端是否成功创建或查询用户 → 后端是否返回 token 给前端。任何一步断了，前端都会表现成“登录失败”。优先查后端日志，日志里会直接显示出是哪一步抛了异常。

10. 最佳实践与使用建议

项目能跑起来只是第一步，能不能顺畅地用于毕设演示、课程答辩，甚至后续扩展成完整的线上项目，还需要注意下面这些工程实践问题。

10.1 建立一套最小可运行配置

在项目目录里明确记下这些信息：

• 后端启动命令。
• 数据库名称和账号密码。
• 小程序 AppID。
• 后端端口。
• 是否需要修改小程序合法域名配置。

写进 README 或单独建一个运行说明.md。很多毕设项目过了一周自己都忘了怎么启动，这一步能省大量时间。

10.2 统一接口返回格式

后端所有接口尽量返回统一结构，包含code、message、data三个字段。前端封装好请求函数后，每次新增接口只需要关心业务数据，不需要重复处理错误。

10.3 管理好微信密钥

小程序AppSecret是敏感信息，绝对不要写在小程序前端代码里。AppSecret只允许在后端保存和使用。如果发现AppSecret泄露，及时在微信公众平台重置。

10.4 使用分页查询

订单列表、用户列表、骑手列表都建议使用分页。不要一次性查询全表返回给小程序端。常见的参数是page和pageSize，后端返回total和list。

10.5 订单状态流转要严谨

跑腿订单有多种状态，后端可以在订单表增加update_time字段，每次状态变化时更新时间。用户端展示“进行中”的订单，就可以用状态和更新时间做判断。

10.6 注意隐私和授权合规

校园跑腿会收集用户姓名、电话、位置信息，毕设阶段也要养成良好的信息保护习惯。数据库中的密码字段要加密存储，用户敏感字段不要在前端过度展示。演示时如果使用了真人姓名、号码，最好换成测试数据。

10.7 项目文件分目录管理

建议本地按下面的结构管理：

campus-errand/ ├── server/ # 后端源码 ├── miniprogram/ # 小程序前端源码 ├── database/ # SQL 脚本 ├── docs/ # 设计文档、论文、PPT └── README.md # 运行说明

这样后续做代码讲解、写部署文档、给导师展示，都会非常清晰。

11. 总结与下一步

这个校园跑腿系统最值得尝试的地方，是它把微信小程序、后端接口、数据库三者串成了一条完整链路，角色设计和订单状态流转也比较贴近真实业务。比起零散地写登录页、写增删改查，它能让你看到一个项目从下单到派单再到完成的全过程，这对毕设和课程设计来说是很有价值的项目。

拿到项目后，最先应该验证的功能不是界面漂不漂亮，而是微信登录能不能拿到用户身份、用户能不能成功创建订单、骑手能不能接单、订单状态会不会正常流转。跑通这四条链路，项目的核心价值就体现出来了。

最容易踩的坑主要在三个地方：第一是 AppID 前后端不一致，导致登录失败；第二是接口地址配置错误，导致真机预览时网络请求不通；第三是数据库字符集不是 utf8mb4，导致中文乱码。这三个坑解决了，本地开发和演示就基本顺畅了。

后续如果想继续扩展，可以考虑这几个方向：引入 Redis 缓存热门订单列表、增加消息通知推送、接入完整的微信支付流程、把管理后台做成 Web 端、增加数据可视化统计图表。对毕设来说，这些方向也是很好的加分点。

建议收藏备用，动手前先把项目结构和运行说明理一遍，再按“数据库 → 后端 → 小程序前端”的顺序启动。项目跑通之后，再根据需求去改功能和写论文，思路会顺很多。