1. 项目背景与整体设计思路

这个选题我第一眼看到就想拍大腿，典型的"技术栈好看+业务能落地"型毕设题目。Spring Boot做后端接口，Android做前端移动端，中间再配上MySQL存数据，一套完整的家教服务平台就出来了。你说它是管理系统，其实本质上是一个双向匹配的在线平台——家长端找家教、家教端接单子，中间夹杂订单、评价、排课、结算这一条完整的业务链。

先聊聊为什么这个题适合做毕业设计，因为它的复杂度刚好卡在"能把你和其他人区分开"的位置。你要是只做一个普通的CRUD管理系统，老师一眼就能看穿，但加上订单状态机、教师等级认证、家长评价体系之后，整个系统的业务完整性立刻不一样了。而且Spring Boot + Android这个组合本身就自带话题性，答辩的时候老师问什么你都能接得上话。

再说说场景怎么拆。一个合格的家教平台至少要覆盖三类角色：管理员、家长、家教老师。家长端要能浏览老师列表、按科目筛选、看评分、下单预约；家教老师要能上传资质、管理自己的课程时间、接受或拒绝订单；管理员则要负责审核老师资质、处理投诉、统计平台数据。这三条线合在一起，才是完整的"家教管理系统"，缺了任何一条线都只是半成品。

从技术演进的角度看，其实现在很多人会纠结要不要用小程序替代Android端，我的看法是：毕设直接用Android原生就行，原因后面工具选型部分详细说。这里先明确一个共识——做这个项目的核心目标不是真的上线运营，而是通过一个完整的全栈项目展示你对"前端交互+后端接口+数据库设计"的整合能力。

2. 技术选型与核心原理

2.1 Spring Boot 3.x + MyBatis Plus 的组合逻辑

后端我推荐直接用Spring Boot 3.x配合MyBatis Plus，这是目前Java系毕设里的主流搭配。Spring Boot负责把整个Web服务的骨架搭起来，内嵌Tomcat，一行代码都不用配就能跑起来，这对时间紧张的毕业生来说太友好了。

MyBatis Plus相比纯MyBatis的优势在于单表CRUD根本不用写SQL，BaseMapper里那些insert、selectById、updateById直接拿来用，省下来的时间都够你把订单状态机多写两个状态了。不过我要提醒一句：MyBatis Plus不是万能药，多表关联查询老老实实自己写XML里的SQL，别硬套它那个Wrapper，很多时候查出来的字段对不上会让你排查到怀疑人生。

接口设计上走RESTful风格，统一返回Result对象（code + message + data），Android端拿到这个结构体再解析，协作效率会高很多。权限认证用JWT，登录成功后颁发一个有效期为24小时的token，Android端保存到SharedPreferences里，每次请求带上Authorization头就行。为什么不用Session？Android端不像浏览器会自动管理Cookie，用JWT免去了很多会话同步的麻烦，而且天然支持无状态扩展，这点在答辩的时候可以拿出来说。

2.2 Android原生开发到底选Java还是Kotlin

现在去搜Android开发相关内容，铺天盖地都是Kotlin，但我不建议毕设一上来就啃Kotlin，除非你之前已经用Kotlin写过项目。原因是大部分学校的Android课程还是用Java教的，你需要在短时间内同时搞明白Activity生命周期、RecyclerView适配器、网络请求回调这几个硬骨头，没必要再叠加一门新语言的认知负担。

当然，你完全可以最后冲刺阶段把代码重构成Kotlin，这属于锦上添花。但核心逻辑用Java写完并且能跑通，比什么都强。Android端架构上我建议MVP就够了，Activity当View层，Presenter负责业务逻辑，Model管数据。MVVM也行，但LiveData + ViewModel这套组合对于毕设来说有点over-engineering，你还要处理生命周期绑定的细节，时间不划算。

网络框架用OkHttp + Retrofit。Retrofit的注解式接口定义方式非常适合这种前后端分离的协作模式，后端接口一定义好，Android端照着接口文档写interface就行，自动把JSON解析成Java对象。JSON解析就用Gson，简单直接，都是Java系的东西，配合格外顺畅。

2.3 数据库选型和表结构设计的第一性原理

