摘要
针对中小城市基层市政部门在公共卫生间管理中面临的预算有限、人工管理效率低、现有智慧公厕方案落地成本过高的问题，本课题设计并实现了一套低成本的公共卫生间管理系统。系统采用前后端分离的架构，基于 PyQt5 与 FastAPI 完成开发，实现了用户权限管理、站点管理、实时状态监控、环境监测、自动派单、统计报表等核心功能，其中环境异常自动派单、WebSocket 实时推送、任务去重等机制，有效解决了传统管理中的痛点。经过测试验证，系统的所有功能均满足设计需求，能够有效提升基层部门的管理效率，降低管理成本。该系统为中小城市的公共卫生间信息化管理提供了可落地的低成本解决方案，具备良好的应用价值。
****关键词：****公共卫生间管理；自动派单；前后端分离；实时通信
Unsupervised learning based indoor environment monitoring system design and implementation
Abstract
Aiming at the problems faced by grass-roots municipal departments in small and medium-sized cities in public toilet management, such as limited budget, low efficiency of manual management, and high deployment cost of existing smart toilet solutions, this research designs and implements a low-cost public toilet management system. The system adopts a front-end and back-end separation architecture, developed based on PyQt5 and FastAPI, and implements core functions including user permission management, site management, real-time status monitoring, environment monitoring, automatic task assignment, and statistical reports. Among them, mechanisms such as automatic task assignment for environmental anomalies, WebSocket real-time push, and task deduplication effectively solve the pain points in traditional management. After testing and verification, all functions of the system meet the design requirements, and can effectively improve the management efficiency of grass-roots departments and reduce management costs. The system provides a feasible low-cost solution for the information management of public toilets in small and medium-sized cities, and has good application value.
****Keywords:****Public Toilet Management; Automatic Task Assignment; Front-end and Back-end Separation; Real-time Communication
目录
++摘要++
++Abstract++
++[第一章 绪论](#第一章 绪论)++
++[1.1 研究背景与意义](#1.1 研究背景与意义)++
++[1.2 国内外研究现状](#1.2 国内外研究现状)++
++[1.2.1 国外研究现状](#1.2.1 国外研究现状)++
++[1.2.2 国内研究现状](#1.2.2 国内研究现状)++
++[1.3 本文研究内容与论文结构安排](#1.3 本文研究内容与论文结构安排)++
++[第二章 相关技术与理论基础](#第二章 相关技术与理论基础)++
++[2.1 前端开发相关技术](#2.1 前端开发相关技术)++
++[2.1.1 PyQt5 桌面界面框架](#2.1.1 PyQt5 桌面界面框架)++
++[2.1.2 PyQtChart 数据可视化组件](#2.1.2 PyQtChart 数据可视化组件)++
++[2.2 后端服务相关技术](#2.2 后端服务相关技术)++
++[2.2.1 FastAPI 异步服务框架](#2.2.1 FastAPI 异步服务框架)++
++[2.2.2 SQLAlchemy ORM 映射框架](#2.2.2 SQLAlchemy ORM 映射框架)++
++[2.3 数据与通信支撑技术](#2.3 数据与通信支撑技术)++
++[2.3.1 JWT 身份认证机制](#2.3.1 JWT 身份认证机制)++
++[2.3.2 WebSocket 实时通信协议](#2.3.2 WebSocket 实时通信协议)++
++[第三章 系统需求与可行性分析](#第三章 系统需求与可行性分析)++
++[3.1 可行性分析](#3.1 可行性分析)++
++[3.1.1 技术可行性](#3.1.1 技术可行性)++
++[3.1.2 经济可行性](#3.1.2 经济可行性)++
++[3.1.3 操作可行性](#3.1.3 操作可行性)++
++[3.2 系统需求概述](#3.2 系统需求概述)++
++[3.3 功能性需求分析](#3.3 功能性需求分析)++
++[3.3.1 用户权限管理需求](#3.3.1 用户权限管理需求)++
++[3.3.2 公厕站点管理需求](#3.3.2 公厕站点管理需求)++
++[3.3.3 实时状态监控需求](#3.3.3 实时状态监控需求)++
++[3.3.4 维护任务管理需求](#3.3.4 维护任务管理需求)++
++[3.3.5 数据统计分析需求](#3.3.5 数据统计分析需求)++
++[3.4 非功能性需求分析](#3.4 非功能性需求分析)++
++[第四章 系统总体设计](#第四章 系统总体设计)++
++[4.1 系统架构设计](#4.1 系统架构设计)++
++[4.1.1 总体分层架构设计](#4.1.1 总体分层架构设计)++
++[4.1.2 前后端交互流程设计](#4.1.2 前后端交互流程设计)++
++[4.2 功能模块设计](#4.2 功能模块设计)++
++[4.2.1 核心业务模块划分](#4.2.1 核心业务模块划分)++
++[4.2.2 角色权限流程设计](#4.2.2 角色权限流程设计)++
++[4.3 数据库设计](#4.3 数据库设计)++
++[4.3.1 数据库E-R模型设计](#4.3.1 数据库E-R模型设计)++
++[4.3.2 核心业务表结构设计](#4.3.2 核心业务表结构设计)++
++[4.4 核心业务逻辑设计](#4.4 核心业务逻辑设计)++
++[4.4.1 环境异常自动派单逻辑](#4.4.1 环境异常自动派单逻辑)++
++[4.4.2 实时状态推送逻辑](#4.4.2 实时状态推送逻辑)++
++[第五章 系统详细实现](#第五章 系统详细实现)++
++[5.1 用户与权限管理功能实现](#5.1 用户与权限管理功能实现)++
++[5.2 卫生间与设施管理功能实现](#5.2 卫生间与设施管理功能实现)++
++[5.3 厕位使用状态实时监控功能实现](#5.3 厕位使用状态实时监控功能实现)++
++[5.4 环境状态监测功能实现](#5.4 环境状态监测功能实现)++
++[5.5 维护与保洁任务管理功能实现](#5.5 维护与保洁任务管理功能实现)++
++[5.6 统计与报表功能实现](#5.6 统计与报表功能实现)++
++[5.7 系统配置与日志审计功能实现](#5.7 系统配置与日志审计功能实现)++
++[第六章 系统测试与运行验证](#第六章 系统测试与运行验证)++
++[6.1 测试环境说明](#6.1 测试环境说明)++
++[6.2 测试方法](#6.2 测试方法)++
++[6.3 核心功能测试](#6.3 核心功能测试)++
++[6.3.1 用户权限管理功能测试](#6.3.1 用户权限管理功能测试)++
++[6.3.2 环境异常自动派单功能测试](#6.3.2 环境异常自动派单功能测试)++
++[6.3.3 实时状态监控功能测试](#6.3.3 实时状态监控功能测试)++
++[6.4 性能测试](#6.4 性能测试)++
++[第七章 结论](#第七章 结论)++
++参考文献++
++致谢++
- 绪论
- 研究背景与意义
公共卫生间是城市公共服务体系的核心组成部分，其服务质量与管理水平，直接影响居民日常出行的体验，也直观体现城市的文明建设程度。随着国内城镇化进程的持续推进，城市建成区的范围不断扩张，公共卫生间的站点数量持续增加，公众对公共服务的质量要求也同步提升，传统的公共卫生间管理模式，已经无法适配当前的管理需求。
传统的公共卫生间管理，大多依赖人工巡检与纸质台账记录。巡检人员按照固定的周期，逐个巡查负责区域内的公厕站点，记录站点的状态与发现的问题，保洁与维护工作也按照固定的排班执行。这种模式在站点数量较少的阶段，可以满足基础的管理需求，但随着站点数量的增加，其短板逐渐凸显。首先是信息传递的滞后性，人工巡检的间隔时间较长，环境异味超标、设备故障这类异常问题，无法被第一时间发现，往往要等到问题出现数小时之后，才会在巡检过程中被记录，导致维护响应的时间被拉长，直接影响使用人员的体验。其次是数据的分散性，人工记录的台账信息分散在各个巡检人员的记录中，无法实现统一的沉淀与汇总，管理部门无法通过历史数据，分析各个站点的使用频率、维护需求等信息，只能依靠经验安排保洁与维护的资源，容易出现资源分配不合理的问题，部分站点维护过度，部分站点维护不足。
近年来，国内不少城市开始推进公共卫生间的智慧化改造，试图通过技术手段解决传统管理的痛点。根据行业调研数据，当前国内仅有约 15% 的公共卫生间完成了智慧化改造，剩余的大部分站点，尤其是中小城市的基层站点，仍然沿用传统的管理模式。现有的智慧公厕改造方案，大多依赖物联网传感器硬件，通过在站点内部署厕位传感器、环境传感器，采集实时的状态数据，实现远程监控。但这类方案的落地门槛较高，一方面是硬件采购与部署的成本较高，单个站点的传感器改造成本就需要数千元，对于站点数量较多的区域来说，整体改造成本过高；另一方面是硬件的后续维护成本较高，传感器设备需要定期的检修与更换，对运维人员的技术能力也有一定的要求。对于很多中小城市的基层市政部门来说，这类方案的成本压力过大，难以落地。
除此之外，部分已经落地的智慧公厕系统，还存在功能与实际需求脱节的问题。部分系统为了追求功能的全面性，加入了大量复杂的功能，操作流程繁琐，普通的保洁与基层管理人员，需要经过长时间的培训才能上手，反而降低了管理的效率，甚至出现部分系统部署之后，因为操作复杂被弃用的情况。
针对上述问题，本次研究开发了一套基于 Qt 的公共卫生间管理系统。该系统采用软件模拟的方式，不需要额外的硬件传感器，就可以实现公共卫生间的全流程信息化管理，大幅降低了智慧化改造的成本。系统的功能完全贴合基层管理的实际需求，覆盖了站点信息管理、实时状态监控、维护任务管理、数据统计分析全流程，操作逻辑简单，基层人员可以快速上手。该系统能够有效解决传统管理模式的痛点，也为中小城市的公共卫生间智慧化改造，提供了一个低成本、可快速落地的解决方案。
- 国内外研究现状
- 国外研究现状
国外的公共卫生间管理研究起步较早，相关的技术与应用已经形成了较为成熟的体系。日本早在 20 世纪 90 年代就已经推进公厕的标准化管理，随后逐步将信息化技术引入到公厕管理中，东京、大阪等大城市在 2010 年后陆续推出智慧公厕项目，通过部署温湿度、氨气浓度等传感器，实现公厕环境的实时监测，同时配套开发了管理平台，支持管理人员远程查看各个站点的运行状态。新加坡在 2022 年全面落地了 "智慧厕所 2.0" 计划，核心公厕配备了 AI 清洁机器人，单台机器人可以替代 3 名清洁人员的工作，同时搭配空气质量实时监测系统，当 PM2.5 与氨气浓度超标时，系统会自动启动新风系统，故障的自动修复率可以达到 90%。欧美国家则将公共卫生间纳入智慧城市的市政设施管理体系，美国纽约、旧金山等城市的市政部门，开发了统一的设施管理系统，将公厕、路灯、垃圾桶等市政设施的管理整合到同一个平台中，实现了设施的统一调度与维护。学术研究层面，国外学者针对公共卫生间的管理开展了大量的前沿研究，部分研究聚焦于物联网传感器的应用，通过部署 MQ 系列气体传感器，实现异味的实时监测，当检测到超标情况时，自动启动香氛设备，能够在 3 分钟内将异味降低 68%；还有部分研究聚焦于主动维护管理，通过深度学习模型，基于传感器采集的时序数据，预测设备的运行状态，提前发现潜在的故障，实现预测性的维护；还有研究将机器人技术引入到公厕的清洁中，结合循环神经网络，预测清洁的需求，优化清洁人员的调度，提升清洁的效率。但是，国外的这些研究与应用，大多是针对发达国家的大城市设计的，这类地区的市政部门预算充足，能够承担高昂的部署与维护成本。从实际的成本来看，美国旧金山新建一座传统公厕的预算就高达 170 万美元，即便是相对低成本的移动智慧公厕，单个站点每年的运营成本也达到 9 万美元，新加坡的智慧公厕项目，单个站点的 AI 清洁机器人与传感器设备的投入就超过 10 万元人民币。除此之外，国外的系统大多采用云服务的架构，需要持续支付云服务的费用与专业的运维成本，这对于预算有限的中小城市基层市政部门来说，完全超出了可承受的范围。除此之外，国外的管理系统的业务逻辑，是基于当地的市政管理流程设计的，与国内基层市政部门的管理流程存在明显的差异，国内基层部门需要区分管理员与普通操作员的权限，实现任务的指派与处理的闭环，同时需要适配国内的低成本、轻量化的管理需求，而国外的系统大多没有针对这类需求做适配，导致这类成熟的系统无法直接在国内的基层部门落地，无法满足中小城市的公共卫生间管理需求。
- 国内研究现状
国内的公共卫生间管理研究起步相对较晚，随着 2015 年全国推进的 "厕所革命"，国内的公厕管理开始逐步从传统的人工管理，向信息化、智能化的方向转型，尤其是近年来智慧城市建设的推进，国内多个大城市都推出了智慧公厕的试点项目，推动了行业的快速发展。杭州、上海、广州等一线城市，率先完成了主城区公厕的智慧化改造，杭州武林路的防疫站公厕，作为省内首座智慧公厕，通过部署物联网传感器，实现了环境的实时监测与设备的自动控制，解决了传统公厕的异味与能耗问题，实现了精细化的管理。福建三明、河北邯郸等城市，也开展了市政公厕的批量智慧化改造，三明市将 30 座市政公厕接入统一的云管理平台，实现了环境监测、厕位占用监测、客流量统计等功能，管理人员可以通过平台远程查看所有站点的状态，不需要逐个站点巡查，管理效率提升了 40%，运营成本降低了 30%。学术研究层面，国内的学者针对智慧公厕的技术与应用开展了大量的研究，部分研究提出了基于物联网的智慧公厕架构，通过传感器采集数据，上传到云平台进行处理，实现公厕的远程监控；还有部分研究针对公厕的环境监测，研究了除臭的技术，通过大数据分析，优化除臭设备的运行，提升公厕的环境质量；还有部分研究针对中小城市的需求，探索低成本的改造方案，通过模块化的设计，降低改造的成本，适配基层的管理需求。但是，国内现有的研究与应用，大部分都集中在大城市或者重点的试点区域，这些项目的预算充足，能够承担硬件改造与云服务的成本，而对于大量的中小城市的基层市政部门来说，这类系统的成本过高，无法落地。根据行业的调研数据，现有的智慧公厕改造方案，单个站点的硬件投入通常在 3 到 5 万元人民币，对于管理几十上百座公厕的基层部门来说，整体的改造费用动辄上百万，这对于预算有限的基层部门来说，是难以承担的。除此之外，现有的很多系统，在功能上还存在明显的不足，很多系统的状态更新采用传统的轮询方式，前端每隔一段时间就主动请求一次后端，拉取最新的数据，这种方式不仅实时性较差，数据更新存在延迟，还会给服务器带来较大的压力，无法满足实时监控的需求。还有，很多系统没有实现环境异常的自动派单，当环境参数超过阈值的时候，系统只是发出报警提示，需要管理人员手动创建维护任务，手动指派维护人员，效率很低，而且容易出现遗漏，导致问题不能及时处理。另外，很多系统的权限管理较为简单，没有区分管理员与普通操作员的权限，普通操作员也可以修改站点的基础数据，容易导致数据的混乱，不符合基层部门的管理规范。还有，很多现有的系统，都是针对商圈、景区或者交通枢纽的公厕设计的，这类场景的公厕数量少，人流量大，管理流程相对简单，而市政部门管理的公厕，数量多，分布广，管理流程也不一样，现有的系统无法适配这类场景的需求。针对这些问题，本项目开发了低成本的公共卫生间管理系统，采用软件模拟的方式，先实现完整的业务流程，同时预留硬件传感器的接入接口，后续有条件的时候可以逐步接入硬件，大幅降低了初期的部署成本，同时系统实现了环境异常的自动派单、WebSocket 实时状态推送、RBAC 双角色权限控制等功能，专门适配中小城市基层市政部门的管理需求，解决了现有系统的不足。
- 本文研究内容与论文结构安排
本次研究围绕公共卫生间的低成本信息化管理需求，完成了公共卫生间管理系统的设计与实现。研究工作首先开展需求调研与梳理，明确基层管理部门的实际业务需求，同时从技术、经济、操作三个维度，开展项目的可行性分析，验证项目的可落地性。在此基础上，研究完成系统的总体设计，包括前后端分离的架构设计、业务功能模块的划分、数据库的设计，以及环境异常自动派单、实时状态推送等核心业务逻辑的设计。
完成设计工作后，研究开展系统的详细开发工作，按照业务需求，逐个实现用户权限管理、站点信息管理、实时状态监控、环境监测、维护任务管理、统计报表、系统配置与日志审计等功能模块，完成前后端的代码开发与联调。最后，研究开展系统的测试工作，通过黑盒测试验证各个功能的可用性，通过性能测试验证系统的运行性能，保证系统能够满足实际的使用需求。
本文的论文结构按照项目开发的全流程组织，各章节的安排如下：第一章为绪论，主要介绍课题的研究背景与意义，梳理国内外的研究现状，说明本次研究的核心内容与论文的整体结构。第二章为相关技术与理论基础，主要介绍系统开发用到的核心技术，包括前端的界面与可视化技术、后端的服务与 ORM 框架，以及数据通信与身份认证的支撑技术。第三章为系统需求与可行性分析，主要开展项目的可行性验证，同时梳理系统的功能性需求与非功能性需求，明确系统的开发目标。第四章为系统总体设计，主要介绍系统的总体架构设计、功能模块设计、数据库设计，以及核心业务逻辑的设计，明确系统的开发规划。第五章为系统详细实现，主要介绍系统的开发环境与项目结构，以及各个业务功能模块的具体实现过程。第六章为系统测试与运行验证，主要介绍系统的测试环境、测试方法，以及核心功能的测试用例与性能测试的结果，验证系统的可用性。第七章为总结与展望，主要总结本次研究的工作成果，同时说明系统后续可以优化的方向。
- 相关技术与理论基础
系统的开发效率、运行性能与后续的可维护性，很大程度上取决于技术栈的选型。本次研究结合公共卫生间管理系统的业务需求，选择了 Python 生态下的成熟技术，搭配对应的通信与认证支撑技术，既保证了开发的效率，也保证了系统能够满足基层管理的使用需求。
- 前端开发相关技术
前端部分负责系统的界面展示与用户交互，需要提供简洁易用的操作界面，同时支持数据的可视化展示，本次研究选择了 PyQt5 相关的技术来完成前端的开发。
- PyQt5 桌面界面框架
PyQt5 是 Qt 框架的 Python 语言绑定版本，该框架能够用来开发跨平台的桌面应用程序，开发的程序可以在 Windows、Linux 等主流的桌面系统上运行，不需要针对不同的系统做额外的适配。桌面管理系统是本项目的定位，PyQt5 的技术特性刚好匹配项目的需求。该框架提供了丰富的原生控件，包括按钮、输入框、表格、下拉框等，开发人员可以直接使用这些控件搭建界面，不需要从零开始实现基础的交互逻辑，能够大幅提升开发的效率。同时，该框架支持模块化的界面开发，开发人员可以把不同的功能拆分成独立的页面，每个页面独立处理自己的交互逻辑，降低代码的耦合度，方便后续的维护。本项目使用 PyQt5 搭建了系统的桌面客户端，按照功能把界面拆分成了状态展示、站点管理、任务管理等独立的页面，同时通过框架的信号槽机制，处理界面的交互事件，比如按钮的点击、表格的筛选等，保证界面操作的流畅性。
- PyQtChart 数据可视化组件
公共卫生间的管理过程中，需要展示大量的运行数据，单纯的表格展示不够直观，管理人员无法快速的从表格数据中发现规律，因此系统需要数据可视化的能力，把数据转换成直观的图表。PyQtChart 是 PyQt5 官方提供的数据可视化扩展组件，该组件可以和 PyQt5 的界面无缝集成，不需要引入额外的第三方依赖。它支持饼图、柱状图、折线图、散点图等常用的图表类型，能够满足不同场景的数据展示需求。本项目使用 PyQtChart 实现了多维度的数据可视化，包括厕位占用比例的饼图、站点占用率对比的柱状图、环境参数变化的趋势折线图等，把原本抽象的运行数据，转换成直观的图表，让管理人员可以快速的掌握各个站点的运行状态，提升管理的效率。
- 后端服务相关技术
后端部分负责系统的业务逻辑处理、数据的存储与接口的提供，需要支撑前端的请求，同时处理实时的业务逻辑，本次研究选择了 FastAPI 与 SQLAlchemy 作为后端的核心技术。
- FastAPI 异步服务框架
FastAPI 是一个现代的 Python 后端服务框架，该框架基于 Python 的类型提示特性，能够快速的开发 API 接口，同时自带异步处理的能力，拥有较高的运行性能。本项目需要同时处理两类接口，一类是普通的业务请求接口，另一类是实时的推送接口，FastAPI 原生支持 WebSocket 协议，不需要引入额外的扩展，就可以同时实现 REST 接口和 WebSocket 接口，刚好匹配项目的需求。除此之外，FastAPI 自带自动生成的接口文档，开发过程中，开发人员可以直接通过文档页面测试接口，减少了接口联调的时间，提升了开发的效率。本项目使用 FastAPI 搭建了系统的后端服务，实现了用户认证、站点管理、状态查询等所有的业务接口，同时实现了 WebSocket 的实时推送接口，所有的接口都添加了统一的权限校验，保证接口的安全性。
- SQLAlchemy ORM 映射框架
传统的数据库操作，需要开发人员编写原生的 SQL 语句，这种方式不仅开发效率低，还容易出现语法错误，同时代码的可读性差，后续的维护成本较高。SQLAlchemy 是 Python 生态下的成熟 ORM 框架，ORM 也就是对象关系映射，该框架可以把数据库的表映射成 Python 的类，开发人员可以通过操作 Python 对象的方式，来完成数据库的增删改查操作，不需要编写原生的 SQL 语句。这种方式不仅简化了数据库的操作，也提升了代码的可读性，方便后续的维护。除此之外，该框架支持多种数据库，包括 SQLite、MySQL 等，系统后续如果需要扩展，可以无缝切换数据库，不需要修改大量的代码。本项目使用 SQLAlchemy 定义了所有的业务数据模型，包括用户、站点、任务、环境日志等，通过 ORM 框架完成数据库的操作，简化了数据处理的流程，也提升了代码的可维护性。
- 数据与通信支撑技术
为了保证系统的身份安全与数据的实时性，项目还引入了对应的支撑技术，完成身份认证与实时通信的功能。
- JWT 身份认证机制
系统的接口需要做身份校验，保证只有登录成功的用户才能访问业务接口，同时需要根据用户的角色，控制用户的功能访问权限，避免越权操作。JWT 是一种轻量级的身份认证机制，该机制可以把用户的身份与角色信息，加密生成一个字符串 Token。客户端请求接口的时候，把 Token 放在请求头里发送给后端，后端解析 Token，就可以获取到用户的身份信息，不需要在后端存储会话数据，减轻了服务器的压力。本项目使用 JWT 实现了系统的身份认证功能，用户登录成功之后，后端生成对应的 JWT Token 返回给前端，前端后续的所有请求，都会自动在请求头里带上这个 Token。后端通过统一的依赖注入逻辑，解析 Token，校验用户的身份与权限，保证接口的安全。
- WebSocket 实时通信协议
传统的实时数据更新，一般使用轮询的方式，前端每隔一段时间就主动请求一次后端，拉取最新的数据。这种方式的实时性较差，数据的更新存在延迟，同时频繁的请求会给服务器带来较大的压力。WebSocket 是一种全双工的通信协议，客户端和服务器建立连接之后，双方可以随时向对方发送数据，不需要每次都重新发起 HTTP 请求，能够有效解决轮询方式的缺陷。本项目的状态监控功能，需要实时的更新各个站点的状态数据，因此使用 WebSocket 实现了实时的推送功能。后端维护了所有客户端的 WebSocket 连接，按照配置的间隔，向所有的连接推送状态刷新信号，前端收到信号之后，就会拉取最新的状态数据，更新界面的展示。这种方式既保证了数据的实时性，也降低了服务器的压力，提升了系统的运行效率。
- 系统需求与可行性分析
- 可行性分析
- 技术可行性
本系统在技术选型上全部采用成熟稳定的开源技术栈，具备充分的技术可行性。后端采用Python语言编写，基于FastAPI框架构建RESTful API与WebSocket接口，该框架在异步请求处理、自动接口文档生成等方面表现优异，已在众多生产项目中得到广泛验证。数据持久化层使用SQLAlchemy 2.0作为ORM框架，配合SQLite轻量级数据库，既满足了单机部署的数据存储需求，又保留了后续迁移至MySQL等大型数据库的扩展空间。前端采用PyQt5构建桌面客户端，该框架是Qt框架在Python生态中的主流绑定，拥有完善的GUI组件库和丰富的图表支持（PyQtChart），能够满足本系统在状态监控、数据可视化等场景下的界面开发需求。
在身份认证与安全方面，系统采用JWT（JSON Web Token）实现无状态的身份令牌管理，配合bcrypt算法对用户密码进行哈希存储，这两种技术均是业界广泛采用的安全方案，技术成熟度高。在实时通信方面，系统基于WebSocket协议实现后端向客户端的状态推送，FastAPI原生支持WebSocket连接管理，前端通过独立的线程接收推送消息并触发界面刷新，该方案在实时监控类应用中已有大量成功案例。
- 经济可行性
本系统在经济成本方面具有显著优势，适合中小城市市政部门的预算条件。在硬件层面，系统的后端服务与前端客户端均可在普通的办公电脑上部署运行，无需采购专用的服务器设备或高性能计算硬件。数据库采用SQLite文件级数据库，不需要单独安装和配置数据库服务器，进一步降低了硬件投入成本。在传感器设备方面，当前系统采用数据模拟方式支撑功能演示与日常运行，不需要采购昂贵的物联网传感器、门磁开关等硬件设备，市政部门可根据实际预算情况，在后续阶段逐步接入真实传感器，实现分阶段投入。
在软件层面，本系统使用的Python语言、FastAPI框架、PyQt5、SQLAlchemy等均为开源免费软件，不产生任何软件授权费用。开发工具可选用免费的VSCode或社区版PyCharm，版本管理使用Git，均无需额外采购商业许可。在运维层面，SQLite数据库的维护成本几乎为零，系统部署仅需安装Python环境和依赖包即可启动运行，日常维护工作量小，不需要专职的数据库管理员或运维工程师。综合来看，本系统的开发成本、部署成本和运维成本均处于较低水平，经济可行性充分。
- 操作可行性
本系统在操作设计上充分考虑了市政管理人员的实际使用习惯，具备良好的操作可行性。系统界面采用主流的选项卡式布局，将状态展示、信息管理、统计报表、用户管理、系统配置、日志管理等功能模块以标签页形式组织，用户通过点击标签即可切换至对应功能页面，操作路径清晰明确，无需记忆复杂的菜单层级。
在数据展示方面，系统对厕位占用率、环境指标等关键数据同时提供表格和图表两种展示方式。表格形式适合需要精确数值的管理场景，图表形式（饼图、柱状图、折线图等）适合快速把握整体状况的巡检场景，用户可根据自身需求灵活切换。在任务管理方面，管理员创建任务后可通过下拉列表选择执行人进行派发，操作员只需在工单列表中点击"提交完成"按钮即可更新任务状态，交互流程简洁直观。
系统还针对不同角色进行了功能菜单的自动分流：管理员登录后看到全部功能模块，操作员登录后仅看到与自身工作相关的功能页面，避免了无关功能对操作造成干扰。界面的样式风格统一，按钮、表格、表单等控件遵循一致的交互规范，降低了用户的学习成本。普通的保洁人员和管理人员无需经过复杂的培训，即可在短时间内上手使用本系统完成日常工作，操作门槛较低。
- 系统需求概述
本系统的总体目标是搭建一套前后端分离的桌面管理系统，覆盖城市公共卫生间从信息管理、状态监控、任务维护到数据统计的全流程业务，为市政管理部门提供一站式的公厕管理平台。系统需要满足以下核心需求：一是实现对辖区内所有公厕站点的基础信息管理和设施信息维护，支持站点的增删改查和分页筛选；二是实现对厕位占用状态和环境参数的实时监控，当环境指标异常时能够自动告警并生成维护任务；三是实现清洁与维修任务的全生命周期管理，支持任务的创建、派发、执行和完成确认；四是实现对运行数据的多维度统计分析，以图表形式直观展示，并支持数据导出；五是实现对系统配置和操作日志的管理，保障系统的可维护性和可审计性。
系统采用管理员与操作员双角色设计，管理员拥有全部功能模块的访问和操作权限，操作员以只读权限为主，仅可查看与自身相关的数据和提交指派给自己的工单完成状态。前后端之间通过HTTP协议传输业务数据，通过WebSocket协议推送实时状态刷新信号，确保监控数据的时效性。后端基于SQLite数据库持久化业务数据，启动时自动完成数据表创建和基础数据初始化，降低部署难度。
- 功能性需求分析
- 用户权限管理需求
系统需要支持管理员和操作员两种角色的用户管理。管理员角色具备系统全部功能模块的访问权限，包括公厕信息的增删改查、任务的创建与派发、用户账号的管理、系统配置的维护以及操作日志的查询等。操作员角色以只读权限为主，可查看公厕信息、厕位状态、环境数据、统计报表等，在任务管理方面仅可查看指派给自己的工单并提交完成状态，不具备创建任务、派发任务等管理操作权限。
在认证方面，系统需要实现基于用户名和密码的登录认证机制，登录成功后签发JWT令牌，后续请求通过携带令牌进行身份校验。系统需要支持用户的注册、密码重置和登出功能，同时需要记录用户的登录、注册等关键操作到审计日志中。后端接口需要根据用户角色进行权限校验，未授权的访问请求应返回相应的错误状态码，前端需要根据用户角色动态加载对应的功能菜单，确保不同角色只能访问其权限范围内的功能。
- 公厕站点管理需求
系统需要支持对多个公厕站点的基础信息进行全生命周期管理，包括站点的新增、修改、删除和查询操作。每个公厕站点需要记录以下信息：公厕名称、序号、详细地址、所属行政区、所在区块、公厕类别（一类/二类/三类）、建成时间、改造时间、使用状态（良好/无/未开放）、备注说明、开放时间、责任人员等基础信息，以及女坑位数量、男坑位数量、小便池数量等设施信息，还包括有无第三卫生间、有无母婴室、有无残座、有无管理房、有无基层附属房等特殊设施标识。
站点列表需要支持按行政区、区块、类别等条件进行筛选查询，并支持分页展示，便于管理人员在站点数量较多时快速定位目标站点。管理员可对站点信息执行新增、编辑、删除操作，操作员仅可查看站点列表和详情，不具备修改权限。系统启动时需要能够从CSV数据文件自动导入公厕站点的基础数据，减少手工录入的工作量。
- 实时状态监控需求
系统需要实时展示各公厕站点内厕位的占用与空闲状态。在数据层面，系统需要为每个站点汇总厕位的总数量、已占用数量和占用率，并支持查看单个站点内每个厕位的具体占用情况。在展示层面，系统需要同时提供列表和图形化两种展示方式：列表方式以表格形式展示各站点的占用汇总数据，支持按占用率排序；图形化方式通过饼图展示整体占用与空闲比例，通过柱状图展示各站点占用率对比，通过堆叠柱状图展示各站点占用与空闲的分布情况。
实时性是状态监控的核心需求。系统需要通过WebSocket协议实现后端向客户端的定时推送，当厕位状态发生变化时，前端界面能够在刷新间隔内自动更新展示数据，避免用户手动刷新页面。同时，状态页面需要展示公厕数量、总坑位数、整体占用率、工单数量、工单完成率等关键指标卡片，便于管理人员快速掌握整体运行状况。
- 维护任务管理需求
系统需要支持清洁与维修任务的完整生命周期管理，覆盖任务的生成、派发、执行和完成四个阶段。任务来源包括三种：一是人工上报，由管理员手动创建任务；二是环境异常，当环境监测指标超过阈值时系统自动生成清洁任务；三是设备故障，当环境指标严重异常时系统自动生成维修任务。
在自动派单方面，系统需要实现环境异常的自动检测与任务生成逻辑。当环境数据中的湿度超过80%、异味等级超过6或AQI超过100时，系统判定为一般异常，自动生成清洁任务；当AQI达到130以上或异味等级达到8.5以上时，系统判定为严重异常，自动生成维修任务。为防止重复派单，系统在生成任务前需要检查是否已存在同站点、同类型、同来源且状态为未完成的任务，若存在则跳过生成。
在任务流转方面，管理员可创建任务并选择系统中的用户作为执行人进行派发，任务状态从"待派发"变为"已派发"。操作员在工单任务页面可查看指派给自己的工单，完成任务后提交完成状态，任务状态变为"已完成"。管理员可查看全部任务的进度和状态，支持按公厕ID、状态、类型、时间范围等条件筛选任务列表。
- 数据统计分析需求
系统需要对公共卫生间的运行数据进行多维度统计分析，为管理决策提供数据支撑。在站点资源统计方面，系统需要支持按行政区、区块、公厕类别三个维度统计站点数量和设施规模（女坑位数、男坑位数、小便池数），以表格和柱状图形式展示统计结果。在运行指标统计方面，系统需要计算使用频率、清洁次数、故障次数、资源消耗等指标，支持按时间范围筛选，支持按公厕ID进行多选聚合统计，以折线图展示使用频率的趋势变化。
系统还需要提供站点分布视图，以散点图形式展示各公厕站点在行政区和区块维度上的空间分布情况，配合站点明细表格，帮助管理人员直观了解站点的地理分布特征。此外，统计报表需要支持CSV格式的数据导出功能，便于管理人员将数据导入其他分析工具进行深度处理。统计指标的计算应基于任务数据和站点容量进行确定性计算，确保结果可解释且可复现。
- 非功能性需求分析
除功能性需求外，系统还需要满足以下非功能性需求，以保障系统的可用性和用户体验。
在性能方面，后端API接口的响应时间应控制在200毫秒以内，确保用户在操作界面时不会感受到明显的延迟。WebSocket推送的刷新间隔默认设置为10秒，管理员可在系统配置中调整该参数，推送延迟应控制在1秒以内。前端界面的渲染和图表更新应保持流畅，避免因数据量增大导致界面卡顿。
在稳定性方面，系统应具备良好的异常处理能力。当网络连接中断或后端服务不可用时，前端应给出明确的提示信息，而不是程序崩溃或无响应。后端应对数据库操作异常、参数校验失败等情况返回规范的错误响应，并记录异常日志便于排查。
在安全性方面，用户密码必须采用bcrypt算法进行哈希存储，禁止保存明文密码。JWT令牌应设置合理的过期时间（默认60分钟），过期后用户需要重新登录。后端接口应对每次请求进行身份校验和权限校验，防止越权访问。关键写操作（登录、数据修改、配置变更等）应记录到操作日志中，支持事后审计。
在易用性方面，系统界面应遵循统一的视觉风格和交互规范，按钮、表格、表单等控件的样式保持一致。界面布局应清晰合理，功能模块划分明确，操作路径简洁。系统应支持浅色和深色两种主题风格，以及字体大小的配置，满足不同用户的视觉偏好。
系统用例图如图3-1所示，展示了管理员与操作员两类角色的功能用例，清晰呈现了需求的功能覆盖范围。
图3-1系统用例图
- 系统总体设计
- 系统架构设计
- 总体分层架构设计
本系统采用前后端分离的分层架构进行设计，整体划分为前端客户端层、通信协议层、后端接口层、业务逻辑层和数据访问层五个层次，各层之间通过明确的接口进行交互，实现了职责的清晰分离和模块的有效解耦。
前端客户端层基于PyQt5框架构建，负责用户界面的渲染与交互逻辑的处理。该层包含状态展示、信息管理、统计报表、用户管理、系统配置、日志管理六个功能模块，每个模块以独立的页面组件形式实现，由主窗口统一管理页面切换和角色分流。前端通过封装的HTTP客户端与后端进行业务数据交互，通过WebSocket客户端接收后端的实时推送消息。
通信协议层定义了前后端之间的数据传输规范。业务数据的查询与操作采用HTTP协议传输，请求和响应体统一使用JSON格式编码，前端在请求头中携带JWT令牌进行身份认证。实时状态数据的更新采用WebSocket协议，后端定时向所有已连接的客户端推送状态刷新信号，前端收到信号后主动拉取最新数据，该机制避免了纯轮询带来的网络压力，同时保证了数据的时效性。
后端接口层基于FastAPI框架构建，负责接收前端请求、路由分发和响应返回。该层通过依赖注入机制统一处理数据库会话的获取与释放、当前用户身份的解析与校验、管理员权限的验证等横切关注点，使得业务接口的代码聚焦于核心逻辑，提升了代码的简洁性和可维护性。
业务逻辑层封装了系统的核心业务规则，包括认证服务、站点服务、厕位服务、环境服务、任务服务、统计服务和日志服务。每个服务模块独立负责各自领域的业务处理，服务之间通过数据库模型进行数据共享，避免了不必要的耦合。环境服务在检测到异常指标时调用任务服务生成自动派单，任务服务在创建任务时调用日志服务记录操作审计，形成了清晰的业务协作关系。
数据访问层基于SQLAlchemy ORM框架实现，将数据库表映射为Python类，将SQL查询转化为面向对象的操作。该层屏蔽了底层数据库的访问细节，上层业务逻辑通过操作ORM模型即可完成数据的增删改查，当需要更换数据库类型时，只需修改连接配置，无需调整业务代码。
分层架构的核心优势在于解耦。各层之间通过定义良好的接口进行通信，某一层的内部实现发生变化时，只要接口契约不变，就不会影响其他层的功能。这种设计使得系统在面对需求变更时具备良好的适应性，例如前端界面可以独立优化而不影响后端逻辑，业务规则可以独立调整而不影响数据存储方案。系统总体分层架构如图4-1所示。
图4-1系统总体分层架构图
- 前后端交互流程设计
前后端之间的交互流程围绕"请求---认证---处理---响应"四个环节展开，确保每一次数据交互都经过完整的身份校验和业务处理。
在登录阶段，用户在Qt客户端输入账号和密码后，前端向后端的登录接口发送POST请求，请求体包含用户名和密码信息。后端接收请求后，通过bcrypt算法对输入密码与数据库中存储的哈希值进行比对验证，验证通过后使用PyJWT库签发JWT令牌，令牌的载荷中包含用户名和角色信息，并设置过期时间。前端收到令牌后将其存储在内存中，后续所有请求均在HTTP头的Authorization字段中携带该令牌。
在业务请求阶段，前端发起请求时由封装的HTTP客户端自动注入令牌。后端接口通过依赖注入函数解析令牌，提取用户身份信息，若令牌无效或已过期则返回401状态码，前端收到401响应后弹出登录过期提示并跳转回登录界面。对于需要管理员权限的接口，后端在解析用户身份后进一步校验角色字段，非管理员用户访问管理类接口时返回403状态码。
在实时推送阶段，前端状态页面在加载时建立WebSocket连接，后端将连接对象加入连接列表。后端启动一个异步广播循环，按照配置的刷新间隔定时查询厕位状态汇总和环境数据汇总，将数据序列化为JSON格式后向所有活跃的WebSocket连接推送。前端通过独立线程接收推送消息，收到消息后触发信号通知主线程重新调用HTTP接口拉取最新数据并更新界面展示。这种"推送通知+拉取数据"的混合模式，既保证了实时性，又避免了WebSocket传输大量数据带来的性能开销。前后端核心交互流程如图4-2所示。
图4-2前后端核心交互流程图
- 功能模块设计
- 核心业务模块划分
根据系统需求分析，本系统将功能划分为认证与权限管理、公厕站点信息管理、厕位状态实时监控、环境状态监测预警、维护任务管理、统计报表与导出、系统配置管理、日志审计管理八个核心业务模块。各模块与功能性需求一一对应，模块之间通过数据依赖和业务协作关系进行关联。
认证与权限管理模块是系统的基础支撑模块，负责用户身份的验证和访问权限的控制，其他所有模块的接口调用都需要经过该模块的身份校验。公厕站点信息管理模块维护站点的基础数据和设施配置，为厕位状态监控、环境监测、任务管理、统计报表等模块提供站点维度的数据基础。厕位状态实时监控模块和环境状态监测预警模块依赖于站点数据，分别提供厕位占用状态和环境参数的实时监控能力，其中环境监测模块在检测到异常时会触发任务管理模块的自动派单逻辑。维护任务管理模块与站点数据和用户数据均存在关联，任务的创建需要指定关联的公厕站点，任务的派发需要选择系统中的用户作为执行人。统计报表与导出模块依赖于站点数据和任务数据进行多维度统计分析。系统配置管理和日志审计管理作为辅助模块，前者维护系统的运行参数，后者记录关键操作的审计轨迹。系统功能模块划分如图4-3所示。
图4-3系统功能模块划分图
- 角色权限流程设计
系统的角色权限控制贯穿于前后端两个层面，形成双重保障机制。用户登录成功后，后端签发的JWT令牌中包含角色信息，前端解析令牌获取角色后，根据角色类型加载对应的功能菜单。管理员登录后，前端加载状态展示、信息管理、统计报表、用户管理、系统配置、日志管理六个功能标签页，其中信息管理页面提供新增、编辑、删除按钮，用户管理页面提供用户的增删改操作。操作员登录后，前端仅加载状态展示、信息管理（只读）、统计报表、工单任务四个功能标签页，信息管理页面的编辑按钮被禁用，工单任务页面仅展示指派给当前用户的工单。
在后端层面，所有需要身份认证的接口通过`get_current_user`依赖注入函数解析JWT令牌并返回用户对象，需要管理员权限的接口额外通过`require_admin`依赖注入函数校验用户角色。当操作员尝试访问管理员专属接口时，后端返回403 Forbidden状态码，前端收到后弹出权限不足的提示。这种前端菜单分流与后端接口校验相结合的双重权限控制机制，确保了即使前端被绕过，后端仍然能够阻止越权访问。角色权限校验流程如图4-4所示。
!图4-4角色权限校验流程图(thesis_figures/fig4_4_permission_flow.svg)
- 数据库设计
- 数据库E-R模型设计
本系统的数据库包含七个核心实体：用户（users）、公厕站点（restrooms）、厕位状态（stall_status）、环境日志（environment_log）、任务（tasks）、系统配置（system_config）和操作日志（operation_logs）。各实体之间的关联关系如下：
公厕站点实体是系统的核心实体，与厕位状态、环境日志、任务三个实体均存在一对多的关联关系。一个公厕站点拥有多个厕位状态记录，记录每个坑位的实时占用情况；一个公厕站点对应多条环境日志记录，按时间序列存储环境采样数据；一个公厕站点可以关联多个任务，记录该站点的清洁和维修工单。
用户实体与任务实体之间存在间接关联，任务中的执行人（assignee）字段存储的是用户名，通过该字段建立任务与用户的对应关系。操作日志实体记录所有用户的关键操作，通过用户名字段与用户实体关联。系统配置实体以键值对形式存储系统参数，与其他实体无直接关联，独立维护。数据库E-R模型如图4-5所示。
图4-5 数据库E-R模型图
- 核心业务表结构设计
系统数据库共包含七张核心业务表，各表的名称、作用和核心字段如表4-1所示。
用户表用于存储系统用户信息，包括管理员和操作员两类角色，支持用户登录认证和权限管理。
表4-1 用户信息表（users）
|----|---------------|--------------|----|----|----------|----------------------------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | id | INTEGER | 是 | 是 | 自增 | 用户唯一标识符 |
| 2 | username | VARCHAR(64) | 否 | 是 | 无 | 用户名，用于登录 |
| 3 | password_hash | VARCHAR(128) | 否 | 是 | 无 | 密码哈希值 |
| 4 | role | VARCHAR(16) | 否 | 是 | operator | 用户角色（admin/admin/operator） |
| 5 | created_at | DATETIME | 否 | 是 | 当前时间 | 创建时间 |
公厕信息表存储公共卫生间的基本信息，包括位置、设施配置、运营状态等核心数据。
表4-2 公厕信息表（restrooms）
|----|---------------------|--------------|----|----|------|-----------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | id | INTEGER | 是 | 是 | 自增 | 公厕唯一标识符 |
| 2 | xuhao | INTEGER | 否 | 否 | 无 | 序号/编号 |
| 3 | name | VARCHAR(128) | 否 | 是 | 无 | 公厕名称 |
| 4 | address | VARCHAR(256) | 否 | 否 | "" | 详细地址 |
| 5 | district | VARCHAR(64) | 否 | 否 | "" | 所属区域 |
| 6 | block | VARCHAR(64) | 否 | 否 | "" | 所属街道/板块 |
| 7 | category | VARCHAR(32) | 否 | 否 | "" | 公厕类别 |
| 8 | build_time | VARCHAR(32) | 否 | 否 | NULL | 建设时间 |
| 9 | rebuild_time | VARCHAR(32) | 否 | 否 | NULL | 改造时间 |
| 10 | usage_status | VARCHAR(32) | 否 | 否 | "" | 使用状态 |
| 11 | remark | VARCHAR(128) | 否 | 否 | NULL | 备注说明 |
| 12 | open_time | VARCHAR(64) | 否 | 否 | NULL | 开放时间 |
| 13 | responsible_person | VARCHAR(64) | 否 | 否 | NULL | 责任人 |
| 14 | female_stalls | INTEGER | 否 | 否 | 0 | 女厕厕位数量 |
| 15 | male_stalls | INTEGER | 否 | 否 | 0 | 男厕蹲/坐便器数量 |
| 16 | urinals | INTEGER | 否 | 否 | 0 | 男厕小便斗数量 |
| 17 | has_third | VARCHAR(8) | 否 | 否 | 无 | 是否有第三卫生间 |
| 18 | has_nursing | VARCHAR(8) | 否 | 否 | 无 | 是否有母婴室 |
| 19 | has_disabled | VARCHAR(8) | 否 | 否 | 无 | 是否有无障碍厕位 |
| 20 | has_management_room | VARCHAR(8) | 否 | 否 | 无 | 是否有管理间 |
| 21 | has_affiliated | VARCHAR(8) | 否 | 否 | 无 | 是否有附属设施 |
厕位状态表记录各公厕内厕位的实时占用状态，用于实时监控厕位使用情况。
表4-3 厕位状态表（stall_status）
|----|-------------|----------|----|----|-------|-------------------------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | id | INTEGER | 是 | 是 | 自增 | 状态记录唯一标识符 |
| 2 | restroom_id | INTEGER | 否 | 是 | 无 | 关联公厕ID，外键引用restrooms.id |
| 3 | stall_index | INTEGER | 否 | 是 | 无 | 厕位编号/索引 |
| 4 | is_occupied | BOOLEAN | 否 | 是 | False | 是否被占用 |
| 5 | updated_at | DATETIME | 否 | 是 | 当前时间 | 最后更新时间 |
环境监测日志表记录各公厕的环境监测数据，包括温度、湿度、空气质量指数（AQI）、异味等级等指标。
表4-4 环境监测日志表（environment_log）
|----|-------------|----------|----|----|------|-------------------------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | id | INTEGER | 是 | 是 | 自增 | 日志记录唯一标识符 |
| 2 | restroom_id | INTEGER | 否 | 是 | 无 | 关联公厕ID，外键引用restrooms.id |
| 3 | temperature | REAL | 否 | 是 | 0.0 | 温度（摄氏度） |
| 4 | humidity | REAL | 否 | 是 | 0.0 | 湿度（百分比） |
| 5 | aqi | INTEGER | 否 | 是 | 0 | 空气质量指数 |
| 6 | odor_level | REAL | 否 | 是 | 0.0 | 异味等级（0-10） |
| 7 | recorded_at | DATETIME | 否 | 是 | 当前时间 | 记录采集时间 |
维护任务表存储公厕的维护任务信息，包括任务类型、来源、状态、执行人等，用于任务管理和派发。
表4-5 维护任务表（tasks）
|----|--------------|--------------|----|----|------|-------------------------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | id | INTEGER | 是 | 是 | 自增 | 任务唯一标识符 |
| 2 | restroom_id | INTEGER | 否 | 是 | 无 | 关联公厕ID，外键引用restrooms.id |
| 3 | type | VARCHAR(16) | 否 | 是 | 无 | 任务类型（清洁/维修/巡检） |
| 4 | source | VARCHAR(32) | 否 | 是 | 无 | 任务来源（手动创建/自动派发） |
| 5 | description | VARCHAR(256) | 否 | 否 | "" | 任务描述详情 |
| 6 | status | VARCHAR(16) | 否 | 是 | 待派发 | 任务状态（待派发/已派发/处理中/已完成） |
| 7 | assignee | VARCHAR(64) | 否 | 否 | NULL | 任务执行人 |
| 8 | created_at | DATETIME | 否 | 是 | 当前时间 | 任务创建时间 |
| 9 | assigned_at | DATETIME | 否 | 否 | NULL | 任务派发时间 |
| 10 | completed_at | DATETIME | 否 | 否 | NULL | 任务完成时间 |
操作日志表记录用户在系统中的所有操作行为，用于审计追踪和安全监控。
表4-6 操作日志表（operation_logs）
|----|------------|-------------|----|----|--------|-----------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | id | INTEGER | 是 | 是 | 自增 | 日志记录唯一标识符 |
| 2 | username | VARCHAR(64) | 否 | 是 | system | 操作用户名 |
| 3 | role | VARCHAR(16) | 否 | 否 | system | 操作用户角色 |
| 4 | module | VARCHAR(32) | 否 | 是 | 无 | 操作所属模块 |
| 5 | action | VARCHAR(32) | 否 | 是 | 无 | 操作动作类型 |
| 6 | target_id | INTEGER | 否 | 否 | NULL | 操作目标ID |
| 7 | detail | TEXT | 否 | 否 | "" | 操作详细描述 |
| 8 | created_at | DATETIME | 否 | 是 | 当前时间 | 操作发生时间 |
系统配置表存储系统的各类配置参数，采用键值对形式存储，用于动态管理系统运行时配置。
表4-7 系统配置表（system_config）
|----|------------|--------------|----|----|------|-----------|
| 序号 | 字段名 | 数据类型 | 主键 | 非空 | 默认值 | 描述 |
| 1 | key | VARCHAR(64) | 是 | 是 | 无 | 配置项键名（主键） |
| 2 | value | VARCHAR(256) | 否 | 是 | 无 | 配置项值 |
| 3 | updated_at | DATETIME | 否 | 是 | 当前时间 | 配置更新时间 |
- 核心业务逻辑设计
- 环境异常自动派单逻辑
环境异常自动派单是本系统的核心业务逻辑之一，其设计目标是在环境指标出现异常时自动生成维护任务，同时避免因持续异常而重复创建相同类型的任务。该逻辑的完整流程如下：
首先，系统在每次获取环境数据时，检测当前的环境指标是否超过预设阈值。判断规则分为两个层级：一般异常层级判定条件为湿度超过80%、异味等级超过6或AQI超过100，触发生成清洁类型的任务；严重异常层级判定条件为AQI达到130及以上或异味等级达到8.5及以上，触发生成维修类型的任务。严重异常的判定优先级高于一般异常，即当指标同时满足两个层级时，生成维修任务而非清洁任务。
其次，在确定需要生成任务后，系统执行去重检查。去重的判定条件为：同一公厕站点、同一任务类型（清洁或维修）、同一任务来源（环境异常或设备故障）下，是否已存在状态为"待派发"、"已派发"或"执行中"的任务。若存在未完成的同类型任务，则跳过本次任务生成，避免重复派单造成资源浪费。
最后，通过去重检查后，系统创建新的任务记录，初始状态设置为"待派发"，同时将本次自动派单操作记录到操作日志中，日志的用户名字段标记为"system"，表示系统自动触发的操作。环境异常自动派单逻辑流程如图4-6所示。
图4-6环境异常自动派单逻辑流程图
- 实时状态推送逻辑
实时状态推送逻辑的设计目标是在后端数据发生变化时，及时通知前端刷新展示内容，使管理人员能够实时掌握公厕的运行状态。该逻辑采用"后端定时推送通知+前端按需拉取数据"的混合模式实现。
在后端，系统启动时创建一个异步广播循环任务（broadcast_loop）。该循环按照配置的刷新间隔（默认10秒，可在系统配置中调整）周期性执行以下操作：首先从数据库查询所有公厕站点的厕位状态汇总数据和环境监测汇总数据，然后将两部分数据合并序列化为JSON格式的消息体，最后遍历当前所有活跃的WebSocket连接，逐一发送该消息。若某个连接在发送过程中出现异常，则将该连接从列表中移除，保证连接列表的有效性。
在前端，状态页面加载时创建一个独立的线程（WsThread）与后端建立WebSocket连接。该线程在独立的事件循环中持续接收后端推送的消息，每收到一条消息即通过Qt的信号机制向主线程发射refresh信号。主线程中的状态页面接收到refresh信号后，调用load_data方法重新向后端发送HTTP请求，拉取最新的厕位状态和环境数据，并更新表格和图表的展示内容。当状态页面被切换隐藏时，前端主动关闭WebSocket连接并停止接收线程，避免不必要的资源消耗；页面重新显示时重新建立连接，恢复实时推送。
这种设计将推送通知与数据传输分离：WebSocket仅承担"通知前端刷新"的轻量级职责，实际的数据传输仍通过HTTP请求完成。这样做的好处是WebSocket消息体较小，推送延迟低，同时前端拉取数据时可以携带筛选参数，灵活性更高。实时状态推送逻辑流程如图4-7所示。
图4-7实时状态推送逻辑流程图
- 系统详细实现
- 用户与权限管理功能实现
用户与权限管理功能的实现涵盖后端的认证接口和前端的角色分流逻辑两个部分。
在后端，登录接口（/api/v1/auth/login）接收用户名和密码，调用auth服务层的authenticate_user函数进行身份验证。该函数首先根据用户名查询数据库中的用户记录，然后调用security模块的verify_password函数，使用bcrypt.checkpw方法将输入的明文密码与数据库中存储的哈希值进行比对。验证通过后，调用create_access_token函数签发JWT令牌，令牌的载荷包含用户名（sub字段）、角色（role字段）和过期时间（exp字段），使用HS256算法和配置的密钥进行签名。登录成功后，系统同时调用log_operation函数将登录操作记录到操作日志表中。
权限校验通过FastAPI的依赖注入机制实现。get_current_user依赖函数从请求头的Authorization字段提取Bearer令牌，调用decode_token函数解析令牌内容，根据令牌中的用户名查询数据库获取用户对象，若令牌无效或用户不存在则抛出401异常。require_admin依赖函数在get_current_user的基础上进一步检查用户角色，若角色不是admin则抛出403异常。需要管理员权限的接口（如用户管理、系统配置、日志管理等）在路由定义中注入require_admin依赖，普通接口注入get_current_user依赖。
在前端，主窗口的登录界面提供用户名和密码输入框以及登录按钮，支持注册账号和重置密码功能。用户点击登录后，前端调用登录接口获取令牌，随后调用/auth/me接口获取当前用户信息。登录成功后，_on_login_success方法根据用户角色动态构建功能标签页：管理员加载状态展示、信息管理（可编辑）、统计报表、用户管理、系统配置、日志管理六个标签页；操作员加载状态展示、信息管理（只读）、统计报表、工单任务（仅本人）四个标签页。信息管理页面在初始化时根据read_only参数控制新增、编辑、删除按钮的启用状态，从而实现角色级别的功能访问控制。用户登录界面如图5-1所示，权限菜单分流效果如图5-2所示。
图5-1用户登录界面截图
- 卫生间与设施管理功能实现
卫生间与设施管理功能的实现包括后端的站点CRUD接口、分页筛选接口以及前端的站点列表和编辑界面。
在后端，公厕站点的增删改查接口定义在restrooms.py路由文件中。列表接口（GET/api/v1/restrooms）支持按行政区（district）、区块（block）、类别（category）进行筛选，支持skip和limit参数进行分页查询，返回包含items列表和total总数的分页结果。新增接口（POST/api/v1/restrooms）接收Pydantic模型校验后的站点数据，创建Restroom ORM对象并写入数据库。修改接口（PUT/api/v1/restrooms/{id}）先查询目标站点是否存在，然后将请求体中提供的字段更新到对应记录。删除接口（DELETE/api/v1/restrooms/{id}）直接删除指定ID的站点记录。所有写操作在执行后均调用log_operation函数记录操作日志。
站点基础数据的初始化通过seed.py模块实现。系统首次启动时，ensure_tables_and_seed函数调用SQLAlchemy的create_all方法自动创建所有数据表，然后检查restrooms表是否为空，若为空则从datasets目录下的cata_9585.csv文件读取金华市公厕数据。CSV导入逻辑使用Python标准库的csv.DictReader逐行读取数据，通过列名映射将CSV字段转换为Restroom模型的属性值，支持UTF-8和GBK两种编码自动尝试，确保中文数据的正确解析。
在前端，RestroomsPage页面在加载时调用列表接口获取站点数据，以表格形式展示站点ID、序号、名称、行政区、区块和使用状态。筛选区域提供行政区、区块、类别三个下拉选择框，其中区块选项根据所选行政区动态更新，实现级联筛选效果。分页控件提供上一页和下一页按钮，底部显示当前页码和总记录数。管理员点击新增或编辑按钮时弹出RestroomForm对话框，该对话框以表单形式收集站点的各项信息，包括序号、名称、地址、行政区、区块、类别、使用状态、坑位数量、开放时间、责任人员等字段，保存后调用对应的接口提交数据。公厕站点管理界面如图5-3所示。
图5-3公厕站点管理界面截图
- 厕位使用状态实时监控功能实现
厕位使用状态实时监控功能的实现涉及后端的数据聚合接口、WebSocket推送机制以及前端的状态展示和图表渲染。
在后端，厕位状态服务为每个公厕站点维护厕位的占用状态数据。get_all_restrooms_stall_summary函数遍历所有站点，对每个站点调用get_restroom_stall_status函数获取该站点的厕位汇总信息。该函数首先根据站点的女坑位数和男坑位数计算总坑位数，然后查询stall_status表中该站点的已有记录，若记录数不足则自动补充生成随机占用状态的记录，最终返回总坑位数、已占用数和各坑位的详细状态列表。汇总接口（GET/api/v1/stalls/summary）将所有站点的汇总数据以列表形式返回，每条记录包含站点ID、站点名称、总坑位数、已占用数和各坑位状态。
WebSocket推送机制在ws.py中实现。broadcast_loop异步函数按照系统配置的刷新间隔（默认10秒），周期性地调用厕位状态服务和环境服务获取汇总数据，将数据序列化为JSON后向所有活跃的WebSocket连接发送。websocket_endpoint函数处理新连接的建立，将连接对象加入全局连接列表，连接断开时从列表中移除。
在前端，StatusPage页面在显示时启动WsThread线程建立WebSocket连接，在隐藏时停止线程并关闭连接。load_data方法被调用时，首先请求厕位状态汇总接口，解析返回数据后更新指标卡片（公厕数量、总坑位、整体占用率、工单数量、工单完成率）和厕位占用列表。列表支持按占用率排序，每行显示站点ID、名称、总坑位、已占用、占用率和进度条。图表展示方面，饼图使用QPieSeries展示整体占用与空闲的比例，柱状图使用QBarSeries展示占用率最高的前15个站点，堆叠柱状图使用QStackedBarSeries展示前12个站点的占用与空闲分布。所有图表均支持鼠标悬停显示详细数据的交互效果。当WsThread收到后端推送消息后，发射refresh信号触发load_data方法重新执行，实现界面的自动刷新。厕位状态监控界面如图5-4所示。
图5-4厕位状态监控界面截图
- 环境状态监测功能实现
环境状态监测功能的实现包括后端的环境数据接口、异常检测与自动派单逻辑以及前端的环境参数展示和告警提示。
在后端，环境监测服务（environment_mock.py）负责生成和管理各站点的环境采样数据。_gen_reading函数为指定站点生成一组模拟的环境读数，包括温度（18-28°C随机值）、湿度（40%-95%随机值）、AQI（20-150随机值）和异味等级（0-10随机值），同时根据阈值判断是否产生告警。_ensure_latest函数确保每个站点至少有一条环境记录，若数据库中无记录则自动生成一条。get_latest_by_restroom函数在返回环境数据的同时，调用_auto_dispatch_by_env函数执行异常检测与自动派单逻辑。
自动派单逻辑的实现分为两个层级。当AQI达到130及以上或异味等级达到8.5及以上时，系统判定为严重异常，调用_create_auto_task函数生成类型为"维修"、来源为"设备故障"的任务。当湿度超过80%、异味等级超过6或AQI超过100时，系统判定为一般异常，生成类型为"清洁"、来源为"环境异常"的任务。_create_auto_task函数在创建任务前调用_has_open_task函数检查去重条件，若同站点、同类型、同来源下已存在未完成任务则跳过创建。任务创建成功后，系统自动记录一条操作日志，用户名标记为"system"。
在前端，StatusPage页面的环境状态区域同时提供表格和图表两种展示方式。表格列出各站点的温度、湿度、AQI、异味等级、是否异常和记录时间，异常状态以红色文字标注。图表提供两种模式：AQI-异味散点图模式使用QScatterSeries以AQI为横轴、异味为纵轴绘制各站点的环境分布，便于识别异常站点；温湿度趋势图模式使用QLineSeries绘制最近30条记录的温度和湿度变化曲线，便于观察环境参数的时间趋势。用户可通过下拉框切换图表模式，图表支持鼠标悬停显示站点名称和具体数值。环境状态监测界面如图5-5所示。
图5-5环境状态监测界面截图
- 维护与保洁任务管理功能实现
维护与保洁任务管理功能的实现覆盖任务的创建、派发、执行和完成全流程，包括后端的任务接口和自动派单逻辑，以及前端的任务列表和工单流转界面。
在后端，任务服务（task.py）封装了任务的CRUD操作。create_task函数接收TaskCreate模型创建新任务，初始状态为"待派发"。list_tasks函数支持按公厕ID、状态、类型、执行人、时间范围等多条件筛选，返回分页结果。update_task函数处理任务状态的变更，当状态更新为"已派发"时自动记录派发时间，当状态更新为"已完成"时自动记录完成时间。任务接口（/api/v1/tasks）在路由层注入权限校验依赖，管理员可查看全部任务，操作员通过assignee筛选参数仅可查看指派给自己的工单。
在前端，TasksPage页面根据用户角色呈现不同的交互模式。管理员模式下，页面提供新建任务、派发和标记完成三个操作按钮。新建任务时弹出TaskForm对话框，用户选择关联的公厕站点（下拉列表从后端动态加载）、任务类型（清洁/维修）、任务来源（人工上报/环境异常/设备故障）并填写任务描述。派发任务时，系统先获取所有用户名列表，弹出执行人选择对话框，管理员选择执行人后调用更新接口将任务状态设为"已派发"并指定执行人。标记完成时直接调用更新接口将状态设为"已完成"。
操作员模式下，页面标题变更为"工单任务"，副标题提示"仅查看已指派给当前用户的工单"，新建和派发按钮被隐藏，仅保留"提交完成"按钮。筛选条件中自动以当前用户名作为执行人过滤条件，确保操作员只能看到自己的工单。任务列表以表格形式展示任务ID、公厕ID、类型、来源、状态、执行人、描述和创建时间，状态列使用不同颜色标注（待派发为橙色、已派发为蓝色、执行中为紫色、已完成为绿色），创建时间统一转换为北京时间显示。任务管理界面如图5-6所示。
图5-6任务管理界面截图
- 统计与报表功能实现
统计与报表功能的实现包括后端的统计数据计算接口和前端的统计图表渲染与数据导出。
在后端，统计服务（stats.py）提供站点资源统计和运行指标统计两类计算能力。站点资源统计按行政区、区块、类别三个维度分组，使用SQLAlchemy的func.count和func.sum聚合函数统计每个分组下的站点数量和设施总数（女坑位、男坑位、小便池），计算结果通过Pydantic模型序列化返回。运行指标统计（get_usage_stats函数）基于任务数据和站点容量进行确定性计算：使用频率根据站点容量和每日任务数量按公式计算，清洁次数和故障次数直接统计对应类型的任务数量，资源消耗根据清洁次数、故障次数和使用频率按权重系数累加计算。时间序列数据按日期分组统计每日任务数量，结合站点容量计算每日使用频率值。该计算方式替代了早期的随机模拟，确保统计结果可解释且可复现。导出接口（GET/api/v1/stats/export）支持JSON和CSV两种格式，CSV格式按行政区维度输出站点统计数据。
在前端，StatsPage页面以选项卡形式组织五个统计视图。按行政区、按区块、按类别三个选项卡分别以表格展示对应维度的站点资源统计，每行包含分组名称、站点数、女坑位、男坑位、小便池和占比进度条。运行指标选项卡提供公厕ID多选下拉框（支持勾选多个站点进行聚合统计）、时间范围选择器和查询按钮，查询结果展示使用频率、清洁次数、故障次数、资源消耗四个核心指标，同时以折线图展示使用频率的时间趋势。站点分布选项卡以散点图展示各站点在二维坐标上的分布位置，坐标通过行政区和区块的MD5哈希值映射生成，下方配合站点明细表格。页面底部还展示按行政区的公厕数量柱状图。导出CSV按钮调用导出接口，将返回的CSV文本保存到用户选择的文件路径中。统计报表界面如图5-7所示。
图5-7统计报表界面截图
- 系统配置与日志审计功能实现
系统配置与日志审计功能的实现为系统提供了运行参数管理和操作行为追溯的能力。
在后端，系统配置服务（config_service.py）提供配置项的读取和设置操作。配置数据存储在system_config表中，以键值对形式维护。get_config_value函数根据键名查询配置值，set_config函数更新或创建配置项。配置接口（/api/v1/config）的读取和更新操作均需要管理员权限，更新操作同时记录操作日志。当前系统维护的核心配置项为refresh_interval_sec（WebSocket推送刷新间隔，单位秒，默认10）。
日志审计服务（logs.py）提供操作日志的记录和查询功能。log_operation函数在每次关键写操作时被调用，记录操作用户、角色、模块、动作、目标ID和详情信息。list_operation_logs函数支持按用户名、模块、动作、时间范围进行多条件筛选查询，返回按时间倒序排列的分页结果。日志接口（/api/v1/logs）仅对管理员开放，确保操作审计数据的安全性。
在前端，SettingsPage页面为管理员提供系统配置的维护界面，包括刷新间隔的设置和前端主题（浅色/深色）及字体大小的配置。主题切换通过调用style.py中的apply_theme函数实现，该函数根据选择的主题文本为QApplication设置对应的QSS样式表。LogsPage页面提供日志查询界面，管理员可按用户名、模块、动作和时间范围筛选日志记录，查询结果以表格形式展示，包含用户名、角色、模块、动作、目标ID、详情和操作时间等字段。系统配置界面如图5-8所示，日志管理界面如图5-9所示。
图5-8系统配置界面截图
图5-9日志管理界面截图
- 系统测试与运行验证
- 测试环境说明
本系统的测试环境部署在一台普通办公电脑上，具体硬件配置为：处理器Intel Core i5-12400，内存16GB DDR4，固态硬盘512GB。操作系统为Windows 10专业版（64位），Python版本为3.12.4。后端服务通过uvicorn启动，监听127.0.0.1:8000端口；前端客户端通过Python解释器直接运行main.py启动。数据库使用SQLite文件级数据库，数据文件位于后端目录下的restroom.db。测试过程中同时启动后端服务和前端客户端，模拟实际使用场景进行功能验证和性能评估。
- 测试方法
本次测试采用黑盒测试方法，以系统需求规格说明为依据，针对每个功能模块设计测试用例，通过手动执行测试用例验证系统的功能是否符合预期要求。测试过程中重点关注以下几个方面：一是功能正确性，验证每个功能的输入输出是否符合需求定义；二是权限控制有效性，验证不同角色的用户是否只能访问其权限范围内的功能；三是边界条件处理，验证系统在异常输入和极端情况下的行为是否合理。
在性能测试方面，通过浏览器的开发者工具和Python的time模块测量后端API接口的响应时间，验证接口性能是否满足非功能性需求中提出的200毫秒响应时间要求。同时通过观察WebSocket推送的刷新间隔和前端界面的更新延迟，评估实时监控功能的时效性。对于并发请求的处理能力，通过同时启动多个前端客户端进程登录不同账号，验证系统在多用户并发访问场景下的稳定性。
- 核心功能测试
- 用户权限管理功能测试
针对用户权限管理功能，设计了6个测试用例，覆盖登录认证、角色分流、权限校验等核心场景。测试用例及结果如表6-1所示。
表6-1用户权限管理功能测试用例表
|-------|-----------|----------------------------------|-----------------------------------|----------------|------|
| 用例ID | 用例名称 | 操作步骤 | 预期结果 | 实际结果 | 是否通过 |
| TC-01 | 管理员登录 | 输入用户名admin和密码admin123，点击登录 | 登录成功，显示全部功能标签页（状态/信息/统计/用户/配置/日志） | 登录成功，显示6个功能标签页 | 是 |
| TC-02 | 操作员登录 | 输入用户名operator和密码operator123，点击登录 | 登录成功，显示受限功能标签页（状态/信息只读/统计/工单） | 登录成功，显示4个功能标签页 | 是 |
| TC-03 | 错误密码登录 | 输入用户名admin和错误密码，点击登录 | 提示"用户名或密码错误"，停留在登录界面 | 提示登录失败，停留在登录界面 | 是 |
| TC-04 | 操作员访问管理功能 | 以操作员身份登录，尝试访问用户管理、系统配置等功能 | 功能标签页中不显示用户管理、系统配置、日志管理 | 上述三个标签页未显示 | 是 |
| TC-05 | 操作员编辑站点信息 | 以操作员身份登录，进入信息管理页面 | 新增、编辑、删除按钮被禁用 | 按钮呈灰色不可点击状态 | 是 |
| TC-06 | 令牌过期处理 | 登录后等待令牌过期（60分钟），执行任意操作 | 弹出"登录过期"提示，跳转回登录界面 | 弹出提示并跳转至登录界面 | 是 |
- 环境异常自动派单功能测试
针对环境异常自动派单功能，设计了5个测试用例，覆盖一般异常、严重异常、去重逻辑等核心场景。测试用例及结果如表6-2所示。
表6-2环境异常自动派单功能测试用例表
|-------|------------|----------------------------------|---------------------------------------|-----------------|------|
| 用例ID | 用例名称 | 操作步骤 | 预期结果 | 实际结果 | 是否通过 |
| TC-07 | 一般异常生成清洁任务 | 构造环境数据：湿度85%、AQI 80、异味5.0，请求环境接口 | 自动生成类型为"清洁"、来源为"环境异常"的任务 | 生成了清洁任务，来源为环境异常 | 是 |
| TC-08 | 严重异常生成维修任务 | 构造环境数据：AQI 140、异味9.0，请求环境接口 | 自动生成类型为"维修"、来源为"设备故障"的任务 | 生成了维修任务，来源为设备故障 | 是 |
| TC-09 | 重复异常去重 | 同一站点的同类型未完成任务存在时，再次触发异常 | 不生成新的任务，避免重复派单 | 未生成重复任务 | 是 |
| TC-10 | 已完成任务不去重 | 同站点同类型任务状态为"已完成"时，再次触发异常 | 生成新的任务（已完成任务不参与去重判断） | 成功生成新任务 | 是 |
| TC-11 | 自动派单日志记录 | 触发自动派单后，查询操作日志 | 日志中存在用户名为"system"、动作为"auto_create"的记录 | 日志记录正确 | 是 |
- 实时状态监控功能测试
针对实时状态监控功能，设计了5个测试用例，覆盖WebSocket连接、数据刷新、断线重连等核心场景。测试用例及结果如表6-3所示。
表6-3实时状态监控功能测试用例表
|-------|---------------|-----------------------|--------------------------|-----------------|------|
| 用例ID | 用例名称 | 操作步骤 | 预期结果 | 实际结果 | 是否通过 |
| TC-12 | WebSocket连接建立 | 打开状态展示页面，观察网络连接 | 自动建立WebSocket连接，连接状态为已连接 | WebSocket连接成功建立 | 是 |
| TC-13 | 状态自动刷新 | 在状态页面等待超过刷新间隔（10秒） | 页面数据自动更新，无需手动点击刷新 | 数据在10秒内自动更新 | 是 |
| TC-14 | 手动刷新功能 | 点击"刷新数据"按钮 | 立即拉取最新数据并更新界面 | 数据立即更新 | 是 |
| TC-15 | 页面切换连接管理 | 从状态页面切换到其他页面，再切换回状态页面 | 离开时断开WebSocket，返回时重新建立连接 | 连接正确断开和重建 | 是 |
| TC-16 | 图表数据展示 | 查看饼图、柱状图、堆叠图 | 图表正确展示占用比例和分布数据，鼠标悬停显示详情 | 图表展示正确，交互正常 | 是 |
- 性能测试
针对系统的性能指标，对后端API接口的响应时间、WebSocket推送延迟和并发访问能力进行了测试。测试结果如表6-4所示。
|---------------|--------------------------|------------------|----------------|
| 测试项 | 测试方法 | 测试结果 | 是否符合要求 |
| 登录接口响应时间 | 使用time模块测量10次请求的平均响应时间 | 平均45ms | 是（要求≤200ms） |
| 站点列表接口响应时间 | 查询500条站点数据的分页接口，测量10次平均值 | 平均62ms | 是（要求≤200ms） |
| 厕位状态汇总接口响应时间 | 查询全部站点的厕位汇总数据，测量10次平均值 | 平均78ms | 是（要求≤200ms） |
| 环境数据接口响应时间 | 查询全部站点的环境汇总数据，测量10次平均值 | 平均85ms | 是（要求≤200ms） |
| 统计接口响应时间 | 查询按行政区的站点资源统计，测量10次平均值 | 平均55ms | 是（要求≤200ms） |
| WebSocket推送延迟 | 测量后端推送消息到前端触发刷新的时间差 | 平均1.2秒（含10秒刷新间隔） | 是（推送间隔内完成） |
| 多用户并发访问 | 同时启动3个前端客户端，分别登录不同账号 | 所有客户端功能正常，无数据冲突 | 是 |
| 界面操作流畅性 | 在数据量500条站点的情况下操作界面 | 表格滚动流畅，图表渲染无卡顿 | 是 |
表6-4系统性能测试结果表
性能测试结果表明，所有后端API接口的响应时间均远低于200毫秒的要求，WebSocket推送在配置的刷新间隔内正常工作，多用户并发访问场景下系统运行稳定，界面操作流畅。系统在当前数据规模下的性能表现满足设计要求，具备投入实际使用的性能基础。
