Spring Boot + 小程序开发高校校友会系统：毕设选题到答辩全流程实战

每年到了毕业设计的季节，总有同学来问我：题目怎么选？这个题到底要不要接？系统做到什么程度才算"够用"？我接触过一个非常典型的选题——基于Spring Boot + 小程序的高校校友会系统。这套东西从立项到答辩，源码、文档、调试一整套走下来，很多同学靠它顺利收尾，也有同学半路卡在登录态、文件上传这种细节上浪费了好几天。这篇文章我就把整个项目从头到尾拆开讲一遍：需求怎么梳理、技术栈怎么定、数据库怎么建模、核心功能怎么实现、部署演示怎么做、论文答辩怎么准备，全部按真实实操的经验来说，适合准备做Java方向毕设的同学，也适合想快速了解一个完整业务系统怎么落地的读者。

1. 毕业设计选题：为什么校友会系统是"性价比之王"

先说选题这件事。很多同学第一步就卡住了，要么选了个完全没人做的冷门题目，答辩时评委一脸茫然；要么选了个门户网站级别的"在线商城"之类，功能堆到天花板，最后连自己都讲不清楚。校友会系统恰好踩在一个非常舒服的位置上——它是典型的管理信息系统，业务场景清楚，用户角色明确，数据关系不复杂但足够展示设计能力，同时它有真实的社交属性，做出来的东西给谁看都"有画面感"。某高校一位做毕设的A同学当初选这个题时，导师给的评价是："需求清晰，发挥空间大，既能考基础也能考设计。"事实证明这个判断是对的。

1.1 这类题目的真实定位

校友会系统的本质，是一个面向校友、学院工作人员、系统管理员三个角色的信息管理平台。它既有传统的增删改查，又涉及微信生态的登录认证、消息触达、活动报名这类偏业务的交互逻辑，天然适合用Spring Boot做后端、用小程序做C端入口这种主流组合来落地。相比纯粹的"图书管理系统"或"学生选课系统"，它的差异点在于：有一个实名认证闭环（校友身份需要审核）、有外部平台对接（微信登录），这两点恰好是毕设答辩时最容易被追问、也最能展现项目深度的地方。

从交付角度看，这类题目也有天然优势：源码结构清晰，文档有固定模板可循，远程调试的场景明确（小程序端需要访问后端接口，必然涉及内网穿透或服务器部署）。很多同学最后顺利通过，不是因为他们写了多惊艳的代码，而是把一条完整链路——注册、认证、浏览活动、报名、管理员审核、数据统计——做得闭环了。

1.2 什么人适合做这个题

如果你满足以下任一条件，这个题都比较合适：

• Java基础过关，能写简单的CRUD，但对"一个完整系统"还没有整体概念；
• 学过一点前端，但没精力开发完整的Web管理后台；
• 想避开高并发、算法类这种"眼高手低"的选题，求一个稳妥落地；
• 需要在较短时间（两到三个月）内从需求到论文完整交付。

反过来，如果你已经完全掌握微服务、容器化那一套，这题对你来说上限确实不高。但话说回来，毕业设计的核心目标不是炫技，而是在有限时间内证明你具备"独立完成一个可用系统"的工程能力。这一点在后面的章节里我会反复提到。

2. 需求拆解：校友会系统到底要管哪些事

拿到题目先别急着写代码。我见过太多同学上来就建工程，结果做到一半发现"这个功能要改表结构""那个角色漏了权限"，返工成本非常高。正确的姿势是先花三五天把需求文档和人（或者自己）对齐。校友会系统的需求可以拆成三层来看：用户能干什么、管理员要管什么、系统本身要支撑什么。

2.1 三个角色的权限边界

• 校友（小程序端用户）：注册/登录、提交校友认证资料、查看资讯与活动、报名活动、发起或参与捐赠、查询校友通讯录（受权限控制）、在社区或留言区互动、维护个人资料。
• 学院管理员（后台管理端用户）：审核校友认证、发布资讯与活动、管理活动报名名单、维护校友信息、查看捐赠统计、处理留言反馈。
• 超级管理员（系统维护者）：管理员账号管理、角色权限配置、系统参数设置（比如是否需要审核后才能发布活动这类开关）。

