企业官网建设流程全解析

做个人健康管理系统这个选题，其实是被身边一堆朋友的真实需求逼出来的。去年体检季，朋友圈里全是晒体检报告的，很多人拿着报告一堆箭头搞不明白什么意思，转头就忘了。医院离得远，挂号排队成本高，日常的健康数据（体重、血压、步数、睡眠、血糖）全部散落在各个App、手环、纸质报告里，没有一个人把这些数据串起来做过分析。这就是我启动"java基于互联网+的个人健康管理系统设计"的初衷：用Java技术栈做一个能真正把健康数据统一管理、统一分析、给出个性化建议的系统。这个选题放在毕设、放在个人项目积累、甚至放在小成本创业验证场景里都极其合适，本文就把完整的设计思路、技术方案、实现细节、踩坑记录全部摊开讲。

下面这篇文章会比较长，我按照实际开发流程来组织，从整体架构到数据库设计、再到核心模块的代码实现和问题排查，全程用我在这个项目里实际用到的方案来讲，不走弯路也不藏私。

1. 项目整体设计思路与技术选型

1.1 核心需求拆解："互联网+"到底加什么

很多同学看到"互联网+"这个前缀就懵了，不知道它具体的含义是什么。我自己的理解是：它不是简单的"做个网页版系统"，而是要让系统具备"在线化、数据化、智能化"这三个递进层次的能力。落到个人健康管理这个场景里：

• 在线化：用户不需要跑医院、不需要手动翻纸质报告，通过Web端就能完成健康数据的录入、查询、统计；
• 数据化：把体检报告、日常监测数据、运动记录等异构数据统一结构化，形成个人健康时间轴；
• 智能化：在数据基础上做健康风险评估、指标趋势预测、个性化健康建议推送。

这个系统解决的痛点非常集中：碎片化健康数据的统一管理、体检报告指标的可视化解读、异常指标的主动预警。适合的参考人群是Java后端学习者、毕设选题选手、想搭建健康类产品原型的开发者，以及想进入医疗健康信息化赛道的工程师。

1.2 为什么选Java技术栈，而不是Python或Go

技术选型阶段我认真对比过三条路线。这个系统涉及大量业务逻辑、权限管理、数据持久化和报表统计，Java生态在这块积累非常深，尤其是Spring Boot加MyBatisPlus的组合，开发效率高、社区资料多、排查问题方便，后期接定时任务、消息队列、小程序接口都有成熟方案。

Python数据分析确实强，但做Web业务系统要额外处理类型安全、事务管理、权限框架等问题，服务部署也没有Java那一套完善。Go性能好，但面向这种业务场景的开发效率不如Java生态顺手，尤其后台管理系统的CRUD操作、代码生成器、权限框架这些，Java这边有大量半成品可以直接复用。

启动速度方面，Spring Boot 2.x版本也可以，建议直接用Spring Boot 2.7以上的版本，JDK用1.8或者11都行。我实际用的是Spring Boot 2.7.14配JDK 1.8，跑得非常稳，后面接小程序、公众号接口也不需要动架构。

1.3 这套系统的典型业务闭环

整个系统围绕一条核心业务链路展开：用户注册登录 → 建立健康档案 → 录入日常健康数据 → 系统自动分析 → 生成健康评估报告 → 推送个性化建议 → 用户按建议调整生活方式 → 定期复查数据 → 更新健康轨迹。

这一个闭环里包含的角色其实不止普通用户，还有健康管理师或者管理员。所以我设计系统时做了双角色区分：普通用户管理自己的档案和数据，管理员/健康管理师可以查看授权范围内的用户健康数据、维护健康知识库、配置预警规则。这一点在后面的数据库设计中体现得很明显。

2. 系统架构设计与数据库建模

2.1 前后端分离的分层架构

整个系统我采用的是标准的前后端分离架构。后端基于Spring Boot构建RESTful API，前端使用Vue加ElementUI搭建管理界面和用户界面，移动端适配我直接用的H5方案，没有单独做原生App，这样在微信里打开就能用。

后端内部严格分层：

