ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

基于SpringBoot与微信小程序的校园活动报名与签到系统的设计与实现毕设源码(源码+lw+部署文档+讲解等)

基于SpringBoot与微信小程序的校园活动报名与签到系统的设计与实现毕设源码(源码+lw+部署文档+讲解等) 博主介绍✌ 专注于VUE,小程序安卓Java,python,物联网专业 从事毕业指导项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题我会尽力帮助你。一、研究目的在当前信息技术迅猛发展的背景下校园活动的组织与管理已成为高校提升学生综合素质、促进校园文化繁荣的重要手段。传统的纸质报名表和人工签到方式不仅耗时耗力而且易出现信息不一致、统计滞后等问题严重制约了活动开展的效率与质量。随着移动互联网和微信生态系统的广泛普及基于移动端的活动管理已成为一种趋势但现有解决方案多为通用型平台缺乏针对高校校园场景的定制化功能无法满足学生、教师及行政人员在报名、签到、统计等方面的多样化需求。为此本研究旨在构建一套基于SpringBoot框架与微信小程序技术的校园活动报名与签到系统以期实现高效、便捷、可扩展的管理流程。具体而言系统将通过后端微服务实现报名数据的统一存储、权限校验和业务逻辑处理前端小程序则提供直观的用户界面使学生能够快速完成报名、查看活动详情并进行二维码签到同时教师与管理员可实时获取报名情况、签到统计及异常报告。通过对比传统方式本研究期望在报名准确率、签到时效性和数据可视化程度等关键指标上实现显著提升。进一步地系统的模块化设计将为后续功能扩展提供便利支持活动日程管理、奖惩机制集成以及与校园其他信息系统的无缝对接从而为高校信息化建设提供可复制、可推广的技术范例。二、研究意义在高校信息化建设的进程中校园活动管理作为提升学生综合素质与校园文化活力的重要载体其高效运作直接关系到教学质量与学生发展。传统纸质报名与人工签到方式不仅耗费人力物力而且易导致数据不一致、统计滞后等问题严重制约了活动开展的效率与质量。随着移动互联网和微信生态系统的普及基于移动端的活动管理已成为趋势但现有通用平台缺乏针对高校校园场景的定制化功能无法满足学生、教师及行政人员在报名、签到、统计等方面多样化需求。为此本研究通过构建基于SpringBoot框架与微信小程序技术的校园活动报名与签到系统旨在实现报名数据统一存储、权限校验和业务逻辑处理并提供直观用户界面使学生能够快速完成报名、查看活动详情并进行二维码签到同时教师与管理员可实时获取报名情况、签到统计及异常报告。该系统通过模块化设计为后续功能扩展提供便利支持活动日程管理、奖惩机制集成以及与校园其他信息系统的无缝对接从而为高校信息化建设提供可复制、可推广的技术范例。系统的实施将显著提升报名与签到的时效性与准确性减少人工错误降低行政成本同时通过实时数据采集与可视化统计管理者能够快速掌握活动参与度、资源使用情况为后续活动策划提供依据此外系统支持多种角色权限管理可实现教师、学生、管理员等不同身份的功能隔离保障数据安全与隐私合规在技术层面采用SpringBoot微服务架构与微信小程序前端技术具备高并发处理能力与良好用户体验可适应高校校园网络环境的变化从长远来看该系统为高校信息化平台提供可扩展的模块化基础可与学生信息管理系统、教学资源平台等实现深度集成推动校园数字化治理向纵深发展。除此之外研究过程中对数据安全、身份认证、权限控制等关键技术的深入探讨将为高校信息系统的安全设计提供参考通过对比实验与用户调研本研究将验证基于移动端报名签到系统在提升学生参与度、增强活动透明度方面的有效性为教育技术领域提供实证依据最终系统的落地实施将促进校园活动管理流程的标准化与信息化提升高校整体治理水平并为类似教育机构提供可复制、可推广的技术方案。在数据驱动的教育决策时代系统所产生的高质量报名与签到数据将成为开展教育科研的重要资源研究者可利用这些数据进行学生参与行为分析、活动效果评估以及学习动机研究从而推动教育理论与实践的融合与此同时系统对接校园一卡通、教务管理等核心信息平台可实现跨系统的数据共享与业务协同进一步提升高校信息化整体效能通过持续迭代与功能扩展系统可支持线上线下混合活动、社团管理、志愿服务等多元化场景为高校数字校园建设提供坚实技术支撑。本研究所提出的基于SpringBoot与微信小程序的架构具备良好的可扩展性与模块化特征能够根据高校规模与业务需求灵活调整服务部署在未来工作中可进一步引入大数据分析、机器学习算法对报名趋势、签到异常进行预测与预警同时可探索区块链技术在活动凭证验证与数据不可篡改方面的应用以提升系统可信度通过与云平台的深度集成系统将实现弹性伸缩满足高峰期报名冲击的稳定运行。三、国内外研究现状在全球范围内基于移动终端的活动管理系统已成为信息化研究的重要课题。国外学者普遍关注系统的可用性与数据安全提出了多种基于二维码、NFC以及蓝牙低功耗技术的签到方案并对其在高校、企业及公共场所中的应用进行了实证研究。与此同时后端技术方面的研究主要聚焦于微服务架构与容器化部署以提升系统的可扩展性与弹性Spring Boot 等轻量级框架被广泛用于快速搭建 RESTful API配合消息队列实现高并发请求处理。学术论文中亦有对数据分析与可视化的探讨利用大数据技术对报名与签到数据进行趋势预测、异常检测以及用户画像构建从而为活动策划与资源配置提供决策支持。国内研究则在此基础上进一步结合微信生态系统探索基于微信小程序的校园活动管理模式。多所高校已将小程序作为学生报名与签到的主要入口通过调用统一的身份认证接口实现单点登录并利用小程序内置的二维码扫描功能完成现场签到。研究者们对系统的性能、易用性以及安全性进行了评估提出了多层权限控制、数据加密传输以及日志审计等技术方案以满足校园信息化建设的合规要求。与此同时国内学术界也关注系统与校园一卡通、教务管理系统等核心信息平台的互联互通问题尝试通过统一的数据中台实现跨系统的数据共享与业务协同。总体而言国外在技术创新与理论研究方面具有较强的深度和广度而国内则在应用场景与实践推广上取得了显著进展。两者共同推动了基于移动终端的活动管理系统向高效、精准、可持续方向发展。四、预期达到目标及解决的关键问题预期目标首先是实现一套完整的校园活动报名与签到系统系统应支持学生通过微信小程序快速完成报名、查看活动详情、生成个人二维码并在现场扫码签到教师与管理员可在后台实时获取报名数据、签到统计以及异常报告并能对活动进行审批与管理。其次系统需具备高并发处理能力在活动报名高峰期仍保持响应时间低于 200 毫秒保证用户体验同时数据安全与隐私保护是关键目标之一系统应采用 HTTPS 加密传输、数据库加密存储以及细粒度权限控制确保学生个人信息不被泄露。再者为提升管理效率与决策支持系统需提供可视化统计报表包括报名人数、签到率、时间分布等指标并支持导出 CSV 或 Excel 格式供后续分析使用。最后系统设计应具备良好的可扩展性与模块化可在未来通过插件或微服务形式添加新功能如活动日程管理、奖惩机制、社团管理等以适应高校信息化发展需求。关键问题主要集中在技术实现与业务流程三方面。技术层面如何在 SpringBoot 微服务架构下实现高并发的报名与签到请求处理是核心挑战需要合理设计数据库表结构、索引策略以及缓存机制同时微信小程序端与后端接口的安全对接、身份认证与授权流程的实现也需细致考量。业务流程层面如何在不影响学生使用体验的前提下实现多角色权限管理学生、教师、管理员以及审批流的自动化是系统设计的重要难点此外现场签到过程中的二维码生成与校验、异常情况如重复签到、未报名签到的处理机制亦需完善。最后系统在实际部署后可能面临校园网络环境不稳定、设备兼容性差异等外部因素需要通过容错设计与监控告警来保障系统的稳定运行。五、研究内容本研究的整体内容围绕基于SpringBoot框架与微信小程序技术的校园活动报名与签到系统的设计、实现与评估展开主要分为需求分析、系统架构设计、关键技术实现、功能模块开发以及系统验证与优化五个阶段。首先在需求分析阶段将通过访谈、问卷及案例研究等方法收集高校学生、教师及行政人员在活动报名与签到过程中的痛点与期望形成功能需求清单和非功能需求规范随后在系统架构设计阶段采用微服务化设计理念将后端拆分为用户管理服务、活动管理服务、报名服务、签到服务及统计分析服务等模块并通过SpringCloud实现服务治理与负载均衡前端则采用微信小程序框架利用其原生组件实现报名表单、活动列表与二维码生成等功能并通过统一身份认证接口完成单点登录。其次在关键技术实现阶段将重点解决高并发请求处理、数据一致性保障与安全加密等技术难题具体措施包括使用Redis缓存热点数据、采用分布式事务管理保证报名与签到操作的原子性、以及在传输层与存储层分别实施TLS加密与字段级加密。随后在功能模块开发阶段按照模块划分实现用户注册与角色授权、活动发布与审批流程、报名信息录入与校验、二维码生成与现场扫码验证、签到状态实时更新以及统计报表生成等功能每个模块均配备单元测试和集成测试用例确保代码质量。最后在系统验证与优化阶段将在真实校园环境中部署系统收集关键性能指标如响应时间、并发处理能力、错误率及用户满意度数据通过A/B测试或灰度发布方式对功能进行迭代改进同时对系统日志进行分析识别潜在瓶颈并进行性能调优。整个研究过程将遵循敏捷开发与持续集成的实践确保系统能够快速响应高校活动管理需求并具备可扩展、易维护的特性。六、需求分析用户需求方面系统的主要使用者包括学生、教师与行政管理人员。学生侧重于报名流程的简洁性与实时性期望能够在微信小程序内快速浏览校园活动列表、查看活动详情并完成报名表单填写同时希望系统能够及时推送活动变更通知与签到提醒并通过生成二维码实现现场扫码签到避免现场排队等待。教师作为活动主办方或审批者需要在后台对新发布的活动进行审核与发布能够对报名人数进行预估与调整并在活动现场通过扫码确认学生身份从而确保参与者符合活动要求。行政管理人员则关注整体运营效率与数据透明度期望能够在后台获取报名与签到的实时统计报表、异常情况报警以及历史数据分析以支持后续资源分配与活动策划。除此之外所有用户均需要在系统中获得统一的身份认证体验避免多账号登录导致信息混乱并且对个人信息安全与隐私保护有较高要求。功能需求方面系统需实现完整的用户身份管理模块包括注册、登录、角色分配与权限控制在活动管理模块中教师与管理员能够创建、编辑、发布活动并设置报名截止时间、签到窗口以及参与人数上限报名模块需支持学生填写报名表单并提交系统自动校验必填项与数据格式同时记录报名时间戳二维码生成与扫码签到模块必须能够为每位已报名学生生成唯一二维码并在现场通过微信小程序扫码验证身份实时更新签到状态签到统计模块需聚合签到人数、迟到率、缺席率等指标并支持按时间段、活动类型或班级维度进行筛选报告与分析模块应提供可视化图表展示报名与签到趋势并支持导出 CSV 或 Excel 文件供后续分析使用安全与性能模块需实现 HTTPS 加密传输、数据库字段加密、Redis 缓存热点数据以及分布式事务管理以保证系统在高并发场景下的稳定性与数据一致性。以上功能模块通过微服务架构进行拆分前端采用微信小程序实现交互界面后端基于 SpringBoot 提供 RESTful API形成完整的技术闭环。七、可行性分析经济可行性方面系统的开发成本主要由后端微服务架构、前端小程序实现、数据库与缓存部署以及安全加密等技术实现组成预计初期投入约为人民币十万元至十五万元其中包括软件许可、服务器租赁与人工成本随后维护费用将主要涉及服务器运维、系统升级与技术支持年均成本预计为总投入的 10% 至 15%从效益角度看系统能够替代传统纸质报名表和人工签到流程显著降低纸张与打印成本、减少人力资源消耗并通过实时数据统计提升活动组织效率预计每年可为高校节约人力成本约五万元至八万元此外系统的可视化报表功能将为管理层提供决策支持进一步优化资源配置长期来看具备良好的投资回报率。社会可行性方面学生群体对微信小程序的使用习惯已十分普及系统通过一键报名与扫码签到降低了操作门槛符合学生“移动化、即时化”的使用需求教师与行政人员在审批与统计环节将获得更高的工作效率和数据透明度提升管理满意度此外系统的安全加密与隐私保护措施符合教育部门对个人信息保护的法规要求能够获得师生与家长的信任从校园文化角度看该系统能够鼓励学生积极参与各类活动丰富校园生活增强归属感。技术可行性方面SpringBoot 与 SpringCloud 生态已成熟稳定可快速构建微服务架构并支持容器化部署微信小程序平台提供完善的 SDK 与 API支持二维码生成、扫码验证以及统一身份认证数据库层可采用 MySQL 或 PostgreSQL 结合 Redis 缓存满足高并发读写需求安全层面可利用 HTTPS、JWT 以及字段级加密技术确保数据传输与存储的安全在硬件与网络环境方面高校校园网及云服务器已具备足够的带宽与计算资源能够支持系统的部署与运行。综上所述该项目在经济、社会与技术三方面均具备可行性能够为高校活动管理提供高效、可靠且易于推广的解决方案。八、功能分析系统功能模块的设计依据需求分析结果逻辑上可划分为用户管理模块、活动管理模块、报名与信息校验模块、二维码生成与签到验证模块、统计与报表生成模块以及通知与安全控制模块。用户管理模块负责实现学生、教师及行政人员的注册、登录以及角色分配功能系统通过微信小程序的授权登录接口获取用户身份信息并在后端数据库中维护用户基本资料与权限等级该模块还需提供密码重置与账号绑定等辅助功能以保证账户安全。活动管理模块主要服务于教师与管理员支持活动的创建、编辑、发布及下架操作管理员可对活动进行审核并设置报名截止时间、签到窗口以及参与人数上限系统通过后台接口将活动信息同步至前端小程序供学生浏览与筛选。报名与信息校验模块为学生提供报名表单填写入口系统在提交时自动校验必填字段与数据格式并记录报名时间戳若出现重复报名或已过截止时间的请求系统将返回相应错误提示。二维码生成与签到验证模块负责为每位已报名学生生成唯一二维码并在现场通过微信小程序扫码接口完成身份验证系统实时更新签到状态并记录签到时间该模块需支持离线缓存与网络异常重试机制以确保现场扫码的稳定性。统计与报表生成模块聚合报名与签到数据提供可视化图表展示报名人数、签到率、迟到率等关键指标并支持按时间段、活动类型或班级维度进行筛选管理员可将报表导出为 CSV 或 Excel 格式以供后续分析。通知与安全控制模块负责系统内部的消息推送与安全管理利用微信小程序的消息接口向用户推送活动变更、签到提醒及异常报警同时该模块实现 HTTPS 加密传输、JWT 认证以及数据库字段级加密保障数据在传输与存储过程中的安全。上述各模块通过 RESTful API 进行交互后端采用 SpringBoot 微服务架构实现业务逻辑分层前端小程序使用原生组件完成用户界面展示与交互从而构成完整、可维护且易于扩展的校园活动报名与签到系统。九、数据库设计表名Users字段名 | 说明 | 大小 | 类型 | 主外键 | 备注user_id | 用户主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成或业务唯一标识openid | 微信开放平台用户唯一标识符 | 50 | VARCHAR(50) | 唯一索引| 与微信小程序关联nickname | 微信昵称 | 50 | VARCHAR(50) | | 用户在小程序中的显示名称avatar_url | 头像链接地址 | 200 | VARCHAR(200) | | 存储用户头像的 URLgender | 性别0 未知1 男2 女 | 1 | TINYINT(1) | | 性别信息country | 国家代码ISO | 10 | VARCHAR(10) | | 用户所在国家province | 省份/地区名称 | 50 | VARCHAR(50) | | 用户所在省份city | 城市名称 | 50 | VARCHAR(50) | | 用户所在城市表名Roles字段名 | 说明 | 大小 | 类型 | 主外键 | 备注role_id | 角色主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成或业务唯一标识role_name | 角色名称如学生、教师、管理员 | 30 | VARCHAR(30) | | 唯一索引表名UserRoles字段名 | 说明 | 大小 | 类型 | 主外键 | 备注user_role_id | 用户角色关联主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成user_id | 用户标识符外键 | 20 | VARCHAR(20) | 外键FK→Users.user_id| 关联用户表role_id | 角色标识符外键 | 20 | VARCHAR(20) | 外键FK→Roles.role_id| 关联角色表表名Activities字段名 | 说明 | 大小 | 类型 | 主外键 | 备注activity_id | 活动主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成或业务唯一标识title | 活动标题 | 100 | VARCHAR(100) | | 活动名称description | 活动简介/详细说明 | 500 | TEXT | | 活动内容描述start_time | 开始时间戳UNIX 时间 | 20 | BIGINT(20) | | 活动开始时间end_time | 结束时间戳UNIX 时间 | 20 | BIGINT(20) | | 活动结束时间location | 举办地点描述 | 200 | VARCHAR(200) | | 活动地点capacity | 容纳人数上限 | 10 | INT(10) UNSIGNED | | 最大报名人数created_by | 创建者用户标识符外键 | 20 | VARCHAR(20) | 外键FK→Users.user_id| 发起人status | 活动状态0 待审核1 已发布2 已结束3 已取消 | 1 | TINYINT(1) | | 活动当前状态表名Registrations字段名 | 说明 | 大小 | 类型 | 主外键 | 备注registration_id | 报名主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成或业务唯一标识user_id | 报名用户标识符外键 | 20 | VARCHAR(20) | 外键FK→Users.user_id| 关联用户表activity_id | 报名对应活动标识符外键 | 20 | VARCHAR(20) | 外键FK→Activities.activity_id| 关联活动表status | 报名状态0 已报名1 已确认2 已取消 | 1 | TINYINT(1) | | 当前报名状态created_at | 报名时间戳UNIX 时间 | 20 | BIGINT(20) | | 报名创建时间表名SignIns字段名 | 说明 | 大小 | 类型 | 主外键 | 备注sign_in_id | 签到主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成或业务唯一标识registration_id | 对应报名记录标识符外键 | 20 | VARCHAR(20) | 外键FK→Registrations.registration_id| 关联报名表sign_in_time | 签到时间戳UNIX 时间 | 20 | BIGINT(20) | | 实际签到时间表名Notifications字段名 | 说明 | 大小 | 类型 | 主外键 | 备注notification_id | 通知主键标识符 | 20 | VARCHAR(20) | 主键PK| 自动生成或业务唯一标识user_id | 接收者用户标识符外键 | 20 | VARCHAR(20) | 外键FK→Users.user_id| 关联用户表activity_id | 与通知相关的活动标识符可为空 | 20 | VARCHAR(20) | 外键FK→Activities.activity_id| 关联活动表title | 通知标题 | 100 | VARCHAR(100) | | 通知主题content | 通知内容 | 500 | TEXT | | 通知正文created_at | 创建时间戳UNIX 时间 | 20 | BIGINT(20) | | 通知生成时间status | 阅读状态0 未读1 已读 | 1 | TINYINT(1) | | 是否已阅读上述表结构遵循第一范式至第三范式避免数据冗余并保证数据一致性。每个表的主键均为唯一标识符外键通过约束实现表间关联字段类型与大小根据实际业务需求进行合理设定。十、建表语句CREATE DATABASE IF NOT EXISTS campus_activity CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;USE campus_activity;-- 用户表CREATE TABLE Users (user_id VARCHAR(20) NOT NULL,openid VARCHAR(50) NOT NULL,nickname VARCHAR(50),avatar_url VARCHAR(200),gender TINYINT(1) DEFAULT 0,country VARCHAR(10),province VARCHAR(50),city VARCHAR(50),PRIMARY KEY (user_id),UNIQUE KEY uk_openid (openid)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 角色表CREATE TABLE Roles (role_id VARCHAR(20) NOT NULL,role_name VARCHAR(30) NOT NULL,PRIMARY KEY (role_id),UNIQUE KEY uk_role_name (role_name)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 用户角色关联表CREATE TABLE UserRoles (user_role_id VARCHAR(20) NOT NULL,user_id VARCHAR(20) NOT NULL,role_id VARCHAR(20) NOT NULL,PRIMARY KEY (user_role_id),KEY idx_user (user_id),KEY idx_role (role_id),CONSTRAINT fk_ur_user FOREIGN KEY (user_id) REFERENCES Users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_ur_role FOREIGN KEY (role_id) REFERENCES Roles(role_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 活动表CREATE TABLE Activities (activity_id VARCHAR(20) NOT NULL,title VARCHAR(100) NOT NULL,description TEXT,start_time BIGINT(20) NOT NULL,end_time BIGINT(20) NOT NULL,location VARCHAR(200),capacity INT UNSIGNED DEFAULT 0,created_by VARCHAR(20) NOT NULL,status TINYINT(1) DEFAULT 0,PRIMARY KEY (activity_id),KEY idx_created_by (created_by),CONSTRAINT fk_act_creator FOREIGN KEY (created_by) REFERENCES Users(user_id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 报名表CREATE TABLE Registrations (registration_id VARCHAR(20) NOT NULL,user_id VARCHAR(20) NOT NULL,activity_id VARCHAR(20) NOT NULL,status TINYINT(1) DEFAULT 0,created_at BIGINT(20) NOT NULL,PRIMARY KEY (registration_id),KEY idx_reg_user (user_id),KEY idx_reg_act (activity_id),CONSTRAINT fk_reg_user FOREIGN KEY (user_id) REFERENCES Users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_reg_act FOREIGN KEY (activity_id) REFERENCES Activities(activity_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 签到表CREATE TABLE SignIns (sign_in_id VARCHAR(20) NOT NULL,registration_id VARCHAR(20) NOT NULL,sign_in_time BIGINT(20) NOT NULL,PRIMARY KEY (sign_in_id),KEY idx_si_reg (registration_id),CONSTRAINT fk_si_reg FOREIGN KEY (registration_id) REFERENCES Registrations(registration_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 通知表CREATE TABLE Notifications (notification_id VARCHAR(20) NOT NULL,user_id VARCHAR(20) NOT NULL,activity_id VARCHAR(20),title VARCHAR(100) NOT NULL,content TEXT,created_at BIGINT(20) NOT NULL,status TINYINT(1) DEFAULT 0,PRIMARY KEY (notification_id),KEY idx_not_user (user_id),KEY idx_not_act (activity_id),CONSTRAINT fk_not_user FOREIGN KEY (user_id) REFERENCES Users(user_id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_not_act FOREIGN KEY (activity_id) REFERENCES Activities(activity_id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方获取联系方式
返回列表