做了好几年毕业设计指导也陆陆续续帮不少计算机专业的同学看过代码、梳理过项目发现一个规律能顺利通过答辩、拿到不错成绩的同学往往不是代码写得最花哨的而是能把一个系统的来龙去脉、设计取舍讲清楚的人。社区康养管理系统就是这么一类题目。它表面上是个常规的SpringBoot管理类系统但仔细拆解下来里面既有典型的多表关联业务、又有权限控制和数据统计还牵扯到需求边界这层很容易被忽略的东西。选这个题目的同学一年比一年多与其说是什么新鲜概念不如说它正好踩在难度适中、工作量饱满、技术栈主流这个黄金位置上。这篇文章我不打算给你贴一整篇可复制的代码那种东西你已经能从各种渠道拿到。我更想聊的是拿到基于SpringBoot的社区康养管理系统这个题目之后从选题分析到数据库设计、从核心代码思路到论文写法和答辩准备一条线该怎么走通以及开发过程中那些不写在课本里的坑。如果你正为毕设选题发愁或者已经在写这个系统但总感觉卡在某一步这篇文章应该能给你一些实际可用的参考。就算你最后不是照搬康养这个领域里面关于SpringBoot项目的设计方法和避坑思路一样能挪到别的题目上用。1. 为什么社区康养管理系统是当前毕设的高热度题目先别急着写代码搞清楚一个问题为什么那么多学校、那么多老师会认可这个题目第一它有清晰的社会需求背景。社区养老、居家康养这几年是实打实的热点方向社区服务中心需要给老人建档案、安排体检、管理上门服务、记录健康数据这些工作用Excel根本干不过来。一个系统能把这些线下流程线上化本身就具备现实意义。答辩的时候老师问你做这个有什么价值你完全可以说清楚它解决的是什么样的管理痛点而不是干巴巴地说这是教学需要。第二技术栈难度刚刚好。它不要求你搞人工智能、不要求搞大数据推荐核心就是SpringBoot做后端、MyBatis或MyBatis Plus操作数据库、MySQL存数据、Vue或Thymeleaf做页面。这几样是Java方向最普及的职业技能学起来资料多、问题容易搜到大四学生完全能独立搞定。同时它又不是那种一个CRUD就完事的玩具项目老年人口碑档案、服务预约、健康数据管理这些业务逼着你把表的关联关系理清楚这就保证了工作量。第三扩展性强。同一个骨架你可以根据自己学校的要求进行调整。比如有的老师要求必须有权限管理那你就在用户角色上下工夫有的老师要求有可视化图表那你就加个ECharts统计页面有的要求有在线支付那就可以对接模拟支付接口。系统边界是可伸缩的这个特点对毕设来说非常重要。就我实际接触的情况来看选这题的同学里认真做的和糊弄的差距一眼就能看出来。认真做的能把每个表字段为什么这么设计讲得头头是道糊弄的连自己的登录逻辑都说不清楚。所以这篇文章的核心目的就是帮你走到认真做那一边去。1.1 这个题目的任务边界是什么正式开始设计之前建议你先做一个动作把系统要管的事情列一个清单。社区康养的管理场景拆开来看通常包括这几个方面老人基本信息的管理姓名、性别、年龄、身份证号、住址、紧急联系人、既往病史、过敏药物等。健康数据的管理定期体检记录、血压血糖数据、用药提醒等。服务工单的管理上门护理、家政服务、陪同就医等服务的预约和派单。工作人员的管理护工、社工、志愿者的信息与排班。系统运营侧的管理公告发布、投诉建议、数据统计分析。这个清单就是你的需求范围。很多同学写论文的时候需求分析一章憋不出来就是因为没先把范围划清楚。你不需要做成一款商业产品那么庞大但上面这几条主线至少要有三到四条系统才撑得起来。1.2 康养域vs养老院域别把题目理解偏了特别想提醒你一点社区康养和养老院管理是两个东西。养老院管理系统的核心是床位管理、入住退住、院内护理它的主场景在院内而社区康养系统的主场景在社区是让老人住在自己家里由社区机构提供上门或驻点服务。简单概括就是前者是把人管进来后者是把服务送进去。如果把这个概念搞混了你的数据库设计、功能模块、论文里的背景描述都会出问题。比如说社区康养系统里不需要做复杂的床位占用状态管理但必须做好服务预约和上门工单的流转。概念边界清晰是你答辩时让老师觉得你真正理解题目的关键。2. 核心技术栈选型SpringBoot不是唯一选项但一定是最稳的选项很多同学纠结要不要用Spring Cloud、要不要上MQ消息队列、要不要用Redis缓存。我的建议很直接没有特别硬的理由就不要上重技术。毕设评分的核心从来不是技术多新多炫而是你有没有把掌握的技术用得合适、讲得清楚。SpringBoot单体架构足以支撑社区康养这类中小规模系统的全部需求你用Spring Cloud拆一堆微服务出来先不说开发和调试成本单是为什么要把一个社区级系统拆成微服务这个问题就很难在答辩时逻辑自洽地解释清楚。2.1 后端架构的选择逻辑核心选型我用一张表帮你理清楚这些都是Java毕设里最稳妥的组合技术组件推荐选型选择理由开发框架Spring Boot 2.x或3.x自动配置、内嵌Tomcat、生态成熟社区里能搜到大量解决方案ORM框架MyBatis Plus单表CRUD几乎不用写SQL分页插件好用适合快速出活数据库MySQL 5.7或8.0稳定、资料多、学校机房普遍有环境权限认证JWT或Spring Security二选一即可建议JWT 拦截器理解成本低、实现直观前端方案Vue3 Element Plus / Thymeleaf有前端基础用Vue前后端分离没有的话Thymeleaf最省事可视化图表ECharts社区康养系统天然适合做年龄分布、服务统计等图表有个问题容易被忽略但很关键Spring Boot版本别选太新。搜索热词里也有springboot版本太高这么一条这不是无病呻吟。我见过好几个同学装了个Spring Boot 3.4之类的最新版结果跟老版本的MyBatis Plus、某些JDK版本不兼容一启动就报错排查半天。做毕设不是追新选一个你自己最熟悉、资料最多的版本就好。比如Spring Boot 2.7.x经过大量项目验证遇到问题很容易找到解决方案。2.2 JDK与开发工具的环境一致性这边有个非常实用的建议整个项目链路尽量保持版本一致性。你们宿舍几个人可能用不同的JDK版本有人用JDK8、有人用JDK17就跑在同一个项目上。每次运行结果不一样出错了互相都不知道对方的运行环境。我在指导过程中一般要求这样做统一JDK版本团队如果你有队友内部用一个版本就用项目里pom.xml指定的那个。Maven仓库镜像用阿里云的否则下载依赖能卡到你怀疑人生。在settings.xml里配上阿里云镜像原生的Maven中央仓库在国内环境下体验很差。IDEA的编码格式统一为UTF-8很多中文乱码问题的根源就是编码不一致。这些基础环境问题看着琐碎实际上占据了毕设阶段求助问题的一半以上。先把环境理顺后面给代码排错才能聚焦到业务逻辑上。2.3 为什么建议用MyBatis Plus而非MyBatis如果你是我带的学生我会毫不犹豫地推荐MyBatis Plus。理由不复杂这个系统的大部分操作都是单表查询和简单的增删改MyBatis Plus能让你少写大量重复的Mapper XML。分页查询一句Page对象搞定逻辑删除一个注解搞定代码量直接减半。每个同学都会担心一个问题用MyBatis Plus答辩时老师会不会觉得没有技术含量我的回答是老师看的不是你有没有用原生SQL而是你能不能讲清楚框架帮你做了什么、你自己又做了什么。你能说明白BaseMapper提供了什么能力我选它是因为什么遇到复杂多表查询时我是怎么自己写SQL解决的这比什么都强。3. 数据库设计一张张表怎么拆关系怎么理数据库设计决定了你后面所有的代码好不好写。表关系理岔了代码就是打补丁表设计清楚了写Service层就像流水线作业。社区康养管理系统的表结构我建议围绕这样的主线来拆3.1 核心表清单与字段要点下面是我在一个实际项目中用过并且效果不错的表结构方案你可以根据自己的需求增减数据表作用关键字段建议user表系统登录用户id、username、password加密存储、role区分管理员/护工/老人、status、create_timeelderly表老人档案id、name、gender、birthday、id_card、phone、address、emergency_contact、medical_history、allergystaff表护工/社工人员档案id、name、phone、professional_level、service_type、statushealth_record表健康体检数据id、elderly_id、record_date、blood_pressure_high、blood_pressure_low、blood_sugar、heart_rate、noteservice_item表服务项目目录id、service_name、service_type、duration、priceappointment表服务预约工单id、elderly_id、staff_id、service_item_id、appointment_time、status待接单/进行中/已完成/已取消、address、remarkannouncement表公告信息id、title、content、publish_time、publisher_idmessage表消息通知id、from_user_id、to_user_id、content、status、create_time你可能注意到了老人表elderly和用户表user是分开的而不是直接合一张表。这是一个很重要的设计考量老人档案里的字段是业务属性病史、过敏药物、紧急联系人而用户表里是登录凭证用户名、密码、角色。把这两种字段硬塞进一张表会让表结构变得臃肿权限管理也不好理清。用user表里的elderly_id字段关联到elderly表各司其职。另外有几个字段设计细节供参考生日建议直接存日期而不是存年龄。年龄是要动态计算的直接存年龄会导致每年都得到数据库里批量更新而存生日只需要在展示时算一下这是一个典型的规范性做法。逻辑删除用deleted字段不要物理删除。老人档案这种数据删了可能还会有纠纷、有追溯需求用deleted字段标记比物理DELETE安全得多。MyBatis Plus加一个TableLogic注解就搞定了。金额字段用decimal不用double。涉及算钱、涉及金额统计的地方double浮点误差会让你在数据统计时对不上账这种坑我见得太多了。3.2 表关系怎么理解这个系统核心的关系其实就是一句话一个老人可以预约多个服务工单一个服务工单属于一个老人并由一个护工执行。用你学过的那套外键来理解就是appointment表里的elderly_id指向elderly表的主键staff_id指向staff表的主键service_item_id指向service_item表的主键。health_record表里的elderly_id指向老人这样就实现了老人与健康记录的一对多关系。画E-R图的时候我建议你按这个逻辑画老人实体是核心往外发散出健康记录、服务预约、消息通知护工实体和服务项目实体通过预约这个中间行为发生关联管理员实体独立在外围负责维护基础数据和查看统计。这样的一张E-R图答辩的时候老师扫一眼就能看出你对业务的理解程度。4. 从零搭建到出活核心模块的代码实现思路数据库设计好了之后开发顺序非常关键。很多同学从后台管理页面开始写结果界面写了一个多月核心逻辑还没动。我推荐的顺序是先搭框架 → 再做登录认证 → 再做核心业务 → 最后做页面和数据统计。4.1 登录认证模块JWT 拦截器的组合社区康养系统的权限其实只有三个角色管理员、护工、老人。你完全没有必要引入Spring Security那套复杂的过滤器链用JWT加一个HandlerInterceptor就可以解决代码量小、逻辑透明、答辩也容易讲清楚。思路是这样的用户登录时校验用户名密码。密码存储时用MD5加盐或BCrypt加密不要存明文。登录成功后用JWT工具类生成一个token里面带上用户ID和角色信息设置过期时间比如24小时。前端每次请求在请求头里带上Authorization: token。后端写一个LoginInterceptor实现HandlerInterceptor接口在preHandle里校验token的有效性同时把用户信息放到ThreadLocal里供后续业务使用。在WebMvcConfigurer里注册拦截器并配置放行路径登录接口、静态资源等不需要token就能访问。一个要注意的坑是token的过期时间别设太长也别太短。太长了有安全隐患太短了用户频繁掉线体验极差。做毕设的话24小时比较合适同时前端在请求拦截器里遇到401状态码就自动跳到登录页。核心代码骨架大致是下面这样Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 如果是预检请求直接放行 if (HttpMethod.OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (StringUtils.hasText(token) JwtUtil.validateToken(token)) { Long userId JwtUtil.getUserId(token); String role JwtUtil.getRole(token); // 放入ThreadLocal中后续业务代码可直接获取 UserContext.set(userId, role); return true; } // token验证失败返回401 response.setStatus(401); return false; } }这套流程下来登录模块大概三四个类就能搞定而且结构非常清晰答辩被追问时你也有话可讲。4.2 健康档案模块多表关联查询与时间线展示健康档案是社区康养系统的灵魂模块之一。老人的每一次血压、血糖、心率测量都应该形成一条health_record记录前端用时间线的方式展示出来比一张枯燥的表格直观得多。实现这个模块时你需要解决一个MyBatis Plus的典型问题health_record表里存的是elderly_id但页面上需要显示出这个老人的姓名那就得联查elderly表。MyBatis Plus的BaseMapper只提供单表操作这个时候就体现出你自己写SQL的能力了。我一般会在Mapper里自定义一个查询方法用XML或注解写联表查询Mapper public interface HealthRecordMapper extends BaseMapperHealthRecord { ListHealthRecordVO selectHealthRecordWithElderly(Param(elderlyId) Long elderlyId, Param(startDate) String startDate, Param(endDate) String endDate); }对应的SQL大概是这样的思路SELECT hr.*, e.name AS elderly_name FROM health_record hr LEFT JOIN elderly e ON hr.elderly_id e.id WHERE hr.deleted 0 AND hr.elderly_id #{elderlyId} AND hr.record_date BETWEEN #{startDate} AND #{endDate} ORDER BY hr.record_date DESC。查出来之后封装成一个VO对象视图对象既包含健康记录字段又带有老人姓名前端拿什么、后端就给什么。这里要说明一下自己会写多表SQL是一个毕设加分项有意识地展示这一点能帮你和那些纯靠框架的选手拉开差距。4.3 服务预约模块状态机的流转逻辑服务预约模块是另一个核心模块它的关键在于状态的流转。一个预约工单从产生到结束正常路径是待接单 → 已接单进行中 → 已完成同时还要考虑异常路径用户取消、护工拒单等。我的建议是为appointment表设计一个status字段取值用数字表示0待接单、1进行中、2已完成、3已取消。每个状态之间的转移规则写清楚待接单可以由老人取消变成已取消也可以由护工/管理员接单变成进行中。进行中只能变成已完成不允许直接跳回待接单。已取消和已完成是终态。在代码层面我建议不要直接在Controller里散落着各种状态判断而是抽一个AppointmentService里面专门写状态流转的方法每个方法里先校验当前状态是否允许流转然后再更新数据库。这个设计能避免很多隐藏的状态错乱bug答辩时讲我是如何保证数据一致性的也有素材可讲。4.4 数据统计模块让图表替你的系统说话如果时间充裕一定要做一个数据统计页面。用ECharts展示几个核心指标会带来非常直观的视觉加分。推荐展示这几类社区老人的年龄分布饼图让管理者一眼看到高龄老人占比。近六个月的预约服务数量柱状图观察服务需求量的变化趋势。各类服务项目的预约占比。统计SQL也不复杂比如年龄分布就可以用一条SQL搞定按年龄段分组统计人数用CASE WHEN判断区间再用GROUP BY分组。这类SQL写的熟说明你的SQL功底是过关的。5. 毕设开发高频报错与排查记录这个章节我想专门把开发中经常遇到的报错和排查过程写出来。虽然你拿到手的项目多半是完整可运行的但在修改、扩展功能的过程中这些问题迟早会碰到。5.1 Java时间序列化问题LocalDateTime报错如果你在前后端分离的项目里用了LocalDateTime类型并且不做特殊处理返回给前端的数据经常会变成一串数字时间戳或者报无法反序列化LocalDateTime之类的错误。这个问题的根因是Jackson这个JSON序列化库默认对LocalDateTime支持不友好需要你显式配置。最简单的解决方法是在application.yml里增设JSON序列化规则或者给字段加JsonFormat注解JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime createTime;这里有个细节容易踩时区问题。你存的时间本来是北京时间但因为时区偏差返回给前端可能差了8个小时。我建议把时区直接固定为GMT8别用服务器默认时区。5.2 时间字符串与SQL查询的边界坑在做健康记录的日期区间查询时如果你前端传的是2024-12-01这种日期格式而后端SQL用了BETWEEN startDate AND endDate你可能会发现12月1日当天的记录查不出来。原因是你传的结束时间是2024-12-01 00:00:00而不是2024-12-01 23:59:59。当天零点过后的记录全部被排到了区间之外。解决思路是在后端对结束日期做处理统一补上23:59:59// 如果endDate是yyyy-MM-dd格式 if (endDate.length() 10) { endDate endDate 23:59:59; }这个坑可以说是时间查询类bug里最高频的一个。你可以在自己的代码里预留一个公共方法处理这种时间参数以后所有区间查询都走这个方法。5.3 逻辑删除字段与唯一索引的冲突接前面提到的逻辑删除设计如果你在user表上给username加了唯一索引那么当你删除一个用户再重新注册同名用户时会插入冲突报错。原因是你只是把老用户标记成deleted1了但这条记录还占着唯一索引的位置。这类问题有几个解决思路唯一索引改成联合唯一索引比如(username, deleted)让同一个用户名在逻辑删除后可以被重新注册。注册时先查包括已删除用户在内的记录如果存在deleted1的同名记录就先物理删除或改掉旧用户名再插入。干脆不加唯一索引在代码里做唯一性校验。我一般推荐方案1改动最小逻辑也清楚。这些设计上的取舍你最好提前想清楚并准备好答辩时的说法。5.4 跨域问题前后端分离项目必看如果你用了Vue做前端、SpringBoot做后端你会发现前端访问后端接口时经常报Cross origin requests are only supported for protocol schemes或者Access-Control-Allow-Origin相关的错误。解决跨域的方式有很多我常用的是在后端配置一个CorsFilter的配置类允许特定来源的跨域请求而不是用CrossOrigin注解一个个Controller加。配置类一次解决全局问题而且答辩时讲起来也更专业。顺便说一句如果用了Spring Security还要额外处理安全过滤器链对跨域的拦截这也是很多跨域配置配了但没用的常见原因。6. 项目演示与远程调试拿到源码后怎么快速跑通并讲清楚这个题的标题里有远程调试、讲解这些词侧面说明很多同学买源码、下源码之后遇到的最大困难不是看不懂代码而是根本跑不起来或者跑起来不会讲。6.1 本地运行的标准步骤拿到一个完整的SpringBoot项目后按顺序做这几件事检查JDK版本在命令行执行java -version确认你的JDK版本和项目pom.xml里指定的版本一致。检查Maven配置Maven的settings.xml里配好了阿里云镜像打开IDEA后让Maven重新加载项目等依赖下载完成。依赖下载失败是新手最常卡住的点。准备数据库在MySQL里新建一个空库字符集选utf8mb4然后执行项目里提供的SQL脚本。这一步注意脚本执行顺序先建表再插入数据。修改配置文件打开application.yml把数据库地址、端口、账号密码改成你本地的。启动项目运行主类上的main方法看到Spring Boot的启动日志不再报错最后一行出现Started Application in x.xxx seconds说明启动成功。访问接口和页面本地浏览器访问http://localhost:8080端口看你配的用初始账号密码登录。其中第三步尤其容易出问题很多学生拿到SQL脚本直接双击用Navicat打开结果字符集不对、中文字段全是乱码。正确的做法是用命令行或Navicat新建查询执行脚本而不是把SQL文件拖进去导入。你可以在执行前检查一下SQL脚本第一行有没有SET NAMES utf8mb4;这样的设置。6.2 远程调试别人帮你排查问题或你帮别人演示时的利器远程调试这个词听起来高大上其实原理就是让本地的IDEA连接到服务器上已经运行的Java进程然后像调试本地代码一样打断点、看变量值。具体配置步骤是这样的在启动项目的命令或IDEA的运行配置里加上JVM参数-agentlib:jdwptransportdt_socket,servery,suspendn,address5005这个参数的意思是开放5005端口允许调试器连接连接时不暂停程序启动。然后在本地IDEA里右上角选择Edit Configurations新增一个Remote JVM Debug配置Host填服务器的IPPort填5005然后点Debug按钮就能连上远程进程打断点了。在我们这边做远程调试的实操场景里最常见的是帮学生排查本地能跑、服务器上跑不起来的问题有几类原因很典型服务器上的Java版本和本地不一致。服务器上的MySQL端口没对外开放连接被拒绝。配置文件里用了本地的绝对路径或localhost指向不对。远程调试的方式去排查这类问题非常高效因为它能让你直接看到对方运行环境里的实际数据而不是反复问你报错信息发我一下。6.3 演示时应该展示哪些模块拿到源码跑通后练习演示时可以围绕这样一条线索来讲比照着页面念名字专业得多先打开系统首页或登录页介绍系统的定位是服务社区老人的一个管理平台然后登录管理员账号按业务顺序演示新建老人档案 → 录入一份健康记录 → 创建一个服务项目 → 模拟老人预约服务 → 护工接单 → 标记完成 → 最后打开统计页面看数据变化。每一步操作之间讲清楚你做了什么、数据存到哪里去了、背后的关键代码是什么。比如演示预约服务时可以顺手打开数据库看一眼appointment表里多了一条状态为待接单的记录这是很有说服力的细节。能边操作边讲清数据流转你已经跑赢了大部分同学。7. 论文与答辩准备的实用思路最后说一下论文和答辩。很多同学代码写完了论文憋了一个月问题在于不知道怎么把代码表现成文字和图表。7.1 论文结构的组织方式一般学校毕设论文都有模板大体逃不开绪论背景、国内外现状、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结这几个大章节。其中最重要的两章是需求分析和系统设计。需求分析章节别光写一堆功能性需求泛泛的话要配合用例图、用例描述表来说。系统设计章节要放总体的架构图、功能结构图和数据库E-R图然后分模块写清楚每个模块是干什么的。写论文的时候记住一个原则你写的每一句话都最好能找到对应的代码支撑。比如写到系统使用JWT实现无状态认证后面实现章节就必须真的有JWT工具类、有拦截器的代码截图。前面吹的技术后面一定要兑现这是论文顺利通过的基本保障。7.2 图表怎么准备图表是答辩环节老师看的时间最长的东西建议认真准备这几张系统功能结构图用树状图展示所有模块简洁清晰一眼看懂系统全貌。系统架构图展示浏览器端、后端Controller层、Service层、DAO层、MySQL数据库的层次关系。E-R图把核心表之间的关系图画清楚注意关系和表字段要对上。核心业务的流程图比如服务预约的状态流转图用来展示业务逻辑的严谨性。画图的时候注意不要画得过于复杂每个图聚焦一件事。E-R图一堆表全画上去反而显得混乱建议分模块画局部E-R图。7.3 高频答辩问题清单根据我的经验针对这个题目老师大概率会问到下面这些问题你可以提前准备答案保证回答时思路清晰为什么选SpringBoot而不选SSH可以从自动配置、内嵌容器、简化部署、生态活跃这几个角度回答。你的系统有哪些角色权限是怎么控制的答管理员、护工、老人三元角色用JWT携带角色信息配合拦截器校验。数据库为什么这么设计有哪些标准化的考虑举例说明三个范式与冗余之间的权衡比如老人表单独拆分的原因。如果并发量大系统哪些地方可能出现瓶颈怎么应对可以先说实话这类社区平台的并发量通常不大然后从数据库连接池、索引优化、Redis缓存静态数据、SQL优化这几个方向谈一些优化思路。系统有哪些不足之后打算怎么改进千万别说什么没有不足每个系统都有优化空间你可以提引入消息队列异步处理预约通知、引入Redis做会话共享、增加更细粒度的权限模型等等。第5个问题尤其重要。老师问不足考察的是你对自己项目的客观认知和技术视野。提前想好两三个合理的不足和改进方向哪怕只是打算将来做也比当场愣住强得多。7.4 个人体会这个项目教会我的事带过这么多毕设我自己最大的体会是能拿优秀的同学通常都具备同一种能力把会用的技术和能讲清楚的技术合二为一。这也是我在这篇文章里反复强调理解要能讲清楚的原因。做一个社区康养管理系统最后学到的绝不只是SpringBoot的注解怎么写、MyBatis Plus的CRUD怎么调。把需求边界划清楚、把表结构一遍遍推翻重来、把状态流转梳理成一条不矛盾的逻辑这些东西才是毕业设计真正的收获。最后分享一个很实用的小技巧整个开发过程中每完成一个模块就给自己录一分钟的讲解视频。到答辩前你会积累一批素材既是你讲稿的底子也能帮你发现自己逻辑上讲不顺的地方。这个方法我带过的学生用了都说值你可以试试。