• Controller层：负责接收请求、参数校验、返回统一响应体；
• Service层：承载核心业务逻辑，事务边界在这里划定；
• Mapper层：基于MyBatisPlus操作数据库，避免手写大量重复SQL；
• Utils层：封装JWT工具、脱敏工具、日期计算、健康指标计算等。

为什么要分层？我踩过一个很实际的坑：开发初期为了省事，直接在Controller里写了业务逻辑，结果后面加"健康趋势分析"功能时，发现分析逻辑被复制到了三个接口里，改一个算法就得改三处。后来老老实实重构成Service层统一处理，代码量立刻下来，维护也清爽了。

2.2 数据库表结构设计

数据库我用的MySQL 8.0，字符集统一utf8mb4，引擎InnoDB。核心表一共设计了9张，我挑几张核心的表来讲。

用户表（sys_user）

CREATE TABLE `sys_user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名', `password` VARCHAR(255) NOT NULL COMMENT 'BCrypt加密密码', `real_name` VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', `gender` TINYINT DEFAULT 0 COMMENT '0未知 1男 2女', `birthday` DATE DEFAULT NULL COMMENT '出生日期', `phone` VARCHAR(20) DEFAULT NULL, `role` TINYINT DEFAULT 1 COMMENT '1普通用户 2健康管理师', `status` TINYINT DEFAULT 1 COMMENT '1正常 0禁用', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

用户表设计的关键点是role字段。一开始我设计的是独立角色表加用户角色关联表，后来发现这个场景只有两种角色，搞三张表太重了，直接一个字段解决，查询还快。如果你后续要扩展更多角色（比如医生、营养师），再拆表也来得及，这就是一个"够用就好"的设计原则。

健康档案表（health_profile）

这张表记录用户基础健康档案信息，包括身高、体重、血型、既往病史、过敏史、家族病史等。设计上需要注意：档案表与用户表是1对1关系，但档案表的字段会伴随用户的复查而更新，所以我加了height、weight等指标的实时快照字段，同时保留了record_time字段记录数据采集时间点，方便回溯历史体重变化——这一点是后面做体重趋势图的数据基础。

日常健康数据表（health_record）

CREATE TABLE `health_record` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL COMMENT '用户ID', `record_type` TINYINT NOT NULL COMMENT '1血压 2血糖 3心率 4体重 5睡眠 6运动步数', `record_value` DECIMAL(10,2) NOT NULL COMMENT '数值', `unit` VARCHAR(10) DEFAULT NULL COMMENT '单位', `record_time` DATETIME NOT NULL COMMENT '测量/记录时间', `remark` VARCHAR(255) DEFAULT NULL COMMENT '备注', KEY `idx_user_type_time` (`user_id`, `record_type`, `record_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表是系统数据量增长最快的表，也是查询频率最高的表。设计时特别注意两点：一是联合索引idx_user_type_time必须建，否则用户查询某类指标的历史趋势时全表扫描会非常慢；二是没有设置update_time字段，因为健康数据记录是流水型数据，一旦写入就不允许修改，这是审计需要。

体检报告表（physical_exam）与指标明细表（exam_item）

体检报告和指标明细是1对多关系。头部表存报告头信息（体检机构、体检时间、整体结论），明细表存具体指标项（指标编码、指标名称、结果值、参考区间、单位、是否异常）。为什么不直接在head表里冗余所有指标字段？因为不同体检机构的检查项目不一样，有的人做了血脂全套，有的人没做，如果用固定字段设计，表结构会被无限拉宽，而且后期增加新指标就得改表结构。用明细表设计，指标项的扩展性无限好，只是查询时需要做一次行转列处理，这个后面代码部分会讲。

健康建议表（health_advice）与知识库表（knowledge_base）

健康建议表存储系统给用户生成的个性化建议，包括建议类型、建议内容、关联的指标类型、推送时间、是否已读。知识库存放标准化的健康科普文章和指标解读，供用户浏览，也作为生成建议时的参考数据源。

2.3 关键接口设计规范

接口设计我遵循RESTful风格，统一返回结构。

所有接口返回的标准格式是：

{ "code": 200, "message": "操作成功", "data": {} }

核心接口清单如下：

