企业官网建设流程全解析

简介：这套SSM+Mysql的决策树就业预测系统，面向计算机相关专业毕业设计或期末大作业场景，适合需要完成个人用户、企业用户、管理员等多角色功能开发的学习者。系统基于SSM框架与Mysql数据库，引入决策树算法对学生就业信息进行预测分析，并覆盖招聘发布、职位申请、就业信息管理、可视化数据查看等典型模块，可帮助理解分层权限设计与业务闭环。压缩包约70.36MB，包含源码、论文、开题报告、部署文档、运行说明和演示视频，其中论文与开题报告可用于选题与撰写参考，部署文档和运行说明能降低环境搭建门槛，演示视频方便快速掌握系统操作流程。已有57人浏览学习，通过源码可快速搭建项目骨架，借助论文理解决策树算法在就业预测中的建模思路，运行说明则提供排错方向；整套资料适合用来支撑毕设答辩、期末大作业汇报或项目二次开发。

1. 大学生就业预测系统到底是什么：一套能答辩的SSM+MySQL工程，核心是决策树算法

如果看到“基于SSM+Mysql的基于决策树算法的大学生就业预测系统(源码+论文+开题报告+部署文档+运行说明+演示视频).zip”这个标题，第一反应应该是：这是一套Java课程设计。SSM+Mysql说明技术栈是Spring+SpringMVC+MyBatis加MySQL数据库，决策树算法说明里面有一个能跑通“训练+预测”的算法模块，后面跟着源码、论文、开题报告、部署文档、运行说明、演示视频，这不是一个纯Demo，而是一份能直接交给评审老师、能答辩、能复现的完整工程。这套东西解决的问题很具体：用大学生在校期间的基本特征——性别、学历、专业、GPA、实习次数、证书数量、技能等级——去预测就业结果，比如“是否就业”“薪资区间”“就业去向”，并且把每一步判断原因用决策树的方式摆在眼前，而不是给一个说不清依据的黑匣子结果。适合两类人：一是急着完成Java课程设计或毕业设计、需要基于SSM框架的项目源码做二次开发的学生；二是想弄明白决策树算法怎么从页面展示、后端接口到数据库全链路落地的一线开发。先说个反直觉的结论：这类项目的真正难点不在决策树算法本身，而在工程化——训练好的树怎么存、接口怎么接、页面怎么调、参数怎么传，这些环节才是让你熬夜翻车的地方。

2. 为什么是决策树+SSM+MySQL：先搞懂选型逻辑，再决定怎么改

2.1 决策树算法凭什么适合就业预测：从信息增益到一条条能答辩的解释路径

就业预测本质是分类问题：给定一组学生特征，输出分类标签。标签可以是二分类（就业/未就业），也可以是多分类（高薪就业/普通就业/未就业）。决策树算法做这件事的逻辑很直白：递归地选特征去划分数据集，让每个子集越来越“纯”。纯度用信息熵衡量，公式是 H(S) = -Σ p_i * log2(p_i)，样本分布越平均，熵越大；越偏向某一类，熵越小。每次划分时算各特征的信息增益（ID3）、信息增益率（C4.5）或基尼指数（CART），挑最大的那个作为分裂点，递归直到叶子节点都是单类别、没有可用特征或达到停止条件。

举例算一遍。假设有15个学生样本，9人就业、6人未就业，当前熵 = -9/15log2(9/15) - 6/15log2(6/15) ≈ 0.971。如果按“是否有实习”切分：有实习的8人全部就业，子集熵为0；无实习的7人里1人就业、6人未就业，熵 ≈ 0.592。加权熵 = 8/15 * 0 + 7/15 * 0.592 ≈ 0.276，信息增益 = 0.971 - 0.276 = 0.695。而按“性别”切分算出来的增益小得多，于是算法优先选“实习经历”作为根节点的分裂特征。这样的决策路径是透明的，答辩时老师问“这个学生为什么被预测为高薪就业”，你可以指着树说：因为GPA≥3.5、实习次数≥2次，一路走到了这个叶子节点。换成随机森林、神经网络就讲不出这种可解释的故事了，这也正是决策树算法在课设里吃香的原因。