这三个角色的权限用一张表就能说清楚：菜单权限、按钮权限、数据权限。毕设级别做到菜单和按钮层面就足够了，不用硬上RBAC的复杂模型，但权限拦截的代码必须清晰可讲，这是答辩时的高频问题。

2.2 核心功能模块清单

功能模块拆成七个就够：

1. 校友注册认证（小程序端）：微信授权登录、填写学籍信息、上传证明材料、等待审核；
2. 校友资讯（小程序端）：学院新闻、校友动态、通知公告的浏览与详情；
3. 活动管理（双端）：后台发布活动（时间、地点、人数限制、报名截止）、小程序端活动列表与报名、后台报名审核/导出；
4. 校友通讯录（小程序端）：按入学年份、专业、地区筛选查找校友，查看联系方式前需要先通过认证；
5. 捐赠记录（双端）：小程序端展示捐赠项目并"模拟捐赠"（毕设通常不接真实支付），后台端记录、统计；
6. 留言互动（双端）：校友留言、管理员回复，类似简单的留言板；
7. 系统管理（后台）：管理员账号、角色、日志。

这七个模块覆盖了一个信息管理系统最常见的业务特征，而且每个模块都能单独拎出来当论文的一个章节来写。

2.3 什么是"必须有"，什么是"锦上添花"

我给A同学的建议是：必须有的是注册认证、活动管理、资讯发布、通讯录查询，这四个构成了系统的业务主线；加分项是数据统计（比如历年校友分布柱状图）、导出Excel、消息通知（审核通过后在小程序里收到一条"服务通知"或站内消息）。做得好的加分项在答辩时很能撑场面，但没有也不影响整体评价。

这里有一个特别容易被忽略的需求：隐私保护。校友通讯录里的手机号、邮箱属于敏感信息，不能所有登录用户一进去就能全部看到。所以设计里一定要有"认证可见"的规则——验证过的校友才能查看联系方式，未认证用户只能看到姓名和所属届别。这个细节在需求分析阶段写清楚，后面数据库和接口设计都会顺理成章。

3. 技术选型的取舍逻辑：Spring Boot + 小程序是怎么被锁定的

很多同学在选型阶段容易陷入选择困难：要不要用Spring Cloud？要不要配个Vue后台？要不要上Docker？我的建议很直接：毕业设计不是企业级项目，技术栈越主流、越容易讲清楚越好。 这套系统的最终选型是 Spring Boot 2.7 + MyBatis Plus + MySQL 8 + Redis + 微信小程序原生 + 后台管理端（可选用开源脚手架改造或用Vue Element Admin），下面逐个说理由。

3.1 为什么是Spring Boot而不是SSH或者Spring Cloud

Spring Boot在Java毕设里几乎是默认答案。它的自动配置让开发效率大幅提升，内嵌Tomcat让部署只用一条命令 java -jar 就能完成，这一点对后面"远程调试"和"现场演示"至关重要。SSH那套已经是上一个时代的东西，Spring Cloud对单机部署的毕设来说完全是大炮打蚊子——服务拆分、注册中心这些概念你很难在论文里自圆其说，除非你做得足够深，否则"为什么需要服务注册中心"这个问题就能难倒一片人。

3.2 为什么C端选微信小程序而不是H5或App

这里有一个很现实的原因：评审老师手机上能直接打开微信扫一扫。相比让人下载一个App，或者打开一个要输入网址的H5页面，小程序的演示门槛是最低的。从平台角度，小程序有官方提供的登录能力（wx.login），用户身份获取链路成熟稳定；从开发角度，小程序前端只需要用WXML/WXSS/JavaScript就能完成，不需要额外搭一套App开发环境，对后端方向的同学学习成本更低。

另外，微信生态对"校友"这个场景天然契合——大家都在微信里，转发活动、分享资讯都方便。这也是在需求论证阶段可以说给导师听的"业务合理性"。

3.3 MySQL + MyBatis Plus + Redis 的配合逻辑

• MySQL：存储结构化业务数据，校友、活动、报名、捐赠，表关系清晰，事务支持可靠；
• MyBatis Plus：相比纯MyBatis，它内置了单表CRUD和分页插件，至少能让你的代码量减少三分之一；同时你又可以自定义SQL来写多表关联查询，保留了"手写SQL能力"的展示空间；
• Redis：主要用来存token（登录态）和缓存热点数据（比如资讯列表、活动列表）。这样选不是因为"用了缓存显得高级"，而是有实际业务场景：小程序每次冷启动都要拉首页资讯，用Redis缓存后接口响应能快一个数量级，演示时滑动的流畅度肉眼可见地提升。

