基于微信小程序实现医院核酸检测服务系统：从选题到落地的完整实战复盘
每年到了毕业设计的季节，总有学弟学妹过来问我："小程序方向好不好做？""医院类系统会不会太复杂？"我的回答一直是：选"微信小程序 + 医院服务"这个交叉方向，踩中了好几个评审加分项——前后端分离架构、真实业务场景、移动端交互设计、数据状态流转。这套基于微信小程序实现的医院核酸检测服务系统，就是一个典型样本：用户端预约下单、现场核销采样、报告回传查看，加上后台的管理与统计，一条完整的业务闭环。这篇内容我会从选题价值、技术选型、数据库设计、核心流程实现到部署踩坑、论文结构，完整复述一遍做这套毕设项目的思路和过程，希望能给正在选型或正在卡壳的你一些参考。
这套系统适合谁来参考？如果你打算做 Java 方向、又想在移动端有所展示，或者已经有 Web 开发基础、想往小程序方向横向扩一下，都可以把这个选题作为蓝本。项目整体难度控制在"中等偏上一点"，既不会让你两个月都写不完，也不会因为太简单被答辩老师追问到无话可说。后面我提到的所有设计、表结构、接口划分，都是我实际从零搭过的路径，并非空谈理论。
1. 选题拆解：为什么毕业设计选"核酸检测预约"能拿高分
1.1 从评审角度看这个选题的加分点
毕业设计答辩时，评委老师通常不会真的把每一行代码读完，他们看的是几个关键维度：系统是否存在真实业务问题、功能是否完整、数据流转是否闭环、有没有技术亮点。
核酸检测服务系统恰好每个点都踩中了。先说业务闭环：用户在小程序端注册登录、选择检测类型、预约时间段、生成预约订单；到院后扫预约码完成签到核销；采样完成后样本进入流转状态；实验室上传报告后，用户在小程序里查看结果。这个链条天然包含"预约 → 支付 → 核销 → 检测 → 报告"五个环节，比单纯做一个增删改查的图书管理系统有血有肉得多。
再说技术覆盖面。一个哪怕只做到中等完成度的系统，也会涉及：微信授权登录与 openid 机制、RESTful API 设计、数据库多表关联查询、订单状态机控制、二维码生成与识别、接口统一鉴权。这几样东西随便展开两三点，答辩时都有充分的技术讨论空间。
1.2 系统定位与角色划分
这个系统我最终落地的形态是"小程序客户端 + Web 管理后台"双端结构，本质上是同一个后端服务在两个端面上的投射。
系统的用户角色分三类：
- 普通用户：通过微信授权进入小程序，进行预约登记、数据填报、支付、查看报告和检测记录。
- 采样人员：使用后台或采样端对预约二维码进行核销，录入采样管编号，启动检测流转。
- 系统管理员：维护院区、检测类型、公告信息，查看预约总览和统计图表，处理异常订单。
角色划分建议按"用户、采样人员、管理员"三种，不必再细分到科室等层级。毕业设计最忌模型过重，权限只要分清"前台用户"和"后台工作人员"两个大域，业务上就不会打架。
1.3 项目的合理工作量与范围边界
在这里我要给所有打算做这个题目的同学一个非常明确的建议：不要试图做真正的支付系统。小程序端对"医院类目"的支付资质要求非常高，个人或普通学生根本申请不到微信支付接口权限。更合理的做法是做成"模拟支付"——前端生成一条支付成功的假回调，后端记录订单支付状态，而在论文里你只需说明"正式环境中应接入微信支付统一下单接口"。答辩时主动讲清楚这个替代逻辑，反而会体现你对真实工程环境的理解。
另一个边界是：真实医院的核酸检测会涉及 LIS（实验室信息系统）对接，难度极大。毕设层面我们只需内置一个报告上传入口，由管理员录入检测结果文件即可，不必编写 LIS 对接协议。这样既保留了业务完整性，又避开了无法落地的外部系统依赖。
2. 技术栈定型和项目整体架构
2.1 前后端选型时的几个现实考量
前端框架的选择上，我只推荐两条路：原生微信小程序，或者 uni-app。如果你后续有打算把代码迁移到其他移动端（比如支付宝小程序或 App），uni-app 会更香；但如果只求稳定、少踩编译器坑，就用原生小程序 + Vant Weapp 组件库。我这次用的是原生小程序，理由是毕业设计评审更认原生实现，而且微信开发者工具本身配套已经很成熟。
后端这里我在 Spring Boot 和 SSM 之间犹豫过一阵。最后选了 Spring Boot + MyBatis Plus，理由很朴素：Spring Boot 的自动配置让环境搭建成本降到最低，MyBatis Plus 的单表 CRUD、分页插件和逻辑删除特性可以省下大量重复代码。你如果对 SSM 更熟，也不是不行，只是 SSM 的 XML 配置和 jar 包版本兼容问题，会让你在最不该浪费时间的阶段浪费时间。
数据库就用 MySQL 8.0，Redis 可以作为选装项。项目初期可以不引入 Redis，用 Spring Session 存登录态；后续如果想让 token 有过期刷新机制，再引入 Redis 也不迟。
2.2 后端工程结构怎么组织
工程结构直接决定后面写论文时"系统设计"章节的展开方式。我是按常见的职责分包：
nucleic-acid-server/ ├── controller/ # 接口层，接收参数并做基础校验 ├── service/ # 业务层，处理预约状态、订单流转等 ├── mapper/ # MyBatis Plus 的 Mapper 接口 ├── entity/ # 数据库实体类 ├── dto/ # 接口入参数据传输对象 ├── vo/ # 接口返回视图对象 ├── config/ # 全局配置（拦截器、WebMvc配置） ├── utils/ # 通用工具（JWT、二维码生成、日期处理） └── common/ # 统一返回结果、异常处理、常量定义这里有个很多同学会忽略的点：接口层与业务层之间务必用 DTO 作为入参，不要直接把 Entity 暴露给前端。原因很简单——前端传的字段和后端表结构大概率不是一一对应的，比如预约创建时前端传的是testTypeId和timeRange，而表里存的是test_type和appointment_time。中间加一层 DTO 做适配，会省掉你后期成堆的字段 null 判断。
另外在返回结构上，我从一开始就定义了一个统一响应类Result<T>：
public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }小程序端统一用code判断接口是否成功，再也不用各自定义一套状态码。这也是很多企业级项目的标配写法，答辩时把这条讲出来，比较提气。
2.3 小程序端页面与目录规划
小程序前端我按"底部 Tab + 功能子页"两层结构规划：
pages/index/：首页，展示公告、检测类型入口、预约按钮pages/appointment/：预约填写页，选院区、日期、时间段、人员类型pages/order/：我的订单，按状态筛选（待签到、已采样、已出报告）pages/report/：报告详情，展示 PDF 或报告卡片pages/user/：个人中心，登录信息、常见问题
每个页面内部的逻辑尽量薄，不要把复杂判断堆在onLoad里。预约页尤其要注意日期选择器的联动——日期一变，可预约时间段就需要重新通过接口获取，这个联动逻辑建议单独封装成一个方法，避免代码写在onChange回调里一大坨。
3. 用户端与后台管理的业务流程拆解
3.1 用户端核心链路：从登录到报告查看
用户第一次打开小程序时，先用wx.login拿到临时 code，发给后端换取 openid。这里提醒一句：wx.login的 code 有效期只有 5 分钟且只能用一次，所以接口设计上必须由后端根据 code 调微信接口换取 session_key 和 openid，然后由后端自行生成业务 token 返回给小程序。不要把 openid 明文存在前端缓存里，那是一种省事但很业余的做法。
预约主流程是这样的：
- 用户进入预约页，选择"单人检测"或"混检"、采样院区、预约日期。
- 系统根据选定日期返回当天各时间段余量。这里后端要做的是"可用量 = 配置上限 - 已预约数"，而不是简单返回全部时段。
- 用户提交预约，填写姓名、身份证号、手机号，生成预约单。
- 预约成功后，前端跳到"预约成功"页，展示预约二维码，同时后端生成一条带核销标识的加密串。
报告查看是用户最关心的环节。我的实现方式是在样本状态变为"已完成"时，由后台扫描并推送报告数据到报告表，同时生成 PDF 文件存储到本地磁盘或 OSS，小程序端通过文件地址预览。为了用户体验，在报告还未发布时，订单页会显示"检测中"状态，并定时轮询（每 10 秒）请求一次订单详情接口，一旦状态变化就自动刷新。
3.2 后台管理端的核心操作流
管理后台我是用 Vue + Element UI 搭建的，但这不是重点，重点是后台的几条业务操作流：
- 预约审核流：管理员可以查看当日预约列表，异常状态可取消预约并释放名额。
- 采样核销流：用户到现场出示二维码，采样人员用手机或扫码枪扫描，核销成功后该预约状态变为"已采样"。核销接口必须做防重处理——同一个预约串不能核销两次。
- 报告发布流：实验室检测完成后，管理员选择样本编号上传报告，系统自动把报告状态置为"已发布"并记录发布时间，随后小程序端轮询到状态变化。
后台统计这一块别忽略。我没做复杂的 BI 图表，只用了 ECharts 按日柱状图展示近 7 天预约趋势、按检测类型做饼图统计占比。这两个图足以撑起论文里"系统测试与应用展示"那部分的内容，再多的就会显得画蛇添足。
3.3 状态机设计：预约单的每一步都要有迹可循
这是整个系统最值得展开讲的技术点。预约单的状态不能只用一个字段硬改，我设计了一套状态枚举：
| 状态值 | 含义 | 允许进入下一状态 |
|---|---|---|
| 0 | 待签到 | 1 |
| 1 | 已采样 | 2, 4 |
| 2 | 已出报告 | 3 |
| 3 | 已完成 | 无 |
| 4 | 已取消 | 无 |
对应的 Java 枚举：
public enum OrderStatus { PENDING(0, "待签到"), SAMPLED(1, "已采样"), REPORTED(2, "已出报告"), FINISHED(3, "已完成"), CANCELED(4, "已取消"); }每次状态流转都必须在代码中校验前置状态，比如只有SAMPLED才能进入REPORTED，如果当前状态是PENDING却收到"上传报告"请求，就应该直接抛异常。这个设计的好处不只在逻辑严谨——论文里你可以专门画一张状态流转图，作为系统设计的亮点之一。
4. 数据库表设计：关键表和字段的取舍逻辑
4.1 核心表的全局设计思路
先看整体设计思路。我把表分为三个域：用户域（用户表）、预约域（预约表、订单表）、检测域（样本表、报告表、公告表），各域通过外键关联。这样划分的优点是领域边界清晰，后续统计查询也方便。
4.2 用户表与预约表
用户表：
CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `openid` varchar(100) NOT NULL COMMENT '微信openid', `nickname` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `id_card` varchar(30) DEFAULT NULL COMMENT '身份证号', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;openid一定要加唯一索引，因为它是用户登录映射的根。手机号和身份证号是在预约时才更新的，不需要在注册时强制填写——用户体验上不做强制，数据上就不会因为用户临时退出而多出一堆半成品。
预约表：
CREATE TABLE `appointment` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '预约编号', `user_id` bigint(20) NOT NULL, `test_type` tinyint(4) DEFAULT NULL COMMENT '1单人 2混检', `hospital_id` bigint(20) DEFAULT NULL, `appointment_date` date DEFAULT NULL, `appointment_time` varchar(20) DEFAULT NULL COMMENT '如08:30-09:00', `status` tinyint(4) DEFAULT '0', `qr_code` varchar(255) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;order_no是业务主键，用户查询单号时用的就是它，我生成的格式是NA + yyyyMMdd + 四位随机数。不建议用数据库自增 id 直接展示给用户——这个细节看起来小，但在答辩时能展示出你有工程意识。
4.3 报告表与公告表
报告表：
CREATE TABLE `report` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `appointment_id` bigint(20) NOT NULL, `result_type` tinyint(4) DEFAULT NULL COMMENT '1阴性 2阳性 3待复查', `file_url` varchar(255) DEFAULT NULL, `department` varchar(50) DEFAULT NULL COMMENT '检测科室', `doctor_name` varchar(20) DEFAULT NULL COMMENT '审核人员', `publish_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有一点要注意：result_type我用了数字枚举而不是直接存汉字。这既省空间也方便做条件查询，展示时再通过字典映射成"阴性/阳性/待复查"。另外报告表不冗余存用户姓名和身份证，因为通过appointment_id关联即可查全链路信息，完全不需要反范式设计。
公告表就简单很多：id,title,content,create_time,sort。后台发布公告后小程序首页展示前三条，按sort倒序取即可。
4.4 时间段并发预约的唯一约束
预约时间段有一个非常典型的并发隐患：同一时间段名额只剩 1 个，多个用户同时提交怎么办？
最稳妥的兜底方案是在预约表上加联合唯一索引：
UNIQUE KEY `uk_date_time_hospital` (`appointment_date`, `appointment_time`, `hospital_id`)这样哪怕业务层已经做了名额判断，数据库层面也不可能出现两条完全相同的时段预约记录。双保险的意义在于：业务层的校验可能因为高并发下的时间差失效，但数据库的唯一索引永远兜底。这一点是生产环境里非常实际的玩法，写在论文里也算一个不错的"技术难点攻克"。
5. 预约核心链路实现：状态机、二维码与报告推送
5.1 微信登录换取 openid 的接口细节
小程序端调用wx.login()拿到临时 code，然后通过后端接口换取 openid。后端这段逻辑如下：
@PostMapping("/user/login") public Result<UserVO> login(@RequestBody LoginDTO dto) { String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + dto.getCode() + "&grant_type=authorization_code"; // 使用 RestTemplate 请求微信接口，解析 openid 和 session_key String openid = parseOpenid(url); User user = userService.findOrCreate(openid); String token = JwtUtil.generateToken(user.getId()); return Result.success(new UserVO(user, token)); }前端拿到 token 后存入wx.setStorageSync，每次请求在 header 里带上Authorization: Bearer <token>，后端做一次拦截器校验即可。JWT 的有效期我设成 7 天，超过了就提示用户重新登录，不用搞复杂的刷新逻辑。毕设阶段，JWT 这套方案已经明显优于 session 方案，主要是无状态、不需要在 Redis 里维护会话，后端水平扩展时也友好。
5.2 二维码生成与核销校验
预约成功后的核销串，我建议这样生成：pre = orderNo + "_" + userId + "_" + status，然后对这个字符串做 MD5 校验，加上订单号一起拼成一个核销码字符串。再通过 Google 的 zxing 库生成二维码图片，存储为一个 Base64 字符串返回给前端渲染，或者存图片地址由前端加载。
核销接口需要做的事：
- 解析二维码内容，拿到 orderNo 和 校验串。
- 对 orderNo 重新生成校验串，与前端传来的校验串比对。
- 查预约记录，判断状态是否为
PENDING（待签到）。 - 状态置为
SAMPLED，同时可能给用户推送一条服务通知。
防重核销的关键在第二步和第三步，缺一不可。别看简单，我在实际开发中见过好几个同学因为只做了第三步，导致同一个二维码可以反复核销，闹出过不少笑话。
5.3 报告状态轮询与推送
小程序端要实时看到报告结果，可以用 WebSocket，也可以用轮询。毕设项目里用轮询完全够——每 10 秒请求一次订单详情接口，共 6 次后停止。这块的设计成本极低，却让用户体验上升一个档次，值得写进论文。
另外一个更"工程化"的选择是订阅消息推送。微信小程序可以给用户发送一次性订阅消息，前提是用户主动订阅。可以做成这样：用户提交预约后弹出"是否允许接收结果通知"，一旦允许，报告发布后就能收到微信服务通知。但订阅消息的模板申请需要小程序类目支持（医疗类目），个人主体无法开通。所以毕设中还是以轮询为主，订阅消息作为扩展点叙述即可。
6. 部署与联调中的高频坑位记录
6.1 本地开发绕不开的合法域名问题
这是每个小程序新手必踩的坑：在微信开发者工具里请求本地接口，默认会被拦截，报错是"不在以下 request 合法域名列表中"。
解决办法有两个：开发期在微信开发者工具右上角"详情 → 本地设置"里勾选"不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书"；或者直接把 request 的域名在公众号/小程序后台配置为合法域名。前者适合本地联调，后者需要你有已经备案的域名。
注意：真机预览时如果还勾着"不校验合法域名"，大部分安卓机可以跑通，但 iOS 端有时会不生效。所以最终要发布体验版或者用于演示，最好还是配一个真实域名 + HTTPS 证书，这是最稳妥的方式。
6.2 开发工具的版本兼容陷阱
小程序的基础库版本差异会直接影响 API 可用性。比如wx.getUserProfile接口在旧版本 SDK 中是拿不到用户头像昵称的（现在已经被官方逐步收紧），如果你在page.json里没有声明对应的 permission 字段，弹窗授权也会异常。
我的经验是：开发时基础库调到 2.30.0 以上，并在app.json里明确配置一个最低基础库版本，低于该版本的手机走降级提示。这个处理虽然只有几行配置，但能有效避免答辩现场因为学生的手机基础库过低出现白屏事故。
6.3 后端跨域与文件路径问题
如果你管理后台用 Vue，业务接口用 Spring Boot，跨域是逃不掉的。我建议别在单个 Controller 上加@CrossOrigin，那是治标不治本，而是在 WebMvcConfig 里做全局跨域配置：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowCredentials(true) .maxAge(3600); } }注意allowCredentials(true)时，allowedOriginPatterns不能直接用*号（Spring 5.3 之后会校验），用模式串更保险。文件路径方面，报告 PDF 我存到服务器本地目录，通过一个虚拟映射/files/**映射到磁盘路径，避免静态资源被拦截器拦截导致前端加载不到文件。
6.4 身份证校验与日期处理
预约时如果不对身份证做校验，会出现乱填的脏数据。前端用正则、后端用javax.validation写自定义注解校验。日期处理上，我强烈建议所有表字段用date/datetime类型，Java 侧用LocalDate/LocalDateTime，避免使用java.util.Date和SimpleDateFormat的时区问题。这虽然是基础问题，但很多同学在答辩现场被问到"时区怎么处理"时答不上来，提前用LocalDate系列就不用担心了。
7. 毕业论文的章节安排与素材留存
7.1 论文结构的参照框架
如果你做的是这套系统，论文结构可以直接参照下面的框架，这个结构与系统开发节奏是对应上的：
- 绪论：研究背景与意义、国内外现状、论文结构安排。
- 相关技术介绍：微信小程序开发框架、Spring Boot、MyBatis Plus、MySQL。
- 需求分析：从业务流程出发画用例图、划分角色权限，给出功能需求和非功能需求（安全性、性能要求）。
- 系统设计：总体架构图、模块设计、数据库设计、接口设计。
- 系统实现：按用户端功能、后台管理功能分小节，配截图和核心代码片段。
- 系统测试：功能测试用例表、测试结果、兼容性测试、性能简述。
- 总结与展望：已完成的工作、不足与改进方向。
这里面最容易被老师翻的重点是"需求分析"和"系统设计"两章——前者要画出完整的用例图，后者要给出清晰的数据库 ER 图和状态流转图。平时开发过程中就要有意识地把这些图留下来，不要等到论文季再补，那时候补图的成本非常高。
7.2 让论文内容更扎实的三个技巧
第一，核心代码不要在论文里整段贴长代码，只贴最关键的 10 到 15 行，比如状态校验、并发防重这类的代码片段，配合小段文字解释逻辑即可，老师看的是"你懂不懂这段代码"而不是"代码贴了多少页"。
第二，每个功能模块至少配一张运行截图，截图最好统一分辨率、统一操作路径，否则排版出来非常难看。建议每完成一个小模块就随手截图存档，这是很多同学后悔没有提前做的事。
第三，测试章节别只写"测试通过"，要写清楚测试环境、测试数据和预期结果。比如"预约时段唯一性测试：并发提交 5 次请求，库中仅产生 1 条记录"，这种描述比一句带过有力得多。
7.3 源码与论文配套的目录服务设计
整个工程的目录建议分三层：前端小程序包、后端服务包、文档资料包。文档包里再放数据库脚本、演示视频、答辩 PPT。这样做的好处有两个：第一，你自己后期维护和对照代码写论文都很方便；第二，如果指导教师要求以压缩包形式提交，目录规范本身就是加分项。我当时就是把这些目录整理得很清楚，指导老师直接拿来当作班级的标准示例，省去了后续反复沟通的麻烦。
8. 答辩环节容易被追问的几个问题与应答思路
8.1 为什么不用现成的预约平台而要自研一套？
这个问题考的是需求分析能力。应答思路：医院内部的检测业务存在多院区、多类型的差异，通用平台的预约流程无法满足定制化的时段配置和报告回传要求；自研系统可以灵活控制表结构、扩展字段和状态流转逻辑，也更便于接入医院后续的其他信息化系统。可以再补充一句"系统设计时预留了扩展接口"，就能堵住追问。
8.2 用户信息安全如何保证？
身份证号、手机号属于敏感信息。应答思路：数据库层面可以对身份证号、手机号做加密存储（比如 AES），接口层只做脱敏展示（110***********1234），传输层依赖 HTTPS 加密，后端通过拦截器统一鉴权，对越权访问返回 403。这四点说出来，基本就能覆盖大多数追问。
8.3 如果并发量上升到几千，系统瓶颈在哪里？
这是开放性追问，主要看你有没有全局思维。应答思路：第一，当前 MySQL 单库单表在几千并发下性能可能出现瓶颈，可以引入 Redis 缓存热点数据（如时段余量、公告列表）；第二，预约时段接口的数据库唯一索引可以降低重复预约风险，但更好的方案是引入分布式锁；第三，静态资源（报告 PDF、图片）可以迁移到 OSS，并配置 CDN 加速。能把这三点讲清楚，这个问题的分数就稳了。
9. 复盘：做完这套系统后，我更推荐你去扩展的三个方向
如果你做完基础版本还留有富余时间，我的建议是先别急着加花哨功能，优先做这三件事：
第一，给系统加上简单的数据看板。预约量趋势、各检测类型占比、各时间段饱和度，这些维度用 ECharts 展示出来后，系统质感立马不一样，论文里也多了一张很有说服力的应用截图。
第二，把订单模块改成真实的"模拟支付 + 订单超时取消"。用户预约后 15 分钟不支付，系统自动释放名额，这个机制需要用到定时任务或延迟队列，体现的是真实业务中的"超时一致性"问题。
第三，给报告模块增加 PDF 导出和批量打印功能。这个功能不复杂，但能体现对实际业务场景的理解——医院需要定期存档检测记录，不只是给单个人看单个人的报告。
我在实际完成这套系统后最大的感受是：毕业设计的核心价值不在于做出一个"完美可用"的商业系统，而在于通过一个完整的业务闭环，把大学四年分散的课程知识串成一条线。小程序端锻炼了移动端交互和联调能力，后端锻炼了接口设计和数据库建模，论文写作则逼着你去复盘整个工程决策的来龙去脉。所以，无论这一步此刻卡在哪——是登录接口没调通，还是状态流转有 bug，都别急着丧气，顺着链路一截一截排查，答案往往就在你整理过的日志和注释里。希望这篇复盘能帮你少走几步弯路，做得比我当初更顺一些。