2.2 SSM+MySQL为什么是这门课设的“标准答案”：分层清楚、资料多、好写论文

SSM是Spring、SpringMVC、MyBatis三个框架的组合。Spring管Bean生命周期和事务，SpringMVC管HTTP请求分发和参数绑定，MyBatis管SQL语句与对象映射。MySQL负责存学生原始数据、就业标签、预测记录，以及序列化后的决策树结构。选这个组合有几个现实理由。一是大批高校的Java课程设计题目默认就是SSM，老师熟悉、网上可搜到的参考资料多，遇到问题不用从零摸索。二是三层架构和论文的“系统总体设计”天然对应，Controller层对应表示层、Service层对应业务逻辑层、Mapper层对应数据访问层，画系统架构图、写用例说明都顺手。三是部署门槛低，Maven打包成war包扔进Tomcat就能跑。

相比之下，Spring Boot单体应用虽然更现代，但有些学校的验收环境还停留在Tomcat加war包的教学体系里，SSM更稳妥。MyBatis也适合这种表结构相对固定的项目，学生表、就业表、用户表关系简单，手写SQL反而比JPA的自动映射更直观。这套源码本身就是一个java课程设计案例源码的标准范本，拿到它以后，改成“考研预测系统”“公务员上岸预测系统”也很方便，只要把学生特征字段和标签换掉，算法代码基本不用动。

2.3 压缩包里每个文件是干什么用的：源码、论文、开题报告、部署文档、运行说明、演示视频

拿到这个.zip，先别急着解压跑代码，先按文件规划使用路径。源码是Maven工程，目录结构大致是src/main/java、src/main/resources、webapp，里面包含决策树训练器、预测Service、登录模块和页面。论文和开题报告是Word格式，前者约一到两万字，用于提交给导师查阅；后者是开题时的选题依据，包含研究背景和可行性分析。部署文档相当于一份mysql安装配置教程的浓缩版，从JDK安装到MySQL建库、Tomcat启动都有；运行说明会写默认管理员账号、页面入口地址、启动顺序；演示视频是录好的操作录屏，从启动系统到录入特征、查看预测结果的完整过程。

我的经验是：先看部署文档而不是源码，把环境跑通，再回头读代码。原因很简单——源码里的数据库密码、端口、包名经常跟部署文档不一致，你对着文档把环境搭好，再用文档里的账号去登录页面，能第一时间发现问题出在文档还是代码。跑通之后再读代码，你才能把“树怎么建”“接口怎么调”落到实处，否则看着一堆Java文件只能干瞪眼。

3. 把就业数据喂给决策树：表结构设计、训练代码与预测接口的落地路数

3.1 数据库表设计：学生表、就业标签表、预测记录表怎么建才方便

这一步直接决定后面写Mapper和训练逻辑的顺畅程度。设计三张主表就够了。学生基础信息表student，存大学生在校特征；就业结果表employment_result，存训练用的标签数据；预测记录表prediction_record，存用户通过页面提交特征后产生的每次预测结果。建表SQL如下：

CREATE DATABASE IF NOT EXISTS employment DEFAULT CHARSET utf8mb4; CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) UNIQUE COMMENT '学号', name VARCHAR(50), gender TINYINT COMMENT '0-女 1-男', education_level VARCHAR(20) COMMENT '专科/本科/硕士', major VARCHAR(50), gpa_level VARCHAR(10) COMMENT '优/良/中/差', intern_count TINYINT COMMENT '实习次数', cert_count TINYINT COMMENT '证书数量', skill_level VARCHAR(10) COMMENT '初级/中级/高级' ); CREATE TABLE employment_result ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT, is_employed TINYINT COMMENT '0-未就业 1-就业', salary_level VARCHAR(20) COMMENT '低/中/高', job_type VARCHAR(30) COMMENT 'Java开发/产品/测试等', company_level VARCHAR(20) COMMENT '大厂/中厂/小厂' ); CREATE TABLE prediction_record ( id INT PRIMARY KEY AUTO_INCREMENT, input_json TEXT COMMENT '页面提交的特征原始JSON', predict_result VARCHAR(50), create_time DATETIME, algorithm_version VARCHAR(20) );