MySQL 8.0是标配，这没什么好纠结的。关键在于表结构怎么设计——这决定了你的业务逻辑是清晰还是混乱。我见过太多人做毕设时随手下两张表就开始写代码，结果到后面订单状态一复杂，整个系统直接崩盘。

一个家教平台的核心表我建议至少包含这些：用户表（user）、老师详情表（teacher_info）、科目表（subject）、老师科目关联表（teacher_subject）、订单表（order）、排课表（course_schedule）、评价表（review）、收藏表（favorite）、公告表（notice）。这些表之间的外键关系要不要物理外键？我建议不要，逻辑外键就够了。毕业设计阶段物理外键的维护成本大于收益，而且你答辩时完全可以说"生产环境通常禁用物理外键以保证扩展性"，这反而是加分项。

订单状态这块单独强调一下：用int类型存状态码，0待支付、1待上课、2已上课、3已完成、4已取消、5退款中。不要直接存字符串，状态码配合常量类或者枚举类使用，可读性照样高，而且后续要统计"所有退款订单"这种数据的时候，写SQL会舒服很多。

3. 后端核心模块设计与实现

3.1 基于JWT的登录认证与角色权限控制

登录这块是整个系统的入口，做得不好后面全崩。我的方案是：登录接口接收手机号和密码，校验通过后用JJWT库生成token，token的payload里塞userId和role字段（1管理员、2家长、3老师），然后返回给客户端。后续请求通过拦截器解析token，把用户信息放到ThreadLocal里，业务层随时能拿到当前操作人。

角色权限控制用一个自定义注解@RequireRole，配合Spring拦截器在handler执行前做校验。比如发布公告这个接口标注@RequireRole(1)，家教接单接口标注@RequireRole(3)，家长下单接口标注@RequireRole(2)。代码看起来是这样：