注意：毕设的Redis不用搞集群或者哨兵，一台单实例足够了。论文里写清楚"使用Redis缓存解决热点数据访问压力"即可，不要给自己挖坑去解释高可用架构。

3.4 后台管理端选型的现实考量

后台管理是很多同学纠结的地方。两条路：一是用开源脚手架改（很多同学用这类方式快速搭出用户管理和菜单权限），二是用Vue + Element UI自己写。我的建议：如果你前端基础一般，用开源脚手架是合理的选择——把精力留给后端业务和论文；但如果你有一定前端能力，自己写一个简洁的后台能避免"代码雷同率"检查时的不必要的麻烦。无论哪条路，后台的页面数量控制在10个以内就够了，重点是功能闭环，不是页面华丽。

4. 数据库设计：把"校友关系"落成表结构

数据库设计是整套系统的地基。A同学一开始设计的表有28张，我帮他砍到15张左右——很多"表"其实是字段，放在一张表里反而更好管理。下面把核心表结构和设计思路讲透，你可以直接作为自己建表的参考。

4.1 核心表清单

4.2 三个容易被忽略的设计细节

第一个：登录账户（t_user）和校友档案（t_alumni）为什么要分表。用户注册后还不一定是"校友"——他只是一个账号，只有提交认证资料且审核通过后才成为校友，档案才完整。这个分离不仅是数据上的解耦，更是业务规则的体现。如果一开始就把openid、手机号、学历信息全塞到一张表里，认证状态一变就要整行更新，逻辑会混乱得多。

第二个：校友认证需要单独一张记录表（t_auth_record）。原因来自真实业务：校友可能第一次提交材料不完整被驳回，完善后再次提交。如果用一张alumni表的auth_status字段去记录，你只能知道"当前状态是否通过"，看不到历史提交了哪些材料、为什么被驳回。单独一张认证记录表，每一次提交都留痕，后台管理员审核时也能看到完整的申请轨迹。这个设计在论文里专门写一节，答辩时是加分项。

第三个：活动表里的current_count字段。很多人会问：报名人数直接 count(*) 查报名表不就得了，为什么要冗余一个字段？原因是：活动列表页需要展示"已报名/总名额"这样的进度条，如果每个活动都去实时统计报名人数，列表接口的查询压力会成倍增加。用冗余字段维护一个计数器，在报名成功事务里 +1、取消报名 -1，同时配合活动校验（当前人数小于最大人数才允许报名），既高效又简单可靠。这就是典型的"用空间换时间"设计思路。

4.3 统一约定：所有表的公共字段

我给这套系统定了一组公共约定，建表时统一加上，后面写代码省心得多：

• create_time、update_time：使用 DATETIME 类型，后端用MyBatis Plus的自动填充；
• deleted：逻辑删除标记，统一用 0/1 表示，除非真的有需要物理删除的场景；
• status：状态字段统一规范为 0-禁用/待处理、1-正常/通过、2-驳回/关闭 这样的语义，不要一张表一个含义；
• 所有ID统一使用 BIGINT 自增主键，不要搞雪花ID——单机部署下雪花算法没有优势，反而让新人看着懵。

5. 核心功能实现：从登录鉴权到活动报名的完整链路

这章是整套系统里技术含量最高的部分。我会按"登录→认证→活动→通讯录→捐赠→后台"的顺序把实现思路和踩坑点讲清楚，每个模块都会提到值得注意的细节。

5.1 微信小程序登录与Token鉴权

小程序的登录流程是：前端调用 wx.login() 拿到临时code，把code传给后端，后端调用微信接口换取 openid（还有session_key），然后用openid查t_user表。如果是新用户，自动创建一条状态为"未完善资料"的账号；如果已存在，直接签发token。token这里选JWT，生成后返回给小程序端，前端存在 wx.setStorageSync('token', ...) 里，后续每个请求在请求头里带上 Authorization: Bearer <token>。

这里有几个坑要提前告诉你：