这里有个关键决策：GPA、实习次数这类连续值不要直接进决策树。ID3和C4.5处理连续值要额外做二分阈值扫描，课程设计代码容易写崩。常见做法是在数据库层面或Java预处理阶段把连续特征离散化，GPA变成“优/良/中/差”，实习次数变成“0次/1-2次/3次以上”。gender这类枚举也建议用TINYINT存数字，而不是存中文字符串，否则前端传值和树的特征分支匹配会徒增很多坑，具体在避坑章节展开。数据库字符集统一用utf8mb4，别用latin1，否则中文报错是必然的。

3.2 决策树训练的Java实现：从计算熵到递归建树的核心代码

训练器的实现以ID3为主，这是课程设计里最常见的版本。数据结构用一个TreeNode表示树节点，成员包含分裂属性、属性取值到子节点的映射、叶子节点的分类结果。训练入口接收List<Map<String, String>>形式的样本集，每条Map是一行学生特征加标签。核心代码如下：

public class DecisionTreeTrainer { private int maxDepth = 5; // 最大深度，防止过拟合 private int minLeafSample = 3; // 叶子节点最少样本数 public TreeNode buildTree(List<Map<String, String>> data, List<String> attributes, int depth) { // 统计当前数据集中标签分布，决定是否需要停止 Map<String, Integer> labelCounts = countLabel(data); if (labelCounts.size() == 1 || attributes.isEmpty() || depth >= maxDepth || data.size() < minLeafSample) { TreeNode leaf = new TreeNode(); leaf.setResult(getMajorityLabel(labelCounts)); return leaf; } // 选择信息增益最大的属性作为当前分裂特征 String bestAttr = chooseBestAttribute(data, attributes); TreeNode node = new TreeNode(); node.setAttribute(bestAttr); Map<String, List<Map<String, String>>> split = splitByAttribute(data, bestAttr); // 剩余属性集合去掉当前分裂属性，递归构建子树 List<String> remainAttrs = new ArrayList<>(attributes); remainAttrs.remove(bestAttr); for (Map.Entry<String, List<Map<String, String>>> entry : split.entrySet()) { node.getChildren().put(entry.getKey(), buildTree(entry.getValue(), remainAttrs, depth + 1)); } return node; } private double calcEntropy(List<Map<String, String>> data) { Map<String, Integer> labelCounts = countLabel(data); double entropy = 0; for (int count : labelCounts.values()) { double p = count * 1.0 / data.size(); entropy -= p * (Math.log(p) / Math.log(2)); } return entropy; } private String chooseBestAttribute(List<Map<String, String>> data, List<String> attributes) { double baseEntropy = calcEntropy(data); String bestAttr = null; double maxGain = -1; for (String attr : attributes) { double weightedEntropy = 0; // 按当前属性的每个取值切分数据 Map<String, List<Map<String, String>>> split = splitByAttribute(data, attr); for (List<Map<String, String>> subset : split.values()) { weightedEntropy += subset.size() * 1.0 / data.size() * calcEntropy(subset); } double gain = baseEntropy - weightedEntropy; if (gain > maxGain) { maxGain = gain; bestAttr = attr; } } return bestAttr; } }

这段代码里最容易踩坑的是熵计算。Math.log(0)在Java里会得到一个负无穷值，进而让整个熵变成NaN，所以在countLabel后要判断count是否为0，实际工程建议在calcEntropy里跳过count==0的分支。maxDepth和minLeafSample是控制过拟合的最直接参数，数据量在几百条级别时maxDepth取5到7、minLeafSample取3到5比较合适，树越深预测越“精确”但泛化越差。splitByAttribute返回的Map的key是属性值（比如“男”“女”“优”“良”），这些值必须跟预测接口接收到的前端参数保持一致，否则查询时匹配不到子节点，会一路走到null导致bug。

3.3 把训练好的树用起来：序列化存储与预测接口设计

训练只做一次，但预测要做很多次，所以必须把树结构持久化。常见做法有两种：一种是序列化成JSON文件放到resources目录，另一种是建一张树节点表用递归查询。我推荐JSON文件方案，代码量小、直观、答辩时容易讲清楚“树已经存在本地了，不需要每次重启都重算”。一个节点结构用JSON表示大概是这样的：

{ "attribute": "intern_count", "children": { "0": {"attribute": "gpa_level", "children": {"优": {"result": "就业"}, "良": {"result": "未就业"}}}, "1-2": {"result": "就业"}, "3以上": {"result": "高薪就业"} } }

对应地，预测端SpringMVC的实现用一个Controller加一个Service。Controller负责接收前端POST上来的学生特征JSON，Service负责加载树并逐层命中分支。

@Controller @RequestMapping("/predict") public class PredictController { @Autowired private PredictService predictService; @RequestMapping(value = "/result", method = RequestMethod.POST) @ResponseBody public Map<String, Object> predict(@RequestBody Map<String, Object> input) { String result = predictService.predictByJson(input); predictService.saveRecord(input, result); // 保存预测记录 Map<String, Object> resp = new HashMap<>(); resp.put("data", result); return resp; } }

Service里的predictByJson方法，加载类路径下的tree.json反序列化成TreeNode，然后一层层往下走：取当前节点的attribute名，从input里取出对应的值，再到children里找下一个子节点，直到遇到带result的叶子节点。对前端传null或缺失字段的情况，我一般会返回“特征不足，无法预测”，并且把这次请求的原样JSON存到prediction_record里，避免用户刷页面时猜来猜去。这个规则一定要在论文里写明，评审老师最容易问“缺失值怎么处理”，能答出这一条，比空泛地说“算法很好”要有说服力。

4. 用SSM+MySQL在本地跑通整套系统：版本匹配、配置改动与打包部署

4.1 环境版本匹配：JDK、Maven、MySQL、Tomcat怎么选不踩坑

这类SSM老项目的环境坑比业务代码多得多。先给一套经过验证的版本组合：JDK 1.8、Maven 3.6.x、Tomcat 8.5、MySQL 5.7。JDK 1.8是必须的，如果你机器装了JDK 11或17，Spring 4.x的CGLIB代理会报IllegalArgumentException，这类老框架对高版本JDK兼容极差。MySQL 5.7比8.0省心，因为8.0默认的密码加密方式caching_sha2_password需要连接器8.x配合，老SSM工程里如果用的是mysql-connector-java 5.1.x，连数据库会直接报“Unable to load authentication plugin”错误。如果你手头只有MySQL 8.0，要么把pom里的依赖升到8.0.29以上，要么建用户时指定老加密方式：

CREATE USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';

pom.xml里关键依赖版本写成这样：

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.3.20</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.11</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.29</version> </dependency>

这里用Spring 5.3是因为它在Servlet 3.x容器上表现稳定，又不挑Tomcat 8.5。需要注意mybatis-spring的版本要跟MyBatis配套，3.5.11的MyBatis建议用mybatis-spring 2.0.7，版本太老会扫描不到Mapper接口。

4.2 数据库初始化和配置文件改动：三处最容易错的地方

先把部署文档里的SQL文件在MySQL里执行一遍，如果文档里的SQL缺失，就按第3章的表结构自己建。然后打开工程里的jdbc.properties，重点改三处：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/employment?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=123456

第一处是driver，MySQL 8.0的连接器用com.mysql.cj.jdbc.Driver，老工程里的com.mysql.jdbc.Driver虽然能兼容但会在启动时打印废用警告。第二处是url里的serverTimezone=Asia/Shanghai，不加这一条，8.0连接器会在运行时报SQLException: The server time zone value 'CST' is unrecognized。第三处是useSSL=false，本地环境没有SSL证书，保持true会握手失败。spring-mybatis.xml里数据源和Mapper扫描的配置：

<bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource"> <property name="driverClassName" value="${jdbc.driver}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> <property name="initialSize" value="5"/> <property name="maxTotal" value="20"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean> <mybatis:scan base-package="com.example.sys.dao"/>

比较隐蔽的一个问题是，某些SSM工程会在pom.xml里没加 标签，导致src/main/java下的Mapper.xml没有被打进最终war包，运行时报Invalid bound statement。解决办法是在pom.xml里显式声明：

<build> <resources> <resource> <directory>src/main/java</directory> <includes><include>**/*.xml</include></includes> </resource> <resource> <directory>src/main/resources</directory> </resource> </resources> </build>

4.3 打包运行与验证：从IDEA打war包到Tomcat启动

用IDEA打开源码工程，等待Maven导入完依赖，然后执行mvn clean package，在target目录下得到ROOT.war或项目名.war。把这个war包复制到Tomcat的webapps目录，Windows下双击bin/startup.bat，Linux下执行bin/startup.sh。启动日志里如果出现Deploying web application archive的字样，说明war包已经在解压部署了。控制台不报错不代表万事大吉，要看页面能不能通。

验证顺序我一般是：先访问http://localhost:8080/登录页，输入运行说明里的管理员账号密码；然后进入“就业预测”页面，手动输入或下拉选择一组学生特征，比如性别男、学历本科、GPA良、实习1-2次，点击预测；最后回到MySQL执行SELECT * FROM prediction_record ORDER BY id DESC LIMIT 1，确认页面返回的结果落在预测结果字段里。整套流程走通，再开始动代码。演示视频一般也是这个顺序，你可以照着录一遍自己的环境，答辩时让老师看实际效果比看视频更有说服力。

5. 避坑与排查：决策树预测不准和SSM启动失败的常见问题

5.1 决策树训练集准确率100%，测试集只有六成：过拟合怎么解

现象：训练代码在控制台输出准确率100%，把数据集分成训练集和测试集后，测试集准确率只剩60%出头。

原因：树没有任何停止限制，把所有样本的特征组合都记下来了。这里有两个典型诱导因素，一是maxDepth没设置或设得很大，树无限分裂；二是数据里有“学号”“姓名”这类全局唯一特征，信息增益极高，根节点直接按学号分裂，每个叶子只剩一条样本，训练准确率必然100%，对测试数据毫无泛化能力。

解决：在buildTree的停止条件里强制加maxDepth=5和minLeafSample=3；训练前把特征列表里的学号、姓名、ID全部过滤掉，只保留真正跟就业相关的属性。另外可以把数据集按8:2切分，80%训练、20%测试，交叉检验准确率，这是论文里必须写的数据。参数初调时先maxDepth=5，如果验证集准确率仍然低，试着把minLeafSample调到5，或者改用C4.5的信息增益率做特征选择。

5.2 MySQL连接报错：从连接器版本到时区、密码策略的三连坑

现象：IDEA里启动Tomcat，后台日志报ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost:3306'，排查了半天MySQL明明开着。还有的工程能连上，但跑几分钟就断，报2006 MySQL server has gone away。

原因：2003通常是MySQL端口没监听或连接器旧。2006通常是因为连接池的空闲连接超过wait_timeout被服务端断开，代码池拿到的是死连接。额外的一坑是MySQL 8.0的认证插件不对，报Unable to load authentication plugin。

解决：先在本机命令行敲mysql -uroot -p，看本地客户端能不能登录，能登录说明MySQL是好的，问题出在连接参数。然后在jdbc.url里加上serverTimezone=Asia/Shanghai&useSSL=false，驱动换成com.mysql.cj.jdbc.Driver。最后在数据源配置里加一条连接保活，比如testWhileIdle=true和validationQuery=SELECT 1。这三件事按顺序做，能解决九成MySQL连接相关报错。

5.3 SSM框架启动报找不到Mapper或接口注入失败

现象：Tomcat启动后，访问带数据库操作的页面报Invalid bound statement (not found)，或者启动时直接报NoSuchBeanDefinitionException，说是找不到UserDao的实现类。

原因：Mapper接口和Mapper.xml没有绑定。常见三种：一是mybatis的mapperLocations配的是classpath:mapper/*.xml，但实际XML在java目录里，没被打进target/classes；二是@MapperScan(“com.example.sys.dao”) 扫描的包路径和接口实际所在包不一致；三是MyBatis要求Mapper.xml的namespace必须是接口的全限定名，例如com.example.sys.dao.UserDao，少写一个.都匹配不上。

解决：先到target/classes目录看有没有mapper/UserDao.xml文件，没有就补pom.xml的resource配置；然后检查spring-mybatis.xml里mybatis:scan的base-package和XML里的namespace双重确认。我自己遇到过一晚上查不出原因的情况，最后发现是XML的文件名和接口名差了一个字母，这种错IDEA不会报编译错误，只能对着名字一个个看。

5.4 JSP页面中文乱码：从请求到数据库到响应三处编码

现象：页面上显示的学生姓名变成“???”，往数据库插入的中文直接变成问号，或者响应返回是乱码。

原因：编码链路断了。JSP页面本身没设置pageEncoding；MySQL连接URL里没加characterEncoding=utf8；数据库表用的是latin1字符集；SpringMVC的请求编码过滤器没加上。四环中任何一环缺失，中文必乱。

解决：把四处一次性补齐。JSP页头加contentType="text/html; charset=UTF-8"；jdbc.url里加useUnicode=true&characterEncoding=utf8；建数据库时用DEFAULT CHARSET utf8mb4，而不是latin1；web.xml里加CharacterEncodingFilter，强制所有请求和响应走UTF-8：

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

5.5 预测结果总是“未就业”或直接空指针：小心特征值匹配不上

现象：页面下拉框选择“男”，后端返回的result是“未就业”，但训练数据里“男”这个分支明明指向“就业”；更有甚者，点击预测后直接500空指针。

原因：决策树训练时属性值是数字0/1，前端传上来的是中文字符串“男”“女”，程序拿“男”去树的children里找key为0的子节点，找不到就落到默认叶子；空指针是因为找不到时直接对null做了getResult。

解决：统一特征值字典。前端下拉框value直接写0/1/2，不要写中文文本；后端接收参数后做一层转换，Map里的key保持和训练时完全一致；预测方法里对子节点找不到的情况做兜底，返回父节点占比最高的类别，而不是null。另外测试数据里可能出现训练阶段没见过的学历值，比如训练集只有本科和专科，预测时来了个“博士”，这类情况最好在接口层直接拦截校验，提示用户录入范围之外的特征值。

6. 让这套系统更好用：后剪枝、5折交叉验证与决策树可视化改进

跑通主流程只是基线版本，要做成一门高分课设，还有三个投入产出比很高的改进点。第一个是后剪枝。决策树训练完，可以用自下而上的方式判断：把某个非叶子节点替换成其子树里样本最多的叶子，如果验证集准确率不降甚至上升，就进行替换。实现上不需要改训练器，只要在树JSON里遍历节点，把每个内部节点尝试改成叶子，比较替换前后在验证集上的准确率，保留更优的树结构。这个处理能让树变小，讲起来也更符合“避免过拟合”的工程思想。

第二个是5折交叉验证。把数据集平均分成5份，每次用4份训练、1份测试，轮换5次，最后取平均准确率作为模型指标，顺便算一下标准差。交叉验证的精度比单次切分更有说服力，论文里写“平均准确率87.2%±2.1%”会让老师觉得你做了充分的实验对比。第三步是可视化。决策树不画出来就少了最大的卖点。常见做法是让后端新增一个treeJson接口，把反序列化后的树结构转成ECharts树图的格式：

{ "name": "根节点", "value": "是否有实习", "children": [ {"name": "无实习", "value": "未就业"}, {"name": "有实习", "value": "就业"} ] }

页面上用ECharts的tree系列画出来，鼠标悬停能看到每个分支的样本数和分类结果。演示视频里把树图展示出来，再配合“这个分支是因为GPA大于3.5”的解释，整个答辩效果完全是另一个档次。我自己做这套系统的顺序是先跑通默认代码，再改maxDepth、交叉验证拿到准确率，最后画树图，每一步都在本地手动插入几条边界数据验证预测结果。这个习惯帮我避开了很多“演示时点一下就崩”的翻车现场。如果你也要拿这套工程去交作业或继续开发，请务必在答辩前把树图和数据验证一起过一遍。希望帮到你。

本文还有配套的精品资源，点击获取