入口：①发现→小程序→搜索②下拉→小程序→搜索 主要的改变是：小程序折叠，展示3个，其它小程序要点击「更多」，而小程序页面收录结果作为主力展示 对内容资讯类小程序比较利好，而工具类小程序可以添加一些相关内容资讯，争取更多结果展示 大家可以搜索一下自己的试试 [图片][图片][图片]

今天各个关键词尝试了一下，特别是模糊搜索，结果多了很多，应该是全部恢复了，大家可以试一下，没有也不要灰心，官方应该在做了。 但是搜索结果内容跟26号以前没有大的改变，大的升级调整，特别是在「搜一搜」里面的展示据说要到11月份了！ [图片]

我们开发者调用微信小程序图片检测的接口，https://api.weixin.qq.com/wxa/img_sec_check?access_token=ACCESS_TOKEN 上传政治敏感图片以及涉黄图，都可以上传成功，后台返回的数据为“OK”，{"errcode":0,"errmsg":"ok"}。 请予以建议及指导！

无意中在小程序后台「微信搜一搜」发现这个，应该是即将到来的功能吧—— [图片] 「该功能开通后，小程序能够主动推送内容到微信搜一搜，推送并审核通过的内容能够被用户在微信搜一搜搜索到。」 什么意思呢？就是说以前是小程序页面被动被收录，即将可以主动发布内容出去，然后在「微信搜一搜」被搜到，是不是有点订阅号的赶脚？ 具体怎么用还不知道，拭目以待吧~ 贴一个我们的小程序「医启查」，大家可以查询医院和医生的执业注册信息，以及患者社区、健康科普，我们也给用户发放福利，积分可以免费报销医药费，或者兑换健康礼品，大家可以体验一下~ [图片]