• POST /api/auth/register用户注册
• POST /api/auth/login登录并返回JWT令牌
• GET /api/profile获取健康档案
• POST /api/health/record新增健康数据
• GET /api/health/record/list?type=1&startDate=&endDate=查询某类健康数据
• GET /api/health/trend?type=4&days=30获取某指标30天趋势数据
• POST /api/exam/upload上传体检报告
• GET /api/report/analysis生成综合健康评估报告
• GET /api/advice/list获取健康建议列表

接口设计的核心原则是参数最小化、语义清晰化。比如查询趋势数据只需要type和days两个参数，服务端根据days计算起始日期，不需要让前端传一堆日期条件。

3. 核心功能模块实现详解

3.1 登录鉴权模块：JWT的完整落地

这个模块看似基础，但我发现很多人做得要么太简单（没有token过期机制）、要么太重（引用了Spring Security全家桶配置半天）。

我采用的是JWT加拦截器方案，没有引入Spring Security。理由很简单：系统只有两种角色，权限复杂度不高，Spring Security配置起来费劲且容易出问题，JWT拦截器30行代码就能搞定。

JWT工具类的核心代码：

public class JwtUtil { private static final String SECRET = "your-256-bit-secret-key"; private static final long EXPIRE = 1000 * 60 * 60 * 24 * 7; // 7天过期 public static String createToken(Long userId, String username, Integer role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

这里有一个非常关键的安全细节：SECRET绝对不能硬编码在代码里，也不应该提交到Git仓库。正确做法是放在application.yml里配合环境变量使用，或者用配置中心管理。我见过有人把密钥提交到代码仓库然后被扫描工具的案例，这种低级错误一定要避免。

拦截器实现时需要注意一个细节：OPTIONS请求要直接放行，否则前端跨域预检请求会被401挡住。

3.2 健康数据录入模块：表单校验与批量处理

健康数据录入是整个系统使用频率最高的功能。用户可能每天记录体重、血压、步数，如果每条记录都要手动填表，体验会很差。所以我在设计时做了两个入口：单条录入和批量导入。

单条录入接口的Controller代码：

@PostMapping("/health/record") public Result addHealthRecord(@RequestBody @Valid HealthRecordDTO dto, @RequestAttribute Long userId) { // userId从JWT拦截器中解析后放入请求属性 healthRecordService.addRecord(userId, dto); return Result.success(); }

DTO层面的参数校验用了@Valid注解，我定义了几个自定义校验规则：比如record_value必须大于0，record_time不能晚于当前时间，血压高压范围必须小于低压范围这种逻辑校验。参数校验不能只在后端做、完全依赖前端，因为有用户可能绕过前端直接调接口。

批量导入功能我支持的是两个格式：JSON数组和CSV文件。CSV解析我用的Apache Commons CSV，处理时有一个容易忽略的坑：CSV文件里的日期格式可能不统一，有人写2025-01-15、有人写2025/1/15，所以解析时必须做多格式兼容，我写了一个DateParseUtils统一处理。

3.3 体检报告解析与指标存储

体检报告上传的方式我设计的比较轻量：用户在前端上传PDF或图片，后端调用OCR识别（这部分接的是第三方API），识别出结构化文本后再由后端提取关键指标，存入体检报告表和明细表。

这里重点讲一下指标明细表存储与查询的设计。用户查看某次体检的完整报告时，前端需要的是一个指标列表，每行包含指标名、结果值、单位、参考区间、异常标记。存储时是明细行，查询后需要做行转列处理吗？其实不需要。我用VO对象直接映射：

public class ExamItemVO { private String itemName; private String itemCode; private BigDecimal resultValue; private String unit; private String referenceRange; private Boolean isAbnormal; }

MyBatisPlus的查询直接返回List<ExamItemVO>，用@Select注解手写一个多表关联查询就可以实现。不需要在数据库层面做行转列，Java层转换更灵活。这个设计决策我卡了很久，后来想通了：既然前端要的数据本质是列表，列表查询直接返回List<ExamItemVO>就是最直接的方案，那些复杂的行转列场景只有在做统计分析报表时才需要，到时候再用数据库函数处理。

异常指标判定逻辑也是系统的一个亮点。参考区间存在exam_item表的reference_range字段里，格式是"3.5-5.9"这样的字符串。判定时解析上下界，比较结果值，超出就标记为异常。这个逻辑抽了一个独立的工具类IndicatorEvaluator，方便复用和单元测试。

3.4 健康评估报告生成：规则引擎的轻量实现

健康评估是本系统智能化程度最高的模块。我的实现方案没有引入专业的规则引擎（比如Drools），因为系统健康指标规则还不到那么复杂的程度，我用的是规则模板加策略模式。

以血压评估为例：

public class BloodPressureEvaluator implements IndicatorEvaluator { @Override public EvaluationResult evaluate(BigDecimal systolic, BigDecimal diastolic) { if (systolic < 90 || diastolic < 60) { return new EvaluationResult("血压偏低", 2); } if (systolic >= 140 || diastolic >= 90) { return new EvaluationResult("血压偏高，建议复查", 7); } if (systolic >= 120 || diastolic >= 80) { return new EvaluationResult("血压偏高倾向，注意饮食", 5); } return new EvaluationResult("血压正常，继续保持", 9); } }

评估结果包含等级分数（1-10分），系统汇总所有指标的分数后，生成综合健康评分。评分生成逻辑要结合用户的年龄、性别做加权处理，这里我用了一个ScoreWeightConfig配置类，集中管理各年龄段的不同权重系数，后续调整评分策略时只需要改配置，不需要动业务代码。

健康建议的生成也走规则模板路线。比如当血糖值连续三次超过参考范围，系统生成一条建议："您的血糖近三次监测持续偏高，建议控制主食摄入量，增加膳食纤维摄入，并在一周后复查空腹血糖。"这类建议文本用模板加占位符拼接，存放在health_advice表里，按用户维度隔离。

3.5 数据可视化模块：趋势图与健康画像

可视化我用的ECharts，前端通过接口拿到趋势数据后构建图表。核心接口是趋势查询：

@GetMapping("/health/trend") public Result getTrend(@RequestParam Integer type, @RequestParam(defaultValue = "30") Integer days, @RequestAttribute Long userId) { LocalDate startDate = LocalDate.now().minusDays(days); List<HealthRecord> records = healthRecordService.queryTrend(userId, type, startDate); return Result.success(buildTrendData(records)); }

buildTrendData方法返回的数据结构里包含时间序列和数值序列两个数组，前端直接塞给ECharts就能画折线图或者柱状图。

健康画像模块则把用户的年龄、性别、BMI、血压、血糖、运动情况汇总成一个雷达图。雷达图的评分数据来自健康评估模块，前端接收后渲染成五维或六维雷达图，用户一眼就能看出自己的薄弱环节在哪。

4. 数据库优化与性能调优实战

4.1 时间范围查询的索引优化

健康数据表的record_time是查询的黄金字段。不建索引时，一个有一年数据的用户查询全年血压时，MySQL走全表扫描，耗时可能到秒级。建了(user_id, record_type, record_time)联合索引后，查询直接走索引，耗时降到几十毫秒。

注意联合索引的列顺序：user_id放在最前面是因为查询条件总是带上用户ID，这个字段的区分度最高；record_type次之，因为同一个用户会记录多种指标；record_time最后，作为范围条件放在最右侧不会破坏索引结构。如果你把record_time放在第二列，那record_type的过滤条件就无法走索引了，这是新手最常犯的错误之一。

4.2 分页查询性能优化

管理后台查询用户列表、健康管理师查询授权用户数据时，用了MyBatisPlus的分页插件。千万注意：分页查询必须新建Page对象，不能直接复用前端传来的Page对象，因为Page内部有线程不安全的分页状态。

另外一个性能优化点是列表页的COUNT查询非常耗时，特别是带多条件过滤时。我的处理是把常用的查询条件（用户名、状态、注册时间范围）作为独立索引，同时在SQL层面用EXPLAIN分析执行计划，强制命中最优索引。

4.3 大字段与频繁更新的取舍

体检报告原始文件（PDF或图片）我选择存在OSS对象存储中，数据库只存文件URL。如果存base64到MySQL，单行数据会达到几MB，严重影响查询性能，还会拖慢数据库备份和恢复。这就是典型的"数据库只存元数据，文件放存储服务"架构思想。

另外，健康档案表的height、weight字段属于"读多写少"的数据，但每次用户更新体重时我并没有立刻更新档案表。我的设计是每日凌晨通过定时任务回刷，从health_record表中取当天的体重记录更新到档案表。这样做的原因是：用户在一天内可能多次记录体重（早晨一次、睡前一次），直接更新档案表会产生大量行锁竞争，而定时批量汇总的性能好得多，业务上也不影响使用。

4.4 数据隔离与权限控制

系统有普通用户和健康管理师两种角色，数据隔离策略必须严谨。普通用户只能操作自己的数据，健康管理师只能查看已授权的用户数据。

我在所有Mapper查询中都强制带了user_id条件，这一点不只是靠代码习惯保证，更在数据库层面通过查询拦截器做了一层兜底。MyBatisPlus的自定义拦截器可以自动在查询SQL末尾追加AND user_id = ?，配合上下文中的当前用户ID。这种"双保险"设计在安全敏感的健康数据场景里非常重要。

5. 开发过程中的常见问题与排查实战

5.1 MySQL中文乱码与时区问题

项目启动后第一件事就是检查连接串。我踩过时区问题：serverTimezone=Asia/Shanghai不配置的话，凌晨和中午的时间字段会差8小时，导出报表时用户会发现"为什么记录时间是错的"。中文乱码则要确保三处一致：数据库字符集、连接串的characterEncoding=utf8、表字段的字符集。这三处只要一处不一致，就会出现乱码。

5.2 JWT过期与前端401处理

JWT的7天过期策略在真实使用中产生了"用户登录状态突然失效"的问题。排查后是前端没有处理token续期逻辑。前端的统一响应拦截器里增加了401处理：弹出提示"登录已过期，请重新登录"，然后跳转登录页。更顺滑的方案是加refresh_token机制，但考虑到这个系统的使用频率，7天过期后重新登录完全可接受，就没把机制搞复杂。

5.3 定时任务重复执行问题

健康档案回刷的定时任务用Spring的@Scheduled注解实现，单机部署时没有问题。但如果部署在多实例环境下，每个实例都会执行一次定时任务，就会产生重复更新。我的解决方案有以下三种思路：最简单的是引入@Scheduled加分布式锁，用Redis的SETNX命令实现锁机制；如果不想引入Redis，可以约定一台固定实例作为定时任务调度器，通过环境变量控制；更成熟的是引入XXL-JOB这类分布式调度框架。我这次用Redis加锁方案，代码不超过15行就能搞定。

5.4 MyBatisPlus字段自动填充失效

代码里用了@TableField(fill = FieldFill.INSERT)注解希望自动填充create_time，但运行时发现没有生效。原因是我没有配置MetaObjectHandler这个内部组件，后来补上了一个自动填充处理器类，实现insertFill和updateFill方法，问题才彻底解决。这是MyBatisPlus开发中非常常见的坑，遇到"自动填充不生效"问题，优先检查这个配置。

5.5 接口响应慢的排查方法论

用户反馈某个页面打开时要等很久，排查时我按照一套固定流程走：

1. 打开浏览器开发者工具的Network面板，确认具体是哪个接口耗时高；
2. 看该接口对应的SQL，使用EXPLAIN分析执行计划；
3. 检查是否走了索引、扫描行数是否过大；
4. 检查前端是否短时间内重复调用了同一个接口；
5. 检查后端是否存在N+1查询问题（关联表多次单条查询）。

这套方法论帮我解决了好几个性能瓶颈，尤其是N+1问题，用MyBatisPlus的selectBatchIds批量查询替代循环单查，性能提升非常明显。

6. 测试与部署落地经验

6.1 单元测试与接口测试

健康指标评估这类核心逻辑，我写了完整的单元测试。测试用例覆盖正常值、边界值、异常值三种场景，用JUnit5的参数化测试，一个测试方法就能跑几十个数据样本。比如血压评估器，我测试了临界值120/80、140/90、90/60等边界情况，确保判定逻辑没有边界bug。

接口测试用Postman的Collection Runner做回归，把核心接口的请求和断言保存下来，每次改代码后跑一遍。这个习惯帮我避免了好几次"改了A功能结果把B功能搞坏了"的回归事故。

6.2 打包部署与持续集成

后端打包用的Maven，mvn clean package -DskipTests打成jar包。部署到CentOS服务器后，用systemd管理进程，配置了开机自启和服务异常自动重启。环境变量里配置数据库密码和JWT密钥，application.yml使用${DB_PASSWORD}占位符引用。

前端用Node.js的Vue CLI构建后，把dist目录里的静态文件放到Nginx的目录下，Nginx配置反向代理/api路径到后端服务的端口。前后端分离部署的优点在这里体现得很充分——静态资源用Nginx处理爆发力强，后端只管业务逻辑，互不干扰。

6.3 监控与日志

虽然这个系统不算大项目，但我还是接入了简单的监控：使用Spring Boot Actuator暴露健康检查接口，配合一个Shell脚本定时检测进程状态，异常时自动重启。日志方面，用logback按天滚动，保留最近30天的日志。排查线上问题经验中，ERROR级别的日志一定要包含用户ID、请求参数、堆栈信息三个要素，不然事后排查时你会发现连"是谁触发的错误"都查不到。

7. 实际运行效果与用户体验

7.1 核心性能指标

在本地开发环境（8核16G配置、单机MySQL），百级用户量下核心接口的响应表现相当稳定：

• 健康数据单条录入：平均30ms
• 30天血压趋势查询：平均80ms
• 综合健康评估报告生成：平均300ms
• 登录鉴权：平均15ms

7.2 实际用户反馈

我让身边十几个朋友真实验用了这套系统，整理出的反馈主要集中在几个方面：录入体验还算顺手，让填的东西不多；血压趋势图和BMI走势图一眼能看懂；体检报告上传后不用自己数箭头了，异常指标直接标红；最后系统的健康建议大多是普适性内容，虽然合规合理但个性化程度还可以加强，这是我下一版要优化的重点。

这些反馈让我意识到，"互联网+健康管理"不是做一个把所有指标堆上去的冷冰冰系统，而是要让用户真正读得懂、用得上、愿意持续使用——这个认知直接影响了我后续的功能迭代计划。

8. 系统扩展方向与二次开发建议

8.1 移动端与小程序端

当前系统是Web端H5方案，下一步最优先的扩展方向是微信小程序。小程序端的优势是获取用户运动步数、睡眠数据可以走微信原生能力，用户在微信里打开就用，不需要额外安装App。后端接口已经按RESTful标准设计，小程序端只需要做一层适配调用即可复用现有全部接口。

8.2 接入智能硬件设备

市面上手环、血压计、体脂秤基本都开放了数据接口。可以在服务端新增一个设备绑定功能，通过定时任务每5分钟拉取一次数据，自动写入health_record表。这个扩展对现有架构的改动很小，因为核心设计就是"数据源是开放的、存储是统一的"，设备只是另一个数据来源而已。

8.3 从"个人管理"到"家庭共享管理"

当前系统的健康数据是按用户完全隔离的，但从实际场景看，子女给父母管理健康数据的需求非常强烈。可以做一个"家庭成员绑定"功能，用户获得授权后可以查看父母授权给自己的健康数据。数据库层面只需要增加一张family_bind表，业务层增加一个"被授权人"的数据可见范围判断。

做这个项目最大的感触是，个人健康管理系统虽然看起来是典型的CRUD系统，但真正做深了会发现，数据建模的合理性、指标计算的准确性、权限控制的严谨性、性能优化的精细度，每一个点拿出来都能写一篇很长的经验总结。系统里最有价值的部分不在于界面有多炫酷，而在于背后的数据能不能真正帮助用户看清自己的健康趋势、发现潜在风险并做出改变。如果你也正在做类似的系统，建议先花足够时间在需求梳理和数据建模上——这块地基打牢了，后面写代码会快很多。