@PostMapping("/order/create") @RequireRole(2) public Result<String> createOrder(@RequestBody OrderCreateRequest request) { // 业务逻辑... }

拦截器里先解析token，再检查当前用户角色是否匹配注解要求，不匹配直接返回403。另外密码存储必须用BCrypt加密，spring-security-crypto这个依赖单独拎出来用就行，不需要引入整套Spring Security。BCrypt有个特点：每次加密同一个密码得到的密文都不一样，因为内部带了随机盐，这比MD5那种固定哈希值安全一个数量级。

3.2 家教检索的核心算法与实现

家长端最核心的功能就是搜索家教，这决定了平台的使用体验。我的实现逻辑是：按科目id + 区域 + 价格区间 + 综合评分做组合筛选，分页返回教师列表。综合评分的计算是，(科目匹配分数×0.4 + 教龄分数×0.2 + 评价分数×0.4)，每个维度都归一化到0-5分，用这个算出来的分数做排序。

这个算法的关键在于打分的规则要讲得清楚，答辩的时候这是重点展示环节。你在代码里封装一个ScoreCalculator类，从teacher_subject表里取科目匹配度，从teacher_info里取教龄，从review表里AVG出评价分，然后按权重加总。排序整合在SQL里做也行，但如果在Java层计算，你就必须注意N+1查询的问题——每个老师都要查一次评价表的话，10个老师就是11次查询。我当时是先把教师列表一次性查出，再按id批量查相关数据，内存里做匹配，性能至少快3倍。

3.3 订单状态机与排课冲突校验

订单是整个平台的主线，我用一个简单的状态机来管理：待支付（0）→ 待上课（1）→ 已完成（2），待支付超过30分钟自动取消，家长可以主动取消待支付和待上课状态的订单，上课完成后双方确认，订单进入已完成状态，此时家长才能评价。

每次创建订单前必须要做排课冲突校验，这是很多粗制滥造系统会漏掉的地方。校验逻辑是：查询老师在该时间段（开始时间到结束时间）是否存在时间重叠的已接订单或已排课记录，存在一律拒绝创建订单。SQL这样写：

SELECT COUNT(*) FROM `order` WHERE teacher_id = #{teacherId} AND status IN (1, 2) AND #{endTime} > start_time AND #{startTime} < end_time

这个重叠判断条件很经典，两个区间[a,b]和[c,d]存在交集，只要满足c < b且a < d即可。我在第一次实现时写成了"start_time BETWEEN #{startTime} AND #{endTime}"，结果漏掉了订单完全包含已有排课的情况，后来才发现这种写法只覆盖了一部分重叠场景。改成交集条件后，各种边界情况全部覆盖了。

3.4 评价系统与教师评分动态更新

评价表的设计要精细一点：id、order_id（一个订单只能评价一次，所以这个字段加唯一索引）、rating（1-5分）、content、create_time。家长提交评价后，transaction里要同时做两件事：插入评价记录、更新老师的综合评分。评分字段放在teacher_info表里冗余存储，这样列表页展示老师评分就只需要查教师表，不需要每次都聚合review表。

但这里有个体验细节容易忽略：评价必须要在订单完成后7天内提交，超过时间就锁定不能再评。这个限制一方面防止恶意刷评价，另一方面也督促家长及时反馈。在代码上就用一个update语句配合时间条件来控制，写起来很轻量。

4. Android端核心模块与实现

4.1 项目架构与Navigation底部导航设计

Android端我遵循单Activity多Fragment的设计，主界面一个MainActivity，底部三个Tab：首页（找家教）、订单（我的订单）、我的（个人中心）。Fragment之间的切换用FragmentManager + FragmentTransaction，不需要引入Navigation组件——那个对毕设来说配置太繁琐，而且你现在不熟的话踩坑成本太高。

底部导航栏用BottomNavigationView，菜单资源里定义三个item，每个item对应一个Fragment的tag，切换时show/hide而不是replace。为什么这么做？因为replace每次都会重新走一遍Fragment的生命周期，导致网络请求重新执行，用户翻个Tab回来数据全部刷新一遍，体验非常差。show/hide的方式能保留Fragment的状态，实测滑动列表位置不会被重置。

4.2 Retrofit网络层封装与响应统一解析

Android端网络层是整个项目最容易写乱的地方。我的做法是：定义ApiService接口，用注解声明后端所有接口，然后用Retrofit.Builder创建实例，配合GsonConverterFactory做JSON转换。统一的响应体Result 在Android端也用对应结构体映射，解析完判断code是否为200，不是就直接toast提示后端返回的消息。

网络请求的异步处理用Retrofit的Callback机制就好，不要因为图新鲜去引入RxJava。那会让数据流变得复杂，而且你如果之前没接触过响应式编程，光理解Observable和Observer的关系都要花不少时间。Callback虽然写起来显得啰嗦，但逻辑清晰——onResponse处理成功、onFailure处理失败，很适合这个项目。

两三年前我帮人排查过一个bug，用户上传头像后图片一直没显示，查了半天发现是Android 10+对文件访问权限收紧，直接用file://协议打开相册选中的URI会崩溃。解决方案是用ContentResolver把URI拷贝到应用私有目录，再交给Glide加载。这个坑新手必踩，毕设里做头像上传功能时一定要提前处理。

4.3 教师列表展示与筛选交互设计

教师列表页用RecyclerView + CardView的组合，每个item展示老师的头像、昵称、主教科目、教龄、综合评分和价格。筛选条件用BottomSheetDialog弹出面板，里面放科目、区域、价格范围等选项，点击"确定"后重新请求列表接口。

滑动加载更多用RecyclerView的OnScrollListener实现，监听最后一个可见item的位置是否接近总数，是就加载下一页。这里有个细节：需要加一个isLoading标志位防止重复请求，否则用户快速滑动时可能同时触发多次分页请求，数据顺序就乱套了。每页我设20条，一屏刚好放5个卡片，滑动两三屏才触发一次加载，交互节奏刚刚好。

5. 数据库设计实战与核心建表语句

5.1 核心表结构全解析

把完整的建表SQL都贴出来不现实，挑几张核心表说。用户表是最基础的，字段包括id、phone、password、role、nickname、avatar、status、create_time。这里phone要加唯一索引，platform登录直接绑定手机号，不搞邮箱注册那套复杂流程。

订单表的字段设计直接决定业务逻辑好不好写：

CREATE TABLE `order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `parent_id` bigint(20) NOT NULL COMMENT '家长用户ID', `teacher_id` bigint(20) NOT NULL COMMENT '老师用户ID', `subject_id` bigint(20) NOT NULL COMMENT '科目ID', `start_time` datetime NOT NULL COMMENT '上课开始时间', `end_time` datetime NOT NULL COMMENT '上课结束时间', `price` decimal(10,2) NOT NULL COMMENT '订单金额', `status` int(11) NOT NULL DEFAULT '0' COMMENT '订单状态', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_teacher_time` (`teacher_id`,`start_time`,`end_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

order_no用"yyyyMMddHHmmss + 3位随机数"生成，这是最简单不会重复的方式。索引设计上，联合索引（teacher_id, start_time, end_time）能极大加快排课冲突校验的查询速度，这个索引在真实场景中就是量级上的性能差异。

5.2 一对多与多对多关系的处理策略

教师和科目之间是多对多关系，需要一张关联表teacher_subject来维系，字段就三个：id、teacher_id、subject_id。科目表本身在系统里基本就是一个静态字典：数学、英语、物理、化学、语文、生物、历史、地理、政治、钢琴、绘画、编程。毕设阶段直接在SQL初始化脚本里INSERT进去就行，不用专门做科目管理功能。

老师详情表teacher_info和用户表是一对一关系，存放老师专属的信息：教龄、学历、学校/机构、教学风格、每小时价格、可教区域等。为什么不分一张表全塞进user里？因为家长端的用户根本不需要这些属性，分表后逻辑更清晰，而且这也能向老师展示你掌握了垂直分表的设计思路。

6. 核心业务流程与代码实现

6.1 下单流程的完整时序

下单是整个系统里横跨前后端最多的业务，建议先从时序层面理清楚：家长在教师详情页点击"预约试听"→ 选择上课时间和时长 → 后端校验老师是否空闲 → 创建订单（状态为待支付）→ 家长确认支付 → 模拟支付成功回调 → 订单状态变为待上课。

考虑到毕设没办法接真实支付渠道，我用的方案是做一个模拟支付页面，点击"确认支付"后直接跳转一个模拟支付成功的回调接口，接口把订单状态更新为待上课。这个方案虽然是模拟的，但业务闭环是完整的，答辩时说明"实际生产可替换为微信/支付宝官方SDK"就够了。

6.2 接口定义与Android端调用对齐

前后端接口对齐的关键在字段命名。后端返回的JSON字段统一用驼峰命名法，和Java属性保持一致，这样Gson解析时不需要额外写SerializedName注解。日期格式统一为"yyyy-MM-dd HH:mm:ss"，直接作为字符串传输，Android端用SimpleDateFormat解析出Date对象再格式化展示。

我列几个核心接口路径：POST /api/auth/login（登录）、GET /api/teacher/list（教师列表）、GET /api/teacher/detail/{id}（教师详情）、POST /api/order/create（创建订单）、GET /api/order/my（我的订单）、POST /api/review/submit（提交评价）。这些接口路径在设计阶段就要定好，写进接口文档里，前后端各自照着文档开发，能少吵很多架。

6.3 教师端接单与日程管理

老师端的核心场景是接单和排课。在"我的日程"页面，老师可以看到自己所有时间段的排课情况，支持手动添加和删除排课。排课数据存在course_schedule表里，字段包含teacher_id、start_time、end_time、type（1空闲、2已预约、3不可约）。对老师来说，这条时间轴就是他的"可售卖资源"。

比较有意思的是推荐算法在这里的应用：当家长浏览教师列表时，我调了一个"活跃推荐"排序因子，近期有排课活动的老师权重升高。这个功能看着不起眼，但能体现你对业务的理解深度——平台需要鼓励老师保持活跃，而不是注册完就消失。

7. 前端关键页面与交互实现

7.1 教师详情页的信息层级设计

教师详情页直接决定家长会不会下单。我按这样的信息层级排布：最顶部是大图头像和名字，下面一排展示教龄、学历、评分三个标签，再往下是ta的可教科目和价格区间，继续往下是个人介绍和教学风格，最后是评价列表。整个页面用NestedScrollView包裹，评价列表嵌套RecyclerView时要注意设置setNestedScrollingEnabled(false)，否则会出现滑动冲突。

页面底部固定一个"预约试听"按钮，颜色用平台主色，点击后弹BottomSheetDialog选择上课时间。这个按钮要一直悬浮在页面底部，用户浏览完所有信息后最自然的动作就是点击它。

7.2 下拉刷新和加载状态的细节处理

页面加载状态我用三种视图管理：加载中显示居中ProgressBar，加载失败显示带重试按钮的提示视图，加载成功显示内容。用ViewStub按需inflate这三种状态视图，比动态addView效率更高，也避免了视图层级过深的问题。

下拉刷新用SwipeRefreshLayout，在onRefresh回调里重新请求第一页数据，请求完成后调用setRefreshing(false)结束动画。这里有个很多人会忽略的坑：如果刷新请求失败，一定要结束刷新动画，否则用户会看到转圈圈停不下来的诡异状态。正确做法是在finally代码块里调用setRefreshing(false)。

8. 系统优化点与进阶提升方向

8.1 服务端性能优化三板斧

毕设如果能展示出性能优化意识，答辩老师通常会高看一眼。我做了三件事：第一，教师列表接口开启了Spring Cache，缓存key为"teacherList:page:{page}:size:{size}"，缓存过期时间60秒，有效降低数据库压力；第二，热门科目和评价数据用Redis缓存，你就算只写几行RedisTemplate的get/set代码，也足够展示你对缓存技术的理解；第三，SQL层面尽量覆盖索引，避免在查询条件中使用函数导致索引失效。

这里说个实际的缓存一致性经验：我在写评价和更新教师评分的事务里手动删除对应教师的缓存key，这样下次请求时就能拿到最新的评分数据。这种"写操作删缓存"的玩法虽然是Cache Aside Pattern的基础操作，但在毕设里能自己悟出来并写出来，说明你确实理解了缓存的核心逻辑。

8.2 Android端体验优化细节

Android端可以做很多小而美的优化：图片加载用Glide，配置占位图和错误图；列表页的item布局用ConstraintLayout减少布局嵌套层级，提升渲染速度；大列表加setHasFixedSize(true)，告诉RecyclerView尺寸不变，跳过重新测量布局的过程。

另外建议在项目里加一个BaseActivity和BaseFragment，把网络请求的Loading对话框和错误Toast统一封装。这样每个页面的代码会清爽很多，而且这种框架思维是导师喜欢的风格。

8.3 功能扩展的想象空间

做完全部功能后，可以想想还有哪些地方能扩展：增加消息推送功能的话，可以用WebSocket实现站内聊天；增加后台数据分析的话，可以在管理员端加订单统计报表，按天/周/月维度展示GMV增长曲线；增加推荐系统的话，可以基于用户行为记录做"猜你喜欢"的教师推荐。

这些扩展方向在论文的"未来展望"章节里写出来，既能体现你思考的深度，又不会给自己增加实际工作量。我当年就是这么干的，老师看完后特意在答辩时问了一圈扩展方案的技术实现思路。

9. 常见问题与排查技巧实录

9.1 跨域问题与Android请求失败的区分

前后端联调时最容易碰到的就是请求失败。如果你用浏览器调试接口发现一切正常，但Android端请求总是走onFailure，大概率是网络请求被拒绝。排查方法：先在AndroidManifest.xml确认加了INTERNET权限——这个问题出现频率高到令人发指；再看是不是用了http明文请求，Android 9.0之后默认禁止明文流量，需要在manifest里配置usesCleartextTraffic="true"或者在networkSecurityConfig里配置域名白名单。

如果你是后端接口在浏览器里直接访问，出现跨域报错，记得加一个CorsFilter或者用@CrossOrigin注解解决。这在前后端分离项目里是必踩的坑，提前处理能省一晚上时间。

9.2 时间参数时区和格式不一致问题

Java后端默认的日期解析格式是ISO标准的"yyyy-MM-dd'T'HH:mm:ss.SSSZ"，但前端传来的可能是"yyyy-MM-dd HH:mm:ss"，直接用@RequestBody接收会导致解析失败。解决方案是用@JsonFormat注解标注时间字段的格式，同时指定timezone为GMT+8，避免时区偏移导致时间差8小时的问题。

这个坑我第一次做项目时踩过，排查了整整一个晚上，最后发现是Jackson反序列化默认不带解析自定义格式导致的。后来我在所有LocalDateTime字段上都加了@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")，从此再没为时间格式头疼过。

9.3 Android内存泄漏的几个典型场景

Android端的内存泄漏问题，可以从源头避免：Activity里持有静态Context引用、Handler匿名内部类持有Activity引用、网络请求回调在Activity销毁后仍然执行、Bitmap没有及时回收。我的建议是网络请求用ApplicationContext起步，回调回来后判断Activity是否已经isFinishing，是就直接return不再更新UI。

实际项目里我用IntentService处理头像上传的任务，这样Activity销毁了任务也能继续执行，上传完成后再通过EventBus通知刷新。虽然EventBus现在有点被嫌弃，但毕设里用起来非常顺手，而且这套模式在真实项目中也很常见。

10. 部署发布与环境配置经验

10.1 后端打包部署的完整流程

后端部署我用的是阿里云的一台2核4G的轻量应用服务器，操作系统Ubuntu 22.04，安装JDK 17和MySQL 8.0。打包时用mvn clean package -DskipTests生成jar包，通过scp命令传到服务器 /home/app 目录下，用nohup java -jar xxx.jar > app.log 2>&1 & 启动。

生产环境和本地环境用不同的application-xxx.yml配置文件，通过启动参数--spring.profiles.active=prod指定。数据库连接、Redis地址这些敏感配置不要写死在代码里，通过环境变量注入。这样代码仓库里的配置都是脱敏的，安全习惯从毕设就开始养成。

10.2 Android签名打包与真机调试

Android端调试时，强烈建议直接连真机调试，不要用模拟器。模拟器虽然看起来方便，但冷启动慢、GPS模拟麻烦、相机权限需要额外配置，这些限制都会影响家教App这种真实业务App的调试体验。我用的是小米手机开USB调试，Android Studio直接识别设备，一键run到手机上，看到效果的速度比模拟器快三倍。

正式签名打包时，在build.gradle里配置好签名证书，生成release APK放到服务器上提供下载。这里有个加分项：可以做一张二维码，用Android的Scan QR Code功能扫码下载安装包，演示的时候非常炫酷，而且让老师感觉到这个系统真的是可交付的。

11. 项目答辩指南与亮点包装

11.1 演示流程图与核心卖点提炼

答辩演示的时候，按这条主线讲故事：从家长搜索家教开始 → 查看老师详情和评价 → 选择时段预约试听 → 支付创建订单 → 老师端确认接单 → 排课日程更新 → 上课完成后评价 → 评分动态更新到列表页。这条链路一气呵成，能向老师展示整个系统的完整度和业务闭环。

核心卖点提炼三个词：全栈（前端Android+后端Spring Boot+数据库MySQL）、闭环（订单状态从创建到完成全流程管理）、体验（教师筛选、评分算法、排课冲突校验这些功能细节）。这三个词在汇报开场就抛出来，定好基调，后面演示的时候不断呼应。

11.2 常见答辩问题应对策略

老师最爱问的问题基本集中在几个方向：为什么选这个技术栈？订单状态是怎么管理的？并发场景下有没有考虑超卖问题？你作为毕设项目，怎么防止一个老师的同一时间段被多个家长同时预约？

超卖问题这个值得提前做准备。我在下单接口里用数据库层面的条件更新来保证原子性：UPDATE teacher_schedule SET status = 2 WHERE id = #{id} AND status = 1，如果返回影响行数为0，说明已经被抢了，这一点在并发场景下能保证不会出现同一位老师同一时段被两个人约走的情况。把这条SQL的逻辑在答辩时讲出来，老师就能看出来你确实思考过并发问题。

还有老师会问：JWT和传统Session有什么区别？为什么不用OAuth2.0？你的回答思路是：JWT无状态适合移动端和分布式场景，OAuth2.0更适合开放平台给第三方授权登录的场景，我们这个系统自己管理用户体系，JWT方案更简洁高效。

最后再说说做这个项目我个人的心态变化。刚开始写订单模块的时候，我以为最难的是Android界面怎么画得好看，但真正做下来才发现，数据库表怎么设计、接口怎么定义、状态怎么流转才是核心难点。前端界面反而是在后端逻辑理清楚之后水到渠成的事情。所以如果你也在准备做一个类似的系统，我真心建议你先花三天时间把表结构和接口设计文档写透，再动手写代码。你会发现后面的开发速度快到超乎想象，而且这种"先设计再编码"的做事习惯，到实际工作中比掌握某个具体框架值钱得多。