1 产品说明1.1 产品开发背景1.1.1 产品背景根据《国务院关于开展城镇居民基本医疗保险试点的指导意见》有关精神，为进一步做好大学生医疗保障工作，国务院决定将大学生纳入城镇居民基本医疗保险试点范围。 但不同的是，城镇居民可以直接使用医疗保险卡在定点医院就医，个人不需要先支付再报销，直接便可由医保和医院结算该医保报销的部分，只有在结帐的时候，自付的部分由自己用医保卡余额或者现金支付。 而在大学生的医保报销流程中，参保大学生因病确需转诊的，其转诊后的门诊医疗费用先由患者个人垫付，转诊后凭转诊医院的医疗费用票据、门诊病历、检查检验报告单、门诊收费明细及校园卡等有效单据，到指定受理点进行报销，随后报销金额会直接通过银行卡支付给学生。材料琐碎，手续麻烦，给师生都造成了一定的不便。 1.1.2 当今现状目前，大学生在申请医疗保险报销时遇到了诸多问题。 1) 时间安排。各大高校的报销受理点，多为校医务处、学生事务中心等，处理人也通常局限在个位数。他们的工作时间不长，主要集中在工作日的上课时间段。所以想要申请医疗保险报销的学生不得不挤出时间来处理这一事物。 由于学生基数过大，每天需要进行报销的学生数量高居不下，而每一份病历的报销所需递交的材料过多，审核繁杂，且需要极大的耐心、细心与时间。对报销受理点的处理人是一个巨大的负担，而对申请报销的学生来说，排队等待便是家常便饭。 时常会出现不少前来申请医保报销的学生等待时间过长，而材料不齐全导致此次医保报销无法被受理。甚至出现了受理点到了下班时间，仍有不少学生的材料还未被受理。无故浪费了整段空闲时间，易让学生产生负面情绪，加大前来申请报销的学生与受理点的工作人员发生矛盾的概率。同时，过多的学生在受理点排队，各大高校的受理点通常较小，极容易互相拥挤，也是产生矛盾的一大诱因，十分不利于秩序的管理。 若是采用排队取号限流的方式，也十分不便。学生需要提前更多的时间为了取得一个号码。更可能有学生特地空出了整天的时间，却由于未能取到号码而无法进行报销，或取得了较为靠后的号码，加长了等待的时间。 2) 查询难。医保报销受理完毕后，倘若学生仍需要查看相关的记录，必须通过校园网链接或者登录学校的VPN，较为麻烦。 3) 记录难。对于受理点的工作人员来说，原系统无法直接生成所需提交给校财务部门及政府部门的数据，需要由人工重复处理，并进行提交。这样更容易出错，也更浪费时间。而医保报销系统涉及金额，且数目不小，一旦出现错误，后续处理较为麻烦。 大学生医疗保险报销的线上审核、预约、记录功能迫在眉睫。 1.2 产品开发意义在此背景下，我们团队制作了高校医保通这一微信小程序，将医保报销审核的主体挪移至线上完成。 （1）学生可以随时随地通过自己的校园账户登录该微信小程序，查看关于医保报销的各项通知，也可以根据提示上传所需进行医保报销的各项材料。待受理点的工作人员审核完毕后，学生会收到短信提示，可以及时上线根据要求修改、添加、删除发票或直接预约合适的时间前往受理点提交发票。 由于审核在线上完成，致使线下流程时间缩短，减少了学生排队等待的时长。同时，也减少了因为材料不齐全或错误，而使学生不得不多次前往受理点完成手续办理的可能。解决了受理点时间安排与学生时间安排相冲突的问题。 通过预约分流了同一时间前往受理点的学生人数，同样降低了学生排队等待的时间，提高了学生的体验。 （2）工作人员可以随时随地打开该微信小程序对发票进行审核，方便快捷，也可以查询已审核的发票记录。同时该微信小程序还提供了查询各受理时间预约人员信息的功能，方便出现问题后及时进行通知。 学生可以随时随地对自己的病历、发票、及获得金额进行查询。工作人员也可以在任意时间地点查询需要查看的发票，解决了查询难这一问题，避免用户受到地域限制。 （3）除该微信小程序以外，我们还为该项目制作了网页版的管理员端，方便受理点的工作人员在受理点工作时进行审核，收到学生提交的发票后及时核对信息。受理点需要向其学校的财务部门和政府部门提交统计信息时，也可以直接导出文件。网页版也能非常方便地发布新的通知、新的预约时间等。 解决了记录难这一问题，通过电脑导出，格式符合要求，也减少了人工完成时的错误。网页版的照片查看更为方便，审核更舒适，满足了工作人员提出的需求，提高了工作人员的体验。 微信小程序作为一个不需要下载安装即可使用的应用，方便用户查找与使用。作为一个应用，他使用户解放了时间与精力。 由于中小学及职员们的医保报销较为便捷，仅大学生医保报销出现了各项问题。很少有人能够意识到需要对这一项目进行完善，同时，由于独立开发成本略大，与其价值不相符，因而大部分高校仍在使用多年以前的产品，对于师生来说，体验都非常的差。但我们的高校医保通可以为各高校提供私人定制版本，给各高校提供了便利，也给我们团队提供了发展方向。 1.3 产品开发内容根据以上各项问题，及询问部分学生、工作人员的个人需求，我们团队构思了以下开发内容。 1.3.1 学生端用户（学生）可通过校园账号登录系统，由于关乎学生隐私，二次登录时需要指纹验证。 用户可以根据要求上传病历照片及其信息，发票照片及其信息以发起审核流程。用户还可以查看通知，病历、发票的审核进程，修改未被审核的发票、病历，也可以添加或删除发票，查看已完成医保报销的病历及其金额、被驳回的发票及其原因并及时进行修改。病历全被通过后，用户可以选择时间进行预约。 同时，该微信小程序还为用户提供了修改手机号，向客服咨询问题的功能。当发票出现问题或全部通过后，系统会自动向用户发送短信进行提醒。 1.3.2 管理员端管理员（受理点的工作人员）可以根据发票提交的先后顺序，对发票进行审核，可以修改医院名称，选择医院等级，修改发票号及各项金额，选择或填写驳回理由，驳回整份病历或单张发票，及是否将病历拉入黑名单（专家门诊不予报销）、是否允许用户修改错误发票（部分用户会提交非发票试图进行报销）。管理员也可以输入发票号、用户学号或用户姓名进行查询搜索，查看或审核发票，也可以选择预约的时间段，查看该段时间已预约的人员的信息。       2 需求分析2.1 设计原则和目标高校医保通微信小程序的设计主要追求实用性，对于目标群体：在高校指定医院完成就诊，提供有完整病例和发票的大学生与各高校医保报销受理点的工作人员进行开发。根据高等院校医保报销流程的特点进行设计与研究，使大学生能够通过小程序便捷地上传相关病例、发票和报销金额等内容，审核人员也可以快速查看相关资料，对目标大学生上传的资料提供通过、驳回等反馈。 该微信小程序深度涉及高校大学生的个人信息，因此该小程序和数据库的安全性、可靠性、数据完整性非常重要。系统在设计上遵循开放模式，预留有给管理员自定义报销比例等的相关接口，用户可以在网站的后台进行管理。 同时，该系统遵照软件工程的设计模式进行开发。在设计上遵循逻辑统一、文档规范、开发流程标准化的原则：做到软件逻辑一致的结构设计、标准统一的数据格式、规范统一的代码格式以及规范的文档。在用户界面设计、操作逻辑等方面能尽量统一，满足目标用户对于使用的需求。 该微信小程序在系统的设计上也采用了模块化的结构设计，在保证平台的整体使用不受影响的情况下也可以根据后期用户的需求增加相关的功能。 2.2 功能需求分析2.2.1 报销管理模块将繁琐冗长的线下报销流程置于线上进行，减少了大学生因为医保报销而频繁往返于受理点所浪费的时间和流程处理的等待时间。因申请报销的学生基数过大，每次报销所需上交的材料过多，该功能也减轻了报销受理点工作人员的负担，同时避免了部分因报销处理时间过长而导致的学生与受理点工作人员之间的矛盾。 学生部分：提供医院、病因、报销金额、发票号、就诊时间，上传需报销的图片资料；查看、修改或删除上传过的信息。详见表3-1，表3-2。 管理员部分：管理员可以审核病历、发票，查看已提交的发票信息。   表3-1 学生上传病历资料用例描述表 项目 内容说明 用例名称 学生上传病历资料 参与者 用户（学生） 前提条件 数据库中有学生购买医保的信息 前置操作 用户登录成功后，可选择进入报销界面 后置操作 用户跳转当前病历信息确认与发票上传界面 合法流程 用户确认个人信息后，提交病因、医院、就诊日期，上传病历照片 异常情况举例 数据库中没有用户购买医保的信息，上传失败 信息未填写完整或照片未上传，不允许进入下一步     表3-2 学生上传报销单的发票资料用例描述表 项目 内容说明 用例名称 学生上传报销单的发票资料 参与者 用户（学生） 前提条件 用户完成病历资料的上传 前置操作 用户完成上传病历资料，自动跳转 后置操作 上传下一张发票或选择完成上传 合法流程 用户输入发票号、发票金额、自费金额、上传发票图片 异常情况举例 自费金额大于发票金额，提示输入错误 信息未填写完整或照片未上传，不允许提交= 2.2.2预约管理模块仅将报销流程放置于线上依然会导致报销终审时（现场提交报销材料）的拥挤无法解决，因而小程序还添加了预约终审时间的功能。报销受理点的负责人可以自由地添加受理点的报销时间段，和每个时间段所允许的预约人数。而进入终审阶段的用户可以根据受理点所提供的时间段，安排好自己进行报销终审的时间，尽可能地降低了单个时间段前来办理医保报销的人次，弱化了拥挤和等待时间过长的问题。 学生可以预约线下报销日期，详见表3-3。         表3-3 学生预约提交报销材料用例描述表 项目 内容说明 用例名称 学生预约提交报销材料 参与者 用户（学生） 前提条件 用户提交的报销材料已通过审核 前置操作 用户成功登陆 后置操作 无 合法流程 用户点击预约，选择可预约日期、时间，提交预约信息 异常情况举例 当前场次人数预约已满，不允许预约 无审核通过的报销材料，不允许预约   2.3 非功能需求分析2.3.1 安全性和保密性由于医保报销牵涉到学生个人信息、学生看病信息以及报销金额等私密性数据，对数据在存储、传输等方面有较高的要求，这也是我们团队最终选择基于微信小程序进行开发的原因之一，所有请求仅支持https/wss协议，确保了数据在传输层次上的安全性，在数据存储层次，我们在涉及学生的敏感信息上进行了md5加密，确保了数据库被入侵，学生的敏感信息也不会外泄。 2.3.2 可靠性和体验性各环节有相应的提示信息，保证用户在第一次接触系统时也不会不知所措。对于用户是否输入数据，数据是否合法等做了相应检测，防止数据异常导致的报错，同时也对各种可能的异常进行了捕捉处理，系统健壮性强，能处理系统运行过程中出现的各种异常情况。       3 交互设计3.1 系统整体设计原则整体设计原则满足一般性原则，用户使用便捷，有必要的错误处理功能，图标简洁、抽象、使用得当，能起到很好的提示作用。大部分按钮具有点击前、点击后加载中、不能点击时等不同的状态，起到了良好的交互作用，考虑到微信小程序作为一个轻量级应用，减少了部分冗杂的状态。输入信息界面具有含义显眼的标题、有易于理解的指导性说明文字、按逻辑分组进行排序，倘若出现未填写或填写错误的情况会实时进行提示，同一界面所需填写内容较少，界面较为美观、清晰。 3.2 配色方案该微信小程序整体配色采用接近社会医疗保险卡的深蓝色，使用图片都带有医疗的元素，使用户一眼便能明白小程序的作用。其中，大部分提示性文字采用黑色，活动对象通常为接近图片颜色的#5499e4和#007aff这两种蓝色，少量警示性文字采用对比强烈的红色，使用户不会因为颜色数量过多而感到不适。 3.3 系统核心功能交互设计3.3.1 系统主要流程用户（学生）使用这一系统时（详见图3-1），首先进行登录，确认个人信息正确无误，上传病历信息及照片，而后分别上传该病历的多张发票信息及照片，确认完成上传。获得事务中心工作人员的审核结果，进行修改或等待医务处工作人员的审核结果，收到通知短信，修改或预约线下提交发票时间，收到预约短信提示。 [图片]   图3-1 系统流程时序图 3.3.2报销管理模块用户（学生）使用报销管理模块的发票上传部分时（详见图3-2），首先，加载未完成的报销信息，提交发票号、发票金额、就诊时间、发票照片等信息，待系统自动判定其正确、完整性后，可选择修改、上传下一张发票或完成提交，。 [图片] 图3-2 报销管理模块——发票上传部分时序图 3.3.3预约管理模块[图片] 用户（学生）使用预约管理模块时（详见图3-3），首先查询可供预约的日期、时间段，及其剩余人数，而后选择合适自己的时间。系统会自动判别该用户是都有已通过的病历。用户将获得预约结果及提示信息，并将会在预约日期的前一天收到提示短信。   图3-3 预约管理模块时序图 3.4 核心功能交互实现            主要流程及核心功能极好的体现了有必要的错误处理功能（部分见图3-4），图标能起到很好的提示作用（部分见图3-6）。按钮交互作用良好，输入信息界面易于理解（部分见图3-7），同一界面所需填写内容较少，界面较为美观、清晰。 [图片][图片] 整体配色采用接近社会医疗保险卡的深蓝色，颜色较少，使用户不会因为颜色数量过多而感到不适（部分见图3-6、图3-7）。              4 技术开发方案4.1 系统架构业务逻辑包含报销管理模块、预约管理模块、个人信息管理模块及权限管理模块，数据访问借由Sql Server数据库完成，将来我们将根据用户需求、系统反馈等及时进行版本更新优化性能，在操作系统方面我们同时支持了Android和iOS。 [图片] 图4-1 高校医保通微信小程序的系统架构图 4.2 业务逻辑架构4.2.1报销管理模块报销管理模块主要包含了用户上传病历、发票的相关信息及其照片，管理员根据病历进行发票审核的流程，是该微信小程序的核心业务。 4.2.2预约管理模块预约管理模块是用户前往现场提交发票环节前的一个必要环节，需要在系统中根据自己的时间安排，选择终审时间。受理点工作人员也可以自由地开放受理报销终审的时间及人数。 4.2.3个人信息管理模块个人信息管理模块是该微信小程序的基础业务，学生在进行报销流程之前，首先会确保个人信息的正确性，以防止报销过程中出现报销主体出错等情况。 4.2.4权限管理模块权限管理模块是系统的必要业务，不同的用户对于系统的操作权限是不同的，防止了部分未经授权的“非法用户”访问系统的所有功能。   4.3 数据库设计4.3.1逻辑模型设计系统数据库一共涉及到9张表分别是Insur, Notice, OrderList, OrderInfo, BlackList, CheckList,UserInfoSet, CaseListSet, LogListSet表。   4.3.2物理模型设计  表4-1 UserInfoSet用户表结构 名称 说明 数据类型 主键 外键 Id 自增主键 int TRUE FALSE UserName 用户学号 nvarchar(max) FALSE FALSE Name 用户姓名 nvarchar(max) FALSE FALSE Tel 用户手机号 nvarchar(max) FALSE FALSE Password 用户登录密码 nvarchar(max) FALSE FALSE Power 用户权限 smallint FALSE FALSE Class 用户班级 nvarchar(max) FALSE FALSE IdNum 用户身份证 nvarchar(max) FALSE FALSE Status 用户在校状态 nvarchar(max) FALSE FALSE OpenId 用户身份id nvarchar(max) FALSE FALSE     表题应写在表格上方正中，表序写在表题左方不加标点，空一格写表题，表题末尾不加标点，全文的表格统一编序，也可以逐章编序，表序必须连续 表4-2 Insur医保报销资格表结构 名称 说明 数据类型 主键 外来键 Id 自增主键 int TRUE FALSE UserName 用户学号 nvarchar(max) FALSE FALSE Year 购买保险年份 float FALSE FALSE     表4-3 Notice通知表结构 名称 说明 数据类型 主键 外键 Id 自增主键 int TRUE FALSE UserName 用户学号 nvarchar(max) FALSE FALSE Location 通知文件位置 nvarchar(max) FALSE FALSE Time 通知发布时间 datetime FALSE FALSE Valid 有效值 bit FALSE FALSE Power 通知权重 int FALSE FALSE     表题应写在表格上方正中，表序写在表题左方不加标点，空一格写表题，表题末尾不加标点，全文的表格统一编序，也可以逐章编序，表序必须连续 表4-4 BlackList黑名单表结构 名称 说明 数据类型 主键 外来键 Id 自增主键 int TRUE FALSE UserName 用户学号 nvarchar(max) FALSE FALSE BillNo 发票号 nvarchar(max) FALSE FALSE       表4-5 CaseListSet病历表结构 名称 说明 数据类型 主键 外键 CaseId 病历 int TRUE FALSE HosName 医院名 nvarchar(max) FALSE FALSE Reason 病因 nvarchar(max) FALSE FALSE HosDate 就诊日期 datetime FALSE FALSE ApplyDate 提交日期 datetime FALSE FALSE Succeed 状态值 smallint FALSE FALSE Valid 有效值 bit FALSE FALSE Level 医院等级 int FALSE FALSE UserInfoSet_Id 用户名 int FALSE TRUE ChangeValid 是否可修改 bit FALSE FALSE LastOpDate 修改时间 datetime FALSE FALSE FinalPay 最终报销金额 decimal(18) FALSE FALSE SubDate 现场确认时间 datetime FALSE FALSE     表4-6 CheckList审核日志表结构 名称 说明 数据类型 主键 外键 Id 自增主键 int TRUE FALSE Admin 管理员学号 nvarchar(max) FALSE FALSE LogId 发票外键 int FALSE TRUE Result 审核结果 int FALSE FALSE Level 审核级别 int FALSE FALSE CheckTime 审核时间 datetime FALSE FALSE     表4-7 LogListSet发票表结构 名称 说明 数据类型 主键 外键 LogId 发票外键 int TRUE FALSE BillNo 发票号 nvarchar(max) FALSE FALSE TotalPay 总金额 decimal(18) FALSE FALSE HosPay 医保金额 decimal(18) FALSE FALSE UserPay 自费金额 decimal(18) FALSE FALSE ErrorInfo 被驳回理由 nvarchar(max) FALSE FALSE Reject 审核状态值 smallint FALSE FALSE Location 发票照片位置 nvarchar(max) FALSE FALSE CaseListSet _CaseId 发票对应病历号 int FALSE TRUE ApplyDate 提交时间 datetime FALSE FALSE Valid 有效值 bit FALSE FALSE ChangeValid 是否可修改 bit FALSE FALSE LastOpDate 修改时间 datetime FALSE FALSE     表4-8 OrderInfo预约时间表结构 名称 说明 数据类型 主键 外键 Id 自增主键 int TRUE FALSE Date 预约日期 date FALSE FALSE StartTime 开始时间 datetime FALSE TRUE MaxNum 可预约人数 int FALSE FALSE NowNum 已预约人数 int FALSE FALSE EndTime 结束时间 datetime FALSE FALSE     表4-9 OrderList 预约详情表结构 名称 说明 数据类型 主键 外键 Id 自增主键 int TRUE FALSE OrderTime 预约日期 datetime FALSE FALSE Valid 有效值 bit FALSE FALSE UserInfoSet_Id 预约用户 int FALSE TRUE OrderInfo_Id 预约信息 int FALSE TRUE   4.5 性能优化因业务层次已基本满足市场需求，我们团队将基于此开发版本，根据用户需求、系统反馈等，对该微信小程序进行实时有效地更新。接下来我们团队也将对系统的响应时间、业务量、系统容量、安全性、可靠性、兼容性等几个方面做进一步的更新优化。 4.6 操作系统目前该系统支持iOS，Android两个主流的手机操作系统，在页面美观的兼容性上做了大量的处理，在业务层次上也同时满足两大操作系统的需求。 4.7 小程序开发基础设施前端开发语言：wxml + wxss + js 后端开发语言：C# 前端开发平台：微信开发者工具 + VSCode 后端开发平台：Microsoft Visual Studio 平台数据库：Microsoft Sql Server 2017       5 测试5.1黑盒测试5.1.1报销模块测试 表题应写在表格上方正中，表序写在表题左方不加标点，空一格写表题，表题末尾不加标点，全文的表格统一编序，也可以逐章编序，表序必须连续 表5-1 报销模块测试 序号 名称 说明 运行结果 测试结果 1 个人信息、图片显示 主页测试 显示正常 PASS 2 正常输入病因、医院并提交图片 创建报销单测试 提交正常 PASS 3 尝试通过病因框进行SQL注入 安全测试 注入失败 PASS 4 不上传图片即提交 完整性测试 提交失败 PASS 5 不上传信息即提交 完整性测试 提交失败 PASS 6 上传超大图片 负载测试 提交正常 PASS   5.1.2审核模块测试 表题应写在表格上方正中，表序写在表题左方不加标点，空一格写表题，表题末尾不加标点，全文的表格统一编序，也可以逐章编序，表序必须连续 表5-2 审核模块测试 序号 名称 说明 运行结果 测试结果 1 未审核发票的信息显示 主页测试 显示正常 PASS 2 输入正确的信息查询发票 功能测试 显示正常 PASS 3 输入不存在的信息查询 功能测试 显示空值 PASS 4 在查询框进行SQL注入 安全测试 注入失败 PASS 5 通过用户审核操作 功能测试 正确通过 PASS 6 不选择医院等级即通过发票 完整性测试 通过失败 PASS       6 系统上线与运维6.1 上线与部署现阶段我们团队已与上海第二工业大学学生处达成合作，该小程序将于2019学年下班学期正式上线运营，为上海第二工业大学数千名学生的医保报销提供便利，预计上线计划为： 2019年6月-2019年7月 小程序的测试与优化，提供初始产品给甲方，征求甲方对初稿的意见并进行修改。 2019年7月-2019年8月 与甲方敲定各项功能及细节，与甲方的受理点进行小范围的测试，及时修改并准备部署。 2019年8月-2019年9月 模拟环境进行部署，解决途中遇见的问题，准备上线。 2019年9月小程序部署完成，提供服务。 另，由于小程序的运行基于HTTPS协议，但我国大部分院校并没有合法的SSL证书部署，因而服务器的部署则成为了一个关键点。 6.2 运营与维护在与各大高校信息服务负责人接触的过程中，我们团队被频繁告知学生的个人信息与看病内容属于隐私，出于安全角度的考虑，该类数据不允许存放在除学校服务器以外的公共服务器内，故我们团队决定将该小程序的后台和数据库部署于各大高校自己的服务器中，采取高校学生与我们团队共同运营维护的模式。 由于服务部署于各大高校的内部服务器中，对于其学生而言，运维较为方便。在上线初期，我们团队将以每两天甚至每天一次的频率，检查数据库、小程序后台报错、IIS日志等，保证其能够正常运行。并助力培养高校学生，接触并维护独立工程项目的能力。因而，如果高校还有其他开发需求，可以选择自己解决，降低二次开发成本。倘若高校内部无法进行妥善的处理，也可以委托我们对其进行维护和二次开发。 例如，上线初期，由于用户非计算机专业人士，会有一些误操作，导致审核结果与实际不相符等情况，我们团队会及时进行数据库事务回滚并检查完整性。      因该小程序接下来将作为公司核心产品推向高校市场，所以产品的上线和运维方案便是接下来的重中之重。       特别鸣谢 蒋文蓉老师的技术开发指导。 于程程老师的文档写作指导。 许德镇老师的 校 方 支 持。