• code2Session接口必须在后端调用，不能在小程序前端直接调，否则会暴露appSecret，这是微信官方明确禁止的。
• 后端处理完登录后，不要把openid直接返给前端。openid相当于用户在微信生态里的身份证号，前端只需要拿到你自己的token。
• JWT密钥不要写死在代码里，放到 application.yml 里，答辩时长官一问就能答上来"配置化了"。

拦截器上，我建议用Spring MVC的 HandlerInterceptor 配合一个注解（比如 @RequireLogin），把所有需要登录的接口统一拦截。后台管理端的接口额外走一层管理员权限校验。把权限判断集中到拦截器里，而不是散落在每个Controller中，这是代码规范性的体现。

5.2 校友实名认证的业务闭环

这个模块是整套系统区分度最高的地方，建议重点写。流程是：校友在小程序端提交认证资料（姓名、入学年份、专业、学历信息、证明材料图片），后端生成一条t_auth_record记录，同时把t_alumni表的auth_status置为"待审核"；管理员在后台看到待审核列表，点开详情查看材料，审核通过或驳回并填写理由；审核结果通过小程序端"我的消息"反馈给用户。

实现要点：

• 图片上传：小程序端用 wx.uploadFile 上传到后端，后端存到本地磁盘或云存储。毕设级别建议存服务器本地（如 D:/upload/ 或Linux上的 /opt/upload/），数据库里存相对路径（/upload/xxx.jpg），访问时通过一个映射路径提供访问。这样最省事，也方便后续打包演示。
• 认证状态变化的通知：审核通过后，在小程序端的消息列表里生成一条站内消息。不要一上来就做微信"服务通知"，那需要小程序模板消息的权限申请，毕设时间线上容易变成无底洞。站内消息足够演示闭环。
• 重复提交：如果用户已经有一条"待审核"记录，前端要控制按钮为不可点击，后端也要做同屋檐拦截（同一个用户不能同时存在两条待审核记录），这个后端校验特别容易漏。

5.3 活动发布、报名与人数控制

后台发布活动时，前端表单提交title、content、startTime、endTime、location、maxParticipants、registerDeadline，后端插入t_activity表，status为"报名中"。小程序端活动列表只查 status = 报名中 且 end_time > now() 的活动，排序按开始时间近者优先。

报名接口是并发敏感场景，虽然毕设不会真有高并发，但代码必须考虑防止"超卖"。标准写法是：先查活动状态和当前人数，校验通过后在同一个事务里更新 current_count = current_count + 1 并插入报名记录。要解释清楚"为什么不先插入报名记录再更新人数"——那会把事务边界搞乱，数据容易不一致。这里用MySQL的行锁就足够了，不需要分布式锁。

还有一个很日常但很实际的功能：报名名单导出Excel。后台点击"导出"就把报名记录生成一个.xlsx文件下载。这个功能在答辩演示时非常给力，评委能看到"管理系统"不只是查列表。

5.4 校友通讯录与捐赠：两个易踩坑的功能

通讯录是隐私最重的模块。查询逻辑是：只有 auth_status = 已认证 的用户才能看到联系电话、邮箱；未认证用户只能看到姓名和届别。实现上，Controller里先从token解析出当前用户，查他的认证状态，再决定返回哪些字段。这里建议不用 @JsonIgnore 这种静态注解来控制——那个太僵硬，我一般在Service层组装VO，不同状态返回不同DTO，逻辑清晰且可测试。

捐赠功能在毕设里通常是"模拟支付"。A同学当初的做法是：小程序端选择捐赠项目、填写金额，点击"捐赠"后走一个模拟支付页面（按钮写着"模拟支付"），后端生成一条 t_donation 记录，状态为"已完成"。有同学纠结要不要接真实支付——千万别接，个人开发者没有微信支付商户号根本没法对接，而且涉及资质问题。论文里说明"鉴于演示环境限制，采用模拟支付流程验证业务闭环"就可以了，这个表述既诚实又合理。

5.5 后台管理端的落地

后台管理端最少需要6个页面：登录页、控制台（统计卡片+趋势图）、校友管理（列表+审核）、资讯管理、活动管理、捐赠/留言管理。统计功能建议用ECharts画两个图：一个是"校友届别分布柱状图"，一个是"每月活动数折线图"——数据从后端统计接口返回，SQL里用 GROUP BY 就能搞定。这两个图放在仪表盘首页，演示时一打开后台就有"管理系统"的视觉冲击力。

