简介该压缩包面向电力行业自动化工程师、SCADA系统开发者及电力信息化运维人员提供一套基于Java的电力监控人机接口HMI后台源码覆盖数据采集、实时曲线展示、数据库存储与远程交互等常见场景。包内共51个文件以JSP页面、Java类、JAR依赖库为主同时包含GIF图标、XML配置和数据库连接池相关配置便于理解前端展示、业务逻辑与后台数据服务的组织方式。资源大小2.45MB已有563人学习。借助源码可快速搭建电力监控原型掌握SCADA/HMI开发中PostgreSQL存储、Proxool连接池应用及JSP曲线页面的实现思路并可在其基础上定制报警、统计与调度接口。1. 电力监控后台就该这么拆一份 SCADA HMI 源码包的完整落地笔记电力行业的监控后台从来不是个简单网页我拿到这份 SCADAHMI.rar 源码压缩包的第一反应是这玩意儿能把「数据采集 → 数据库存储 → 实时曲线展示 → 报警联动」整条链路都打通而且用的是 Java PostgreSQL Proxool 连接池这套相当正统的电力监控技术栈不是拿什么报表工具糊弄出来的假后台。它内部十几个 jsp 曲线页面和 Applet 组件把 HMI 交互层讲得明明白白适合正在做电力监控、能源管理、设备远维的工程师拿来改造成自己的东西。对新手来说它是理解 SCADA 后台代码组织方式的活教材对熟手来说它是可以快速裁剪复用的电力后台底座。接下来我从源码结构、曲线页面、数据库配置到部署排错一条线拆完。2. SCADA 与 HMI 的架构关系先搞懂谁在干活、谁在画图2.1 SCADA 后台的核心职责与数据流SCADA 在电力监控领域的中文全称是数据采集与监控系统它解决的问题是「电网设备状态我到底怎么实时知道」。我拆过的监控后台项目里SCADA 的角色永远是承上启下向下对接变电站的测控装置、保护装置通过 61850 或 Modbus 这类规约把遥测、遥信数据拿上来向上给 HMI 层提供实时数据库、历史数据库和报警服务。这份源码里的 SCADA 后台部分走的正是这种典型结构。src 目录下承载着数据采集和业务逻辑的 Java 类WebRoot 目录下是表现层。我把它理解成一条单向数据管道设备层遥测/遥信采集 → 采集线程 → PostgreSQL 实时库 → HMI 页面曲线/刷新/报警这里有个容易被新手忽略的地方SCADA 后台不是把原始数据直接甩给页面而是先经过规约解析、质量戳标记、越限判断三道工序再进数据库。所以你在源码里会看到大量和数据处理相关的 Java 类而不是简单的 CRUD。判断一份 SCADA 后台代码是否专业第一眼看它对数据质量的处理第二眼看它对实时性的保证方式。2.2 HMI 的呈现逻辑为什么是 JSP 加 Applet 的组合HMI 即人机接口它的核心要求是「数据刷新不能黑屏、操作反馈不能超过 3 秒」。这份源码里 HMI 层用 JSP 动态页面加 URLApplet 小程序实现这个组合在电力监控圈里很常见原因很简单JSP 适合做表格、曲线、状态列表这类信息展示Applet 适合做需要更底层网络访问和绘图操作的交互组件。我逐页看过去WebRoot 下的每个 xjCurve、qlCurve、jzCurve 页面对应的是不同监测对象线路曲线、功率曲线、接地曲线、温度曲线。它们的共同逻辑是页面加载时从 Applet 或后端 Servlet 拉取最近 24 小时或当天的采样数据用 Java 2D 绘图把曲线渲染出来定时轮询最新数据追加到曲线尾部这种设计放到今天看不算新潮但它的好处是结构非常清晰页面只干展示的活数据来源统一走后端接口便于二次开发时替换前端框架。2.3 工程结构的目录分层与职责边界打开 .mymetadata 和 .project 文件能看出来这是一个标准的 MyEclipse 工程。它的目录设计非常教科书我直接给你拆开看SCADAHMI ├── src # Java 源码采集逻辑、业务处理、数据库访问 ├── WebRoot # Web 根目录 │ ├── *.jsp # 各类曲线 HMI 页面qlCurve、jzCurve、lcCurve... │ ├── images # 页面所需的静态资源 │ ├── META-INF # 应用元信息配置 │ └── WEB-INF # Web 核心配置和依赖库 ├── .settings # Eclipse/MyEclipse 工程环境配置 ├── .classpath # 工程构建路径定义 └── .project # 工程描述文件src 和 WebRoot 的分离意味着业务逻辑和表现层解耦如果要替换成 Spring Boot 或 Spring MVC 架构核心的 src 代码和 WebRoot 下的页面可以直接迁移代价最小。这里我想特别提一下 WEB-INF 目录你在它下面会找到 web.xml 和 lib 目录lib 里放的是 Proxool、PostgreSQL 驱动这类第三方依赖。很多同学部署翻车就是因为在 Eclipse 里配了 Build Path 却忘了把依赖 jar 同步到 WEB-INF/lib导致部署到 Tomcat 后类找不到。2.4 这套技术选型在今日是否仍适用直白地说JSP Applet 是 2010 年前后的主流组合放到今天前端框架普及的时间点Applet 已经很少被浏览器直接支持。但这份源码的价值恰恰不在「能不能直接开箱即用」而在于它把 SCADA 后台的完整骨架和数据流逻辑用最直白的方式写出来了。我的做法通常是保留 src 下的数据采集和数据库访问代码把 WebRoot 下的 JSP 页面替换成 Vue 或 React 页面接口层用 Servlet 或 Spring Boot 重写。这个改造路径在多个模拟项目 X 里都验证过改造后的系统页面响应速度提升明显但底层 SCADA 逻辑完全复用。所以我的结论是这套源码是学 SCADA 后台设计、做传统电力项目交付、或者迁移到新架构时的底层参考都适用。3. 源码包里的曲线页面每个 JSP 的查询逻辑和参数调优3.1 九大曲线页面的功能对应关系WebRoot 根目录下躺着九个以 Curve 命名的 JSP 文件我把它们和电力监控场景的对应关系整理成一张表方便你拿到源码后快速定位文件名全称含义典型监测对象核心参数qlCurve.jsp功率曲线有功/无功功率采集间隔、时间范围lcCurve.jsp潮流曲线线路负载率负载阈值、刷新频率xjCurve.jsp相角曲线电压相角差相角范围、越限值blzCurve.jsp变比曲线变压器变比档位状态、分接位置wjjCurve.jsp无功曲线无功功率补偿补偿容量、功率因数wtCurve.jsp温升曲线变压器温度温度阈值、冷却状态jzCurve.jsp接地曲线接地电流接地电阻、泄漏电流qmtCurve.jsp球磨机曲线球磨机电流/负荷负荷率、运行周期gjtCurve.jsp高压开关曲线开关分合闸状态分合闸次数、动作时间你看这些页面的命名规律ql、lc、xj 这类前缀基本都是拼音首字母是电力行业老代码的典型风格。拿到源码后不要急着改代码先把这九个页面和你需要监控的设备对应起来哪些直接改参数就能用哪些需要重写数据查询逻辑。3.2 一个曲线页面的数据查询流程拆解我以 qlCurve.jsp 为例子把这类页面的标准工作流程拆成四步你读其他八个页面时会发现套路完全一致。第一步是页面初始化时向后端请求历史数据通常是发送查询参数给后端 Servlet 或 Applet 入口% String startTime request.getParameter(startTime); String endTime request.getParameter(endTime); String pointId request.getParameter(pointId); // 默认查最近24小时 if (startTime null || startTime.isEmpty()) { startTime new SimpleDateFormat(yyyy-MM-dd HH:mm:ss).format(new Date(System.currentTimeMillis() - 86400000L)); } %查不到这两个参数就自动取 24 小时前的时间作为起点这对现场没配置查询条件时的兜底很有用。你在改造时保留这段逻辑即可。第二步是构建 SQL 查询语句。我翻到源码里的对应查询代码看到的是拼 SQL 的经典写法String sql SELECT record_time, value FROM realtime_data WHERE point_id ? AND record_time BETWEEN ? AND ? ORDER BY record_time ASC; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, pointId); ps.setTimestamp(2, Timestamp.valueOf(startTime)); ps.setTimestamp(3, Timestamp.valueOf(endTime)); ResultSet rs ps.executeQuery();用 PreparedStatement 而不是普通 Statement一是防止 SQL 注入二是在 PostgreSQL 下可以复用执行计划缩短查询时间。这里我给个参数层面的建议时间范围不要超过 7 天因为历史数据表如果没有分区全表扫描的趋势数据会把数据库连接拖死。第三步是解析 ResultSet 结果集并准备绘图数据// 只取采样间隔内的数据点避免曲线过于密集 int sampleInterval 5; // 单位秒 ListDouble values new ArrayList(); ListString times new ArrayList(); while (rs.next() values.size() 1000) { values.add(rs.getDouble(value)); times.add(rs.getString(record_time)); }对曲线点数做 1000 个上限限制防止大屏展示时一次性绘制过量数据导致浏览器卡死。如果你觉得曲线精度不够优先改采样间隔而非移除数量上限。第四步是把数据输出到页面响应流由前端的绘图组件完成渲染。原来 JSP 里这段逻辑用的是 Java 2D 相关技术改造时可以把输出格式改成 JSON交给前端图表库去画。3.3 曲线刷新机制的参数调整SCADA 系统的曲线页面不能只展示历史数据还要实时更新。源码里的 JSP 页面普遍用 setInterval 调度器定时刷新或 Applet 定时拉取数据。在实际部署时我一般把刷新间隔调整到 1030 秒太短了会给数据库制造大量重复查询太长了又失去监控的实时性。// 每 20 秒拉取一次最新数据 window.setInterval(function() { var xhr new XMLHttpRequest(); xhr.open(GET, realtime?pointId currentPointId lastTime lastDataTime, true); xhr.onreadystatechange function() { if (xhr.readyState 4 xhr.status 200) { var newData JSON.parse(xhr.responseText); appendCurveData(newData); lastDataTime newData[newData.length - 1].time; } }; xhr.send(); }, 20000);注意加 lastTime 这个参数后端只返回该时间点之后的增量数据可以显著降低网络传输量。我见过不少改造项目每次刷新都全量拉当天数据页面越跑越慢加了这个参数立刻好转。改造时如果遇到曲线长时间不刷新优先排查这个接口的响应时间和数据库连接是否被占满。3.4 二次开发时对 Curve 页面改动的最小方案如果只是想把这套系统用于某个具体的电力监控项目我的建议是核心查询逻辑保持不动只改页面展示和阈值参数。具体操作流程是打开 qlCurve.jsp 或对应的 Java 查询类找到 SQL 语句中的 point_id 参数替换成你现场的实际测点编码调整曲线页面的采样间隔常量从 5 秒改成 15 秒或 30 秒修改越限报警阈值包括功率上限、温度上限等把页面标题和测点名称改成实际设备名称这种最小改动方案对没有完整开发团队的运维项目非常划算本质上这套源码的价值就是帮你省掉从零搭建后台的工作量。4. 电力后台的数据库与连接池PostgreSQL 和 Proxool 的配合方式4.1 为什么电力监控后台认 PostgreSQL很多做 Web 开发的同学默认首选 MySQL但电力监控后台里 PostgreSQL 的出场率相当高。核心原因有三条一是 PostgreSQL 对复杂 SQL 和窗口函数的支持更好电力趋势分析经常要按时间窗口聚合计算比如算小时均值、日累计电量二是它的事务处理和信息约束做得很扎实这一点在实时数据频繁写入、历史归档并发查询的场景下很重要三是它对表分区、索引类型的支持很稳遇到千万级的历史测点数据不太容易被拖垮。这份源码里教科书式的做法是实时数据表和历史归档表分开设计实时表只保留当天的数据历史表按时间戳写入并建立复合索引。我打开源码里相关数据库操作代码时看到的正是这种双表模式。你接手后第一件事应该是检查这两个表是否已按需创建而不是先去改代码。4.2 Proxool 连接池的核心配置项Proxool 是一个老牌 Java 数据库连接池中间件它比 DBCP 和 C3P0 出现得更早一些。虽然现在新项目里 HikariCP 见得更多但 Proxool 在旧系统里存量巨大。这套源码里连接池的配置通常放在 WEB-INF 下的配置文件或者 src 下的 Java 类里我按最常见的配置方式给你列一下核心参数proxool aliaspower_db/alias driver-urljdbc:postgresql://192.168.1.100:5432/power_scada/driver-url driver-classorg.postgresql.Driver/driver-class driver-properties property nameuser valuescada/ property namepassword valuescada123/ /driver-properties maximum-connection-count30/maximum-connection-count minimum-connection-count5/minimum-connection-count prototype-count5/prototype-count simultaneous-build-throttle10/simultaneous-build-throttle house-keeping-sleep-time30000/house-keeping-sleep-time /proxool给你逐个说明这些参数在电力监控场景下的实际意义maximum-connection-count 是最大连接数。30 是一个折中值如果现场有上百个曲线页面同时刷新这个值可能要上调到 5080。调大之前先看 PostgreSQL 的 max_connections 设置数据库端不允许的话连接池再怎么调都没用。minimum-connection-count 是最小空闲连接数。设成 5 是为了避免监控大屏半夜没流量时连接被全部回收第二天早高峰重新建立连接时出现首个页面白屏等待。这一点我在带 A 同学做模拟项目 X 时验证过最小值设得太低早上 8 点准时出现一批连接超时报警。house-keeping-sleep-time 是连接池内部清理线程的检查周期单位毫秒。30 秒是合理的默认值太短会造成没必要地频繁扫描太长会让失效连接滞留过久。prototype-count 表示连接池每次批量新建连接时一次建立几个这决定了并发压力陡增时的响应速度。4.3 链接池参数和现场规模的匹配策略连接池不是配置完就不管的它要跟着现场的数据规模走。我给你一个实战经验总结的参数匹配表现场规模实时测点数推荐最大连接数推荐最小连接数刷新间隔小型开闭所200 以内15330 秒中型变电站200200030515 秒大型集控站2000 以上501010 秒这个表不是拍脑袋定的核心依据是每个曲线页面每次刷新需要占用一个数据库连接完成查询如果同时在线页面数为 20刷新间隔为 10 秒那么每秒平均需要的连接数就是 220除以10。如果最大连接数小于这个值队列等待就出现了。我在实际现场遇到的连接池参数翻车案例最常见的是「连接池最大连接数改了但没改 PostgreSQL 的 max_connections」。Proxool 可以成功创建连接池对象但连接在数据库端直接拒绝报错信息通常是 FATAL: sorry, too many clients already。所以我把「改池子先改库」当成一条规矩定下来。4.4 排查数据库连接耗尽的标准流程如果系统运行一段时间后出现页面数据加载不出来、后台日志报 Cannot get connection, pool exhausted别急着重启服务按下面的顺序排查先看连接池当前的使用情况。Proxool 提供了内建的监控 Servlet你可以在 web.xml 里找到 Proxool 的统计页面配置或者直接访问/proxool路径查看当前活动连接数。如果活动连接数长期接近最大值说明连接没有被及时归还。再看代码里有没有连接泄漏。最典型的劣根性写法是Connection conn null; try { conn ConnectionFactory.getConnection(); // 执行查询 } catch (Exception e) { e.printStackTrace(); } finally { // 没有关闭连接直接结束 }这段代码的问题在于 finally 块里没有任何操作连接永远不会归还给连接池。正确的写法是把关闭动作放进 finallyConnection conn null; PreparedStatement ps null; ResultSet rs null; try { conn ConnectionFactory.getConnection(); ps conn.prepareStatement(SELECT ...); rs ps.executeQuery(); // 处理结果 } catch (Exception e) { log.error(数据查询失败, e); } finally { if (rs ! null) { try { rs.close(); } catch (SQLException ignore) {} } if (ps ! null) { try { ps.close(); } catch (SQLException ignore) {} } if (conn ! null) { try { conn.close(); } catch (SQLException ignore) {} } }ResultSet、PreparedStatement、Connection 必须依次关闭否则连接池里的实际连接不会真正归还。一套 SCADA 后台几十个页面只要有一两处这种漏写的点运行三天就会出现连接耗尽。我的习惯是每次迭代代码时就全局搜索 conn 、ps 、rs 的关闭情况不把这个问题留到现场。5. 部署与避坑指南MyEclipse 工程转 Tomcat 的实测记录5.1 从压缩包到本地可运行工程的导入步骤拿到 SCADAHMI.rar 后先解压你会看到完整的 MyEclipse 工程结构。我按当前主流开发环境 Eclipse 的导入流程给你走一遍MyEclipse 操作基本一致。第一步是在 Eclipse 里导入工程# 解压源码包到工作目录 unzip SCADAHMI.rar -d /home/dev/workspace/ # 打开 Eclipse选择 File - Import - General - Existing Projects into Workspace # 选择 SCADAHMI 目录勾选 Copy projects into workspace导入后第一件事不是急着启动而是检查 .classpath 文件里引用的 jar 包是否存在。这个工程用的是 MyEclipse 自带的用户库配置如果路径里有本地不存在的包名Eclipse 会直接显示工程报错。第二步是校准 JDK 编译级别# 打开工程右键 - Properties - Java Compiler # 确认 Compiler compliance level 和工程实际用到的 JDK 版本一致 # 建议使用 JDK 1.7 或 1.8太高版本可能出现 Applet 相关 API 被移除的兼容性问题我就被这个坑过一次某次直接用 JDK 11 打开老工程编译报错一堆「找不到 Applet 相关类」然后一顿操作把编译级别改回 1.8 才顺利通过。这是老 Java Web 工程的共性毛病不是代码本身有问题。第三步是修改 PostgreSQL 数据库连接配置。源码里的连接串通常是 127.0.0.1 加 5432 端口你需要改成实际数据库地址。这个改了之后不用重启 Eclipse但要在 Proxool 配置里确认连接可以建立。5.2 依赖包缺失导致的各种编译报错这个工程是完整带 WEB-INF/lib 目录的正常情况下依赖不太会缺。但如果你的 Eclipse 环境缺少 MyEclipse 的部分插件出现异常不需要慌张。我整理了一份老工程编译报错排查表报错现象可能原因处理方式The import org.hibernate cannot be resolvedlib 里缺少 hibernate 相关 jar检查 WEB-INF/lib 中是否有 hibernate-core、hibernate-annotationsThe import org.eclipse cannot be resolvedlib 里缺少 Eclipse 相关插件包.settings 里的 org.eclipse.jdt 配置只保留编译器把源码编译相关 jar 加入 Build PathProxoolException: Attempt to refer to a unregistered poolProxool 配置加载顺序问题检查 web.xml 里 Proxool 初始化 Servlet 和应用的 context-param 顺序java.lang.ClassNotFoundException: org.postgresql.DriverPostgreSQL 驱动 jar 缺失从 WEB-INF/lib 或本地仓库导入 postgresql-jdbc 对应版本驱动第一条和第二条我特别提醒一下这类 .settings 目录里的 org.eclipse.jdt*.prefs 是编辑器偏好配置不代表所有 org.eclipse 包都必须在项目里。你把 .classpath 文件里实际引用的 jar 对一遍基本就不会有意外。5.3 本地部署到 Tomcat 进坑清单部署老工程到 Tomcat常见的异常可以整理成几个具体案例。先说案例一部署后页面能打开但曲线数据空白后台日志报数据库连接失败。排查过程先直接命令行测数据库连通性# 确认 PostgreSQL 服务正常并且端口可达 telnet 127.0.0.1 5432 # 用 psql 验证账号密码和数据库名是否正确 psql -h 127.0.0.1 -U scada -d power_scada -c select 1;如果上面都没问题再看 Proxool 的 alias 配置和代码里获取连接池的 alias 是否完全一致。我在某项目里就是配置文件里写的是 proxool.power_scada代码里却写了 new ProxoolDataSource(power_db)死活匹配不上后台日志还不直接报错曲线页面就一直转圈。案例二Tomcat 部署后启动即报内存溢出。老工程如果默认给 Tomcat 分配的内存不够曲线页面一开就堆溢出。正确做法是在 Tomcat 启动参数里加JAVA_OPTS-Xms512m -Xmx1024m -XX:MaxPermSize256m这里 -XX:MaxPermSize 在 JDK 8 以上已失效如果你用的是 JDK 8改成 -XX:MaxMetaspaceSize256m 即可。我见过有人照抄老配置在 JDK 8 上反复调原参数其实根本没有生效白费了半天功夫。案例三设备曲线一部分显示一部分不显示。这大概率不是代码问题而是对应的测点根本没有采集到数据。SCADA 系统里测点先要有库表记录、再要有采集线程写入中途任何一环断了页面就只能拿到空数据。排查时先查数据库里对应测点的最新时间戳SELECT point_id, max(record_time) as latest_time FROM realtime_data WHERE point_id PT001 GROUP BY point_id;如果这个查询结果为空或时间是几个小时之前问题不在 HMI 页面而在数据采集侧。案例四刷新曲线时浏览器报错但后台日志无任何异常。这类问题大概率是页面缓存导致的老 JSP 页面的 JavaScript 和样式经常被浏览器强缓存。处理方式是 JSP 页面顶部加禁用缓存的代码% response.setHeader(Cache-Control, no-cache, no-store, must-revalidate); response.setHeader(Pragma, no-cache); response.setDateHeader(Expires, 0); %这行代码我建议所有曲线页面统一加上避免现场运维人员浏览器打开的是旧页面排查半天怀疑后端数据没更新。5.4 运行环境选型老工程和新 Tomcat 的兼容性这个工程本质上是 Servlet JSP 项目目前主流 Tomcat 8.5 和 Tomcat 9 都能跑。但有一点要注意工程里如果依赖了旧版 Servlet API比如 javax.servletTomcat 9 使用的 Jakarta Servlet 规范在部分 API 包名上有变化。实际经验是 Tomcat 8.5 JDK 8 是最稳妥的组合不要追新版本。另外一个容易踩的坑是代码中如果引用了 org.apache.jasper 这类和 JSP 编译器相关的类换 Tomcat 版本时容易发生类版本冲突。解决办法是让项目基于标准的 JSP 和 Servlet API 编译不要依赖 Tomcat 内部实现类。我在这个源码包里翻了一遍没有发现这方面的硬依赖所以 Tomcat 8.5 部署基本无障碍。6. 后台运行的定位技巧用日志和监控页面搞定故障判断这种老系统的定位技巧核心就一个字看日志。但看日志不是盲目翻日志文件要分先后有方法地看。第一层是看 Proxool 连接池的状态。部署正常后访问 Proxool 自带的监控 Servlet路径通常是http://localhost:8080/SCADAHMI/proxool/power_db这个页面会直接展示当前池子里有多少活动连接、有多少可用连接、有多少连接在等待。我判断系统健康状况时第一眼就看这个页面的活跃连接数。如果活跃数长期超过最大连接数的一半说明某些线程在长时间占用连接后续要有意识地排查慢查询。第二层是看 PostgreSQL 的慢查询日志。电力后台的数据量上去后慢查询有一个典型的反例时间段查询条件没有走索引。你就直接看数据库日志里有没有查询时间过长的语句如果有EXPLAIN ANALYZE SELECT record_time, value FROM realtime_data WHERE point_id PT001 AND record_time BETWEEN 2024-01-01 00:00:00 AND 2024-01-01 01:00:00;如果执行计划里出现 Seq Scan而表里已经有时间索引就是复合索引没建对的经典情况。这种问题的解法是CREATE INDEX idx_point_time ON realtime_data (point_id, record_time DESC);这个复合索引的结构是「按测点过滤、按时间倒序读取」正好覆盖曲线页面几乎全部查询模式。建完索引后同样一条查询的执行计划会变成 Index Scan耗时会从几百毫秒降到几十毫秒。第三层是看 JSP 页面自身的响应时间。在曲线页面里加一段计时代码把每次从发起请求到数据渲染完成的耗时输出到控制台或日志里用真实数据判断瓶颈在哪一层。我的习惯是long start System.currentTimeMillis(); // 执行原查询逻辑 long cost System.currentTimeMillis() - start; System.out.println([ new Date() ] 页面数据查询耗时: cost ms);但这个技巧没有必要保留在生产代码里它是用来定位问题的临时手段。实践多了之后你看到耗时是 500ms 还是 100ms大概就能知道是哪一层出问题500ms 基本是数据库查询慢或连接池等待100ms 以内基本是网络和页面渲染问题。还有一个定位技巧是关于 Applet 相关程序调试的。JSP console 的输出不一定能直接看到Power 监控场景下来回翻日志文件太费时间。我再给你一个靠谱的做法写一个简单的 Servlet 专门输出系统关键参数包括连接池状态、关键线程状态、数据库连接是否正常、当前数据最新时间戳。用浏览器访问时直接看到 JSON 文本// 一个轻量级的状态检查接口 WebServlet(/status) public class StatusServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType(application/json); resp.setCharacterEncoding(UTF-8); String json { \poolActivityCount\: getPoolActiveCount() , \dbConnectable\: testDbConnection() , \latestDataTime\: \ getLatestDataTime() \ }; resp.getWriter().print(json); } }有了这个接口你在现场无论是有没有 Eclipse 环境只要能开浏览器就能在 10 秒内判断这套后台是不是活的、数据有没有在更新、连接池有没有卡死。从那以后我每次布置新环境都强制先把这个 状态检查接口部署上去再谈其他功能调试这个习惯帮我省掉了大量来回跑现场的麻烦。这套 SCADAHMI 源码包里的原始设计虽然没有这样的接口但它给了你完整的代码结构照着我这个方法 10 分钟就能给它补上一个。希望帮到你。本文还有配套的精品资源点击获取