✅源码获取：
🍅--------------------【点击左上方头像，在置顶文章上方的wx】联系我们-----------------🍅
✌网站介绍：✌10年+项目辅导经验、专注于计算机技术领域学生项目实战辅导。
✌服务范围：大数据、机器学习、Java(SpringBoo/SSM)、Python、PHP、Nodejs、爬虫、数据可视化、小程序、安卓app等设计与开发。
✅优秀相关专栏推荐✅
2024-2025年最全的计算机软件毕业设计选题大全：1000个热门选题推荐✅
Java精品实战项目1000+
Python精品实战项目1000+
ASP.NET精品实战项目1000+
PHP精品实战项目1000+
APP精品实战项目1000+
微信小程序精品实战项目1000+
Node.js精品实战项目1000+
针对中小城市基层市政部门在公共卫生间管理中面临的预算有限、人工管理效率低、现有智慧公厕方案落地成本过高的问题，本课题设计并实现了一套低成本的公共卫生间管理系统。系统采用前后端分离的架构，基于 PyQt5 与 FastAPI 完成开发，实现了用户权限管理、站点管理、实时状态监控、环境监测、自动派单、统计报表等核心功能，其中环境异常自动派单、WebSocket 实时推送、任务去重等机制，有效解决了传统管理中的痛点。经过测试验证，系统的所有功能均满足设计需求，能够有效提升基层部门的管理效率，降低管理成本。该系统为中小城市的公共卫生间信息化管理提供了可落地的低成本解决方案，具备良好的应用价值。
本系统采用前后端分离的分层架构进行设计，整体划分为前端客户端层、通信协议层、后端接口层、业务逻辑层和数据访问层五个层次，各层之间通过明确的接口进行交互，实现了职责的清晰分离和模块的有效解耦。
前端客户端层基于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-3所示。
图4-3系统功能模块划分图
- 环境异常自动派单逻辑
环境异常自动派单是本系统的核心业务逻辑之一，其设计目标是在环境指标出现异常时自动生成维护任务，同时避免因持续异常而重复创建相同类型的任务。该逻辑的完整流程如下：
首先，系统在每次获取环境数据时，检测当前的环境指标是否超过预设阈值。判断规则分为两个层级：一般异常层级判定条件为湿度超过80%、异味等级超过6或AQI超过100，触发生成清洁类型的任务；严重异常层级判定条件为AQI达到130及以上或异味等级达到8.5及以上，触发生成维修类型的任务。严重异常的判定优先级高于一般异常，即当指标同时满足两个层级时，生成维修任务而非清洁任务。
其次，在确定需要生成任务后，系统执行去重检查。去重的判定条件为：同一公厕站点、同一任务类型（清洁或维修）、同一任务来源（环境异常或设备故障）下，是否已存在状态为"待派发"、"已派发"或"执行中"的任务。若存在未完成的同类型任务，则跳过本次任务生成，避免重复派单造成资源浪费。
最后，通过去重检查后，系统创建新的任务记录，初始状态设置为"待派发"，同时将本次自动派单操作记录到操作日志中，日志的用户名字段标记为"system"，表示系统自动触发的操作。环境异常自动派单逻辑流程如图4-6所示。
- 实时状态推送逻辑
实时状态推送逻辑的设计目标是在后端数据发生变化时，及时通知前端刷新展示内容，使管理人员能够实时掌握公厕的运行状态。该逻辑采用"后端定时推送通知+前端按需拉取数据"的混合模式实现。
在后端，系统启动时创建一个异步广播循环任务（broadcast_loop）。该循环按照配置的刷新间隔（默认10秒，可在系统配置中调整）周期性执行以下操作：首先从数据库查询所有公厕站点的厕位状态汇总数据和环境监测汇总数据，然后将两部分数据合并序列化为JSON格式的消息体，最后遍历当前所有活跃的WebSocket连接，逐一发送该消息。若某个连接在发送过程中出现异常，则将该连接从列表中移除，保证连接列表的有效性。
在前端，状态页面加载时创建一个独立的线程（WsThread）与后端建立WebSocket连接。该线程在独立的事件循环中持续接收后端推送的消息，每收到一条消息即通过Qt的信号机制向主线程发射refresh信号。主线程中的状态页面接收到refresh信号后，调用load_data方法重新向后端发送HTTP请求，拉取最新的厕位状态和环境数据，并更新表格和图表的展示内容。当状态页面被切换隐藏时，前端主动关闭WebSocket连接并停止接收线程，避免不必要的资源消耗；页面重新显示时重新建立连接，恢复实时推送。
这种设计将推送通知与数据传输分离：WebSocket仅承担"通知前端刷新"的轻量级职责，实际的数据传输仍通过HTTP请求完成。这样做的好处是WebSocket消息体较小，推送延迟低，同时前端拉取数据时可以携带筛选参数，灵活性更高。实时状态推送逻辑流程如图4-7所示。
在前端，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日志管理界面截图