经验提示：后台管理端的会话管理可以复用JWT机制，也可以简单用Session。但前后端如果分开部署（比如前端Vue打包后由Nginx托管，后端Spring Boot独立端口），用JWT统一会简单很多，避免跨域Session的问题。

6. 部署与远程调试：把系统从本机搬到能演示的状态

毕设做得再好，演示时打不开就是零分。这一章讲的是从开发到可演示的完整链路，每一步都是我实际带人操作过的，细节直接照着做就行。

6.1 本地开发环境的完整清单

你的电脑上需要装齐这些，版本不对很容易踩坑：

A同学踩过的一个大坑是：MySQL 8的默认认证插件是 caching_sha2_password，而某些JDBC驱动老版本不兼容，连接报 Public Key Retrieval is not allowed。解决方法是JDBC连接串加上 allowPublicKeyRetrieval=true&useSSL=false，或者把驱动版本升到8.x。这种问题看起来小，但能卡住一整天，提前写在文档里能救不少人。

6.2 小程序端联调最容易翻车的地方

在微信开发者工具里跑小程序，第一步是改 project.config.json 里的appid——如果你用的是测试号，很多东西（比如手机号快捷验证）用不了，但 wx.login 可以正常用。后端接口地址要从小程序的request的baseURL统一管理，本地联调时填 http://localhost:8080，注意开发者工具里要勾选"不校验合法域名"才能在本地访问非HTTPS接口。

真机预览是另一个分水岭：手机上的小程序不能访问你电脑的 localhost，必须把后端接口映射到公网或局域网。最常用的方案是内网穿透工具，把本机的8080端口映射成一个公网域名，手机访问这个域名就能打通请求链路。如果你用的是云服务器，也可以直接把后端部署到服务器公网IP，小程序请求地址填 http://服务器IP:8080。但这里有个限制：微信小程序在正式发布时要求接口必须是HTTPS的备案域名，不过毕设演示阶段，在开发者工具里勾选"不校验合法域名"就能绕过，所以现场演示时一定要用开发者工具的"预览"模式，而不是发布体验版。

6.3 生产环境部署的完整步骤

如果评审要求用手机直接访问，或者你想更稳妥一点，建议直接部署到云服务器。步骤是：

1. 给云服务器装好JDK、MySQL、Redis，用 mvn package 把Spring Boot项目打成jar包；
2. MySQL导入初始化SQL脚本，改好配置文件里的数据库账号密码；
3. nohup java -jar alumni-system.jar > output.log 2>&1 & 启动后端；
4. 用服务器管理面板（或用Nginx）托管后台管理端打包后的dist静态文件，需要配置反向代理把 /api 请求转发到后端端口；
5. 在安全组里放行8080端口（或你自定义的端口）、3306一般不对公网开放，只允许本机访问；
6. 小程序request的baseURL改成 http://服务器公网IP:8080，开发者工具中预览测试。

这一步里面最容易出的问题是端口没放行、MySQL配置了skip-networking（默认只本地连接）导致后端连不上，以及jar包启动后端口被占用。每一样我都见过现场翻车，提前写进部署文档能让你答辩时从容很多。

6.4 远程调试的实战姿势

毕设的远程调试分两种场景：一种是帮别人跑代码（很多同学买的源码要换环境跑起来），一种是自己在不同设备上继续开发调试。核心思路是一样的：先把环境变量和依赖全部标准化，MySQL和Redis的账号密码写在配置文件中而不是代码里，用Git管理代码版本，用一份 README.md 记录从拉取代码到启动成功的每一步。A同学踩过一个很蠢的坑：数据库用户名密码写在代码里，换一台电脑跑时改了三处才想起来还有一处没改。把所有环境相关配置收敛到 application.yml 的一个配置块里，这个习惯能让你和你的队友都省心。

7. 论文写作与答辩：文档和问答怎么准备

很多同学系统做完了，论文却憋不出来，或者写出来像流水账。其实毕设论文是有章法可循的，只要按标准结构填充内容，再加上自己项目里的真实细节，很容易写出"像那么回事儿"的论文。

7.1 论文结构怎么搭

一般情况下，导师会要求包含这些章节：

• 绪论：背景与意义（校友工作数字化趋势、传统校友会管理痛点）、国内外研究现状（可以写校友会信息化平台逐渐从PC端向移动端转移）、本文主要工作；
• 相关技术介绍：Spring Boot、小程序、MySQL、Redis，每个技术要点一句话说明+为什么选它；
• 需求分析：角色分析、用例图、功能需求（用表格列功能模块）、非功能需求（安全性、性能、易用性）；
• 系统设计：总体架构图（不要用mermaid，画一张简单的分层图就行）、功能模块设计、数据库设计（ER图+核心表结构说明）；
• 系统实现：每个核心功能模块怎么实现的，贴关键代码片段而不是整段源码；
• 系统测试：测试环境、功能测试用例表、测试结果分析；
• 总结与展望：项目实现了什么、存在哪些不足（比如未接入真实支付、消息推送依赖站内信）、未来改进方向。

正文部分的代码展示很关键：不要大段贴代码，只贴核心方法（比如登录接口、报名事务那段），旁边配上解释文字。评委不会一行行读代码，但能看到你"关键逻辑是清楚写在论文里的"。

7.2 评审必问问题与回答思路

根据我见过的答辩现场，以下问题的出现率极高，提前准备好不吃亏：

• "你这个系统安全和隐私怎么做的？" 答：登录采用JWT无状态鉴权，后端拦截器统一校验；校友通讯录字段按认证状态动态返回；密码采用加密存储（BCrypt）；管理端有操作日志。
• "为什么用户表和校友表要分开？" 答：因为一个用户可能未认证或认证被驳回，用户账号与校友档案的生命周期不完全一致，分开表设计让认证状态的管理更清晰。
• "报名人数并发怎么控制？" 答：使用数据库行锁，在事务中先更新活动人数再插入报名记录，当前人数达到上限时报错回滚，保证数据一致性。
• "你在项目里用了缓存，缓存和数据库一致性怎么保证？" 答：本系统对一致性要求较高的活动报名、认证状态不缓存，只缓存资讯列表、活动列表等低频变更数据，更新时主动删除缓存（Cache Aside模式），保证最终一致即可。
• "小程序和后台共用一套后端吗？" 答：是，后端提供统一RESTful API，小程序端和管理端通过不同接口前缀（如 /api/alumni 和 /api/admin）访问同一服务，但鉴权规则不同。

这些问题都是顺着项目自然产生的，只要你在开发时真的想过"为什么这样设计"，回答起来非常顺。

7.3 现场演示的准备工作

演示翻车几乎是毕业设计最常见的悲剧现场，但90%的翻车都可以通过演练避免。我的建议是提前准备一个演示脚本，按照"校友登录→提交认证→管理员审核→发布活动→校友报名→查看通讯录→模拟捐赠→数据统计"这条主线走一遍，每个操作前想好对应的讲解词。

特别要注意的是演示数据的准备：数据库里预先造好10个左右的校友账号、5个活动、若干条资讯和留言。把演示账号的登录二维码提前准备好，现场直接扫码。活动报名演示时就报一个还"未满"的活动，别在答辩现场才发现活动人数已经满了按钮置灰——这种细节太影响印象分。还有，如果现场网络不稳定，小程序加载会很慢，备一台连手机热点的电脑，以及所有静态资源和接口走同一个地址，减少请求耗时的不确定性。

演示时间的控制也很重要。一般答辩演示时间在10到15分钟，按照脚本走刚好卡在10分钟左右比较理想，留出时间给评委提问。如果时间紧张，通讯录和留言模块可以口头带过，重点演示认证审核闭环和活动报名闭环。

写在最后的几点个人体会

带过不少同学做类似题目，我最大的感受是：毕业设计的价值不在于代码量有多大，而在于你能否把一个需求从零到一真正做完、讲清楚。 这个校友会系统放在真实企业里也许不值一提，但它让你走通了这样一条完整链路——需求怎么拆、表怎么建、接口怎么设计、小程序怎么对接、怎么部署、怎么答辩。这套思维方法到了实际工作中，无论你后面接触的是多复杂的系统，底色是一样的。

最后送上一个实用小技巧：整个项目开发过程中，从第一天起就保持写开发日志的习惯。每天花十分钟记录：今天做了什么、遇到什么问题、怎么解决的。等写论文时你会发现，所有内容都是现成的，你只需要把日志按章节归类，论文的"实验过程"和"问题分析"部分就信手拈来了。这个习惯比任何写作技巧都管用，我亲测有效。