简介一份基于Java与MySQL的农场管理系统毕业设计论文适合计算机相关专业毕业生及需要完成类似选题的开发者。内容针对传统农场管理中信息混乱、出错率高、安全性差等问题给出了完整的设计与实现方案。全包共1个文件为DOC格式论文文档大小1.49MB便于直接阅读、编辑和打印。已有185人学习适合用作论文撰写参考或毕设答辩准备。论文覆盖课题背景、开发环境、可行性分析、功能模块设计等核心章节其中农场信息管理、作物管理、生产记录管理、员工管理、安全管理等模块均有详细说明同时涉及Java、MySQL、Spring Boot、微信小程序等技术并包含B/S架构设计、数据库设计、安全策略与系统测试内容。读者可据此快速搭建同类管理系统论文框架也可借鉴其需求分析、表结构规划及测试思路节省从零开始梳理的时间。1. 农场管理系统小程序论文题目背后从“4.19”到可运行系统的三件套农场管理系统小程序这个题目在课程设计和毕业设计清单里出现频率很高文档名里的“4.19”多半是文件名里的日期或第几版修订号真正值钱的是后半句——你要交付的不只是一篇论文.doc而是一套能当场扫码演示的小程序外加支撑它的后端接口和数据库。这类题目的本质是三层东西农场业务建模、管理系统功能设计、微信小程序载体实现。论文文字只是把这三件事讲清楚的容器答辩老师翻开文档之前先看的是你的演示能不能跑通。所以这篇笔记我按三件套来讲先定架构再设计数据表和接口最后落到小程序端和论文材料的准备上适合正在写这篇论文的学生也适合接了类似“基于微信小程序的XX系统”单子的开发者直接照着搭。2. 选题与架构先行为什么农场管理系统小程序比Web端更好答辩2.1 小程序端与Web端的差异部署、演示和考核点做管理系统很多人的第一反应是Web端Vue加Spring Boot浏览器打开就能用。但放在农场管理这个场景里小程序有明显优势。农场的管理者不是在电脑前办公的是在大棚、田埂和仓库之间走动的人手机端操作符合实际使用习惯论文里写需求分析时场景描述比Web端更站得住脚。答辩演示更直接老师微信扫码就能打开体验版不用打开浏览器输地址、等服务启动。Web端演示翻车的常见原因是环境依赖本机IP变了、数据库没启动、端口被占用演示现场一片混乱。小程序的体验版二维码是死的只要后端服务还挂着扫码即用。这里有个隐藏坑开发版小程序的二维码默认有效期较短过期后需要重新在开发者工具里预览生成。出现过“开发版小程序已过期请在开发者工具重新扫码”的提示答辩前必须提前一天重新生成二维码不然现场就冷场了。另外从考核角度看小程序端的项目在结构上多了一层“微信公众平台”的配置环节小程序后台、AppID、服务器域名白名单都是可以写进论文测试章节的素材比Web端凭空多出两页可写内容。对需要凑字数、凑图表的学生来说这不是坏事。2.2 选uni-app还是原生微信小程序团队技能与论文篇幅的权衡技术选型是论文开题部分就要定的中途换框架的成本很大。常见做法是在原生微信小程序和uni-app之间选。原生就是微信开发者工具里写WXML、WXSS、JSuni-app是Vue语法编译到多端一套代码可以出微信小程序、App、H5。这两条路各有适用场景需要按论文和项目规模来权衡。对比维度原生微信小程序uni-app上手门槛需学WXML和WXSS语法会Vue就能写多端复用只出微信小程序可编译到App、H5、鸿蒙等代码结构与调试简单直观报错定位快编译链路长问题需要在编译产物里排查论文素材官方文档多截图丰富可以同时写多端适配但容易写偏踩坑生态问题在社区基本都能搜到依赖框架版本部分问题无解如果论文题目明确写了“基于微信小程序”我建议用原生。理由很实际原生开发遇到的报错开发者社区里几乎都有现成答案你卡住时能搜到解决方案uni-app虽然写起来舒服但编译后报错会绕一层而且多端适配的内容一旦写进论文答辩老师追问“你是怎么处理iOS和安卓差异的”你没有实际测过就会答得很虚。如果是接外包、要同时交付Android和iOS包再考虑uni-app。论文项目不需要多端原生就够了。2.3 三层架构与论文章节映射把技术栈变成答辩材料农场管理系统小程序的经典落地架构是三层前端微信小程序、后端Java Spring Boot、数据库MySQL。选Spring Boot不是因为它性能多好而是Java后端实现微信小程序登录的链路最成熟网上资料最多答辩老师也最熟悉这套技术栈你遇到的问题他基本都能预判。建议的技术栈分配小程序端负责页面展示和交互后端提供RESTful接口MySQL存业务数据。这三层正好映射论文的三大章节。需求分析章节写用例图角色是农户、农场管理员、操作员概要设计章节放系统架构图前端、后端、数据库三层连线详细设计章节放接口文档和时序图重点画wx.login登录时序图数据库设计章节放ER图和建表SQL。我见过不少论文翻车翻车点不是代码写不出来而是论文章节和技术实现对不上。比如详细设计里写了“本系统采用JWT进行身份认证”代码里却只用了openid直接查表没有签发token答辩老师细看代码一眼就能发现。所以架构选型要和自己实际写出来的代码一致宁可写得简单不要写得花哨但没实现。3. 数据模型与后端接口农场最小闭环的字段设计与登录方案3.1 先理业务闭环地块、作物、任务与农资记录写代码之前要先想清楚农场管理这个系统的业务闭环否则建表会漏字段。一个最小可用的农场管理系统核心是四个环节农场里有什么地块每个地块种了什么作物这些作物需要做哪些农事任务任务完成后产生了哪些农资消耗和产量记录。这个闭环对应到数据表上就是地块表、作物批次表、农事任务表、农资流水表。论文里需求分析部分会画用例图这个用例图不要画得太大围绕这四张表画就够。农户或管理员登录后可以维护地块信息、查看作物批次、创建农事任务、登记农资出入库这就是一套能用的话术。做农产品销售模块也是热门的扩展点但先不要急着加商城订单系统会牵扯库存和支付复杂度翻倍。先把种植管理闭环跑通论文结构已经很完整。数据表之间用逻辑外键关联不要用数据库物理外键。物理外键在删除和统计时容易踩坑比如删除一个地块时如果它名下还有作物批次物理外键会直接报错阻止删除逻辑外键只需在业务代码里判断灵活得多论文里也可以多写一段“采用逻辑外键设计”的说明。3.2 用SQL设计最小表结构地块、作物批次与农事任务以地块表、作物批次表、农事任务表为例给出一个能直接跑在建库脚本里的最小设计。注意字段命名统一用下划线风格时间字段统一为datetime状态字段用tinyint预留deleted字段做软删除。CREATE TABLE plot ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 地块ID, plot_name VARCHAR(50) NOT NULL COMMENT 地块名称如1号大棚, area DECIMAL(10, 2) DEFAULT 0 COMMENT 面积亩, soil_type VARCHAR(20) DEFAULT COMMENT 土壤类型如沙土/黏土, location VARCHAR(100) DEFAULT COMMENT 地块位置描述, status TINYINT DEFAULT 1 COMMENT 1正常 0停用, deleted TINYINT DEFAULT 0 COMMENT 软删除标记, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT 农场地块表; CREATE TABLE crop_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 批次ID, plot_id BIGINT NOT NULL COMMENT 关联地块ID, crop_name VARCHAR(50) NOT NULL COMMENT 作物名称如番茄, variety VARCHAR(50) DEFAULT COMMENT 品种, planted_date DATE NOT NULL COMMENT 定植日期, expected_harvest DATE DEFAULT NULL COMMENT 预计采收日期, status TINYINT DEFAULT 1 COMMENT 1种植中 2已收获, deleted TINYINT DEFAULT 0 ) COMMENT 作物批次表; CREATE TABLE farm_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 任务ID, batch_id BIGINT NOT NULL COMMENT 关联批次ID, task_type VARCHAR(20) NOT NULL COMMENT 任务类型浇水/施肥/打药/除草, task_name VARCHAR(50) NOT NULL COMMENT 任务名称, assignee VARCHAR(20) DEFAULT COMMENT 负责人, plan_time DATETIME NOT NULL COMMENT 计划执行时间, finish_time DATETIME DEFAULT NULL COMMENT 实际完成时间, status TINYINT DEFAULT 0 COMMENT 0待执行 1已完成 2已逾期, remark VARCHAR(200) DEFAULT COMMENT 备注 ) COMMENT 农事任务表;表设计的几个关键点status字段用tinyint不用varchar因为代码里判断状态时数字比字符串更高效也不容易因大小写不一致产生bugplanted_date用date类型因为只需要精确到天plan_time用datetime因为任务需要精确到时刻deleted字段是给“删错数据后悔药”用的删除操作只更新deleted为1查询时统一加where deleted 0条件论文里可以解释为“保留历史审计轨迹”。一个容易忽略的设计是task_type用字符串而不用数字枚举。农事任务的类型将来必然要扩展用数字枚举每加一种都要写映射字符串在代码里可读性高前端拿到直接显示省一层翻译。代价是存储空间略大但这个量级完全无所谓。3.3 登录换openidjscode2session与JWT token的全链路小程序登录和后端Session登录不一样小程序没有密码输入框登录靠微信的openid。前端调用wx.login获取一个临时code后端拿着code去微信的jscode2session接口换openid和session_key再用openid作为用户唯一标识签发自己的token。这里最容易被忽视的点是微信返回的session_key绝对不能返回给前端它涉及用户微信数据的解密只该留存在后端。RestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginRequest req) { // 1. 用前端传来的code换openid String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code req.getCode() grant_typeauthorization_code; String resp HttpUtil.get(url); JSONObject json JSONObject.parseObject(resp); if (json.getString(openid) null) { return Result.error(code无效或已过期); } String openid json.getString(openid); // 2. 查库或注册新用户 User user userService.findOrCreateByOpenid(openid); // 3. 签发JWT有效期7天 String token JwtUtil.createToken(user.getId(), 7 * 24 * 3600); return Result.ok(token); } }这个接口里三个参数最关键appid和secret从微信公众平台后台复制不要硬编码在代码里建议放application.yml并用环境变量覆盖避免代码上传到Git时泄露code是一次性的前端每次wx.login都会拿到新code后端不用缓存token有效期放7天太短会让用户频繁重新登录太长有安全风险。前端拿到token后存入wx.setStorageSync每次请求放进header的Authorization字段后端用一个拦截器统一校验。很多项目在这里会漏掉一个细节token刷新策略。7天有效期到了用户在田里干活打开小程序发现要重新登录体验很差。常见的做法是后端在token里加一个refresh_token或者前端在请求拦截器里遇到401就静默调用wx.login换新token对用户无感知。论文里如果能写清楚这个方案是一次加分。4. 小程序端落地用微信开发者工具跑通首页、任务与我的页面4.1 目录结构、app.json与三个Tab页面初始化新建一个微信小程序项目时模板选“JavaScript基础模板”就够了不用选云开发模板因为后端我们打算自己写。小程序端目录按功能划分pages下放四个目录index做首页仪表盘tasks做农事任务列表mine做用户中心再加上utils放公共工具。微信小程序源码也好、项目实例也好绝大多数都是这个套路论文里写“模块化目录结构”也有据可依。app.json是整个小程序的全局配置文件页面注册、tabBar导航、窗口样式都在这一个文件里配置。头部标题就是这里设置的navigationBarTitleText顶部导航栏的背景色和文字颜色也可以通过navigationBarBackgroundColor和navigationBarTextStyle调整。这两个参数是答辩演示时最容易出效果的地方把标题改成“XX农场管理系统”比默认的“微信小程序”看起来正规得多。{ pages: [ pages/index/index, pages/tasks/tasks, pages/mine/mine ], window: { navigationBarTitleText: 农场管理系统, navigationBarBackgroundColor: #07c160, navigationBarTextStyle: white, backgroundColor: #f5f5f5 }, tabBar: { color: #999999, selectedColor: #07c160, list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/tasks/tasks, text: 任务 }, { pagePath: pages/mine/mine, text: 我的 } ] } }tabBar的list数组有数量限制最少2个最多5个这里放三个正合适。注意tabBar的pagePath必须在pages数组里注册过否则编译直接报错。页面文件是四个一组js、wxml、wxss、json成对出现新建页面时右键选择“新建Page”会自动生成这四个文件不用手动建。每个页面的json文件里可以单独覆盖全局的window配置比如任务页想用自定义导航栏可以在页面json里设navigationStyle: custom但自定义导航栏要自己处理顶部状态栏高度新手不建议碰。4.2 request.js封装与列表渲染从登录态注入到wxml数据绑定小程序里发请求用wx.request但如果每个页面都写一遍wx.request代码会非常冗余。常见的做法是封装一个request.js工具统一处理baseURL、token注入和401跳转。下面是实际项目里常用的封装方式可以直接复制改参数。// utils/request.js const BASE_URL https://your-api.example.com function request(path, method, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: BASE_URL path, method: method || GET, data: data || {}, header: { Content-Type: application/json, Authorization: token ? Bearer token : }, success(res) { if (res.statusCode 401) { // token过期清掉本地缓存并跳回登录页 wx.removeStorageSync(token) wx.reLaunch({ url: /pages/login/login }) reject(res) return } if (res.statusCode 200 res.statusCode 300) { resolve(res.data) } else { wx.showToast({ title: res.data.message || 请求失败, icon: none }) reject(res) } }, fail(err) { wx.showToast({ title: 网络异常请检查后端服务, icon: none }) reject(err) } }) }) } module.exports { request, BASE_URL }封装的核心逻辑是三点token在每次请求前从storage里取有就放进Authorization头401统一处理后端token失效不用每个页面单独判断错误提示集中弹toast页面里只需要关心数据。注意BASE_URL在小程序后台配置request合法域名时要用https开发调试阶段可以先在开发者工具里勾选“不校验合法域名”这个勾选项的位置在右上角“详情→本地设置”里很多新手找不到。页面里调用这个封装代码会干净很多。以农事任务列表为例在tasks页面的onLoad里调request(/api/tasks, GET)拿到数据后setDatawxml里用wx:for循环渲染。有一个细节setData的数据量不宜过大如果一次拉几百条任务会造成页面卡顿所以列表接口一定做分页后端接口设计时就要带上page和pageSize参数。4.3 云开发与自建API怎么选论文深度差异在这微信官方现在主推云开发也就是不用自己买服务器直接在微信开发者工具里建云函数、用云数据库免鉴权调用。云开发的好处是快还有免费额度不用处理域名备案和服务器部署开发版小程序也能直接跑。但它有个对论文来说很要命的问题后端逻辑被拆散在云函数里你的论文里就没有数据库设计章节可写了。云开发用的数据库是JSON文档型不能用SQL写不了事务答辩老师如果习惯用MySQL的思路提问这套东西很难展开。自建API虽然前期工作量大要装MySQL、写Spring Boot接口、处理跨域和服务器部署但每一步都是论文的素材建表SQL贴进数据库设计章节接口代码贴进详细设计章节部署截图贴进系统测试章节。论文深度完全不一样。结论很明确图省事、只要能验收的项目用云开发想论文写得厚、能扛答辩追问用自建Spring Boot加MySQL。农场管理系统这个题目大多数学校都要求有数据库设计我建议自建。云开发可以作为扩展内容写在论文的“技术选型备选方案”里一句话带过“本系统也评估过微信云开发方案因事务支持和SQL查询能力受限最终采用自建后端”。4.4 论文截图要刻意准备状态栏、空列表、加载失败一张都不能少论文里测试章节需要大量截图很多学生只在开发环境里跑通页面就截图结果截出来全是成功态。答辩老师一眼就能看出这是开发期截图因为没有任何异常处理痕迹。真实感很强的截图要刻意造出来加载中超时截图Network里把网络调成Slow 3G截个loading转圈的图空列表截图把数据库清空再进页面显示“暂无数据”的占位图断网提示截图关掉后端服务再刷新页面截toast提示。按三个维度准备截图正常态每页一张这个容易异常态包括空数据、网络错误、登录失效三种每样一张权限态包括定位授权、手机号授权弹窗测试可以写“进入系统时弹出授权请求用户拒绝后功能降级”。这些截图贴在论文的“系统功能测试”表里每条用例配一张图这一章看起来就非常充实比贴十张成功页有说服力得多。截图时注意微信开发者工具的背景色、模拟机型的导航栏高度保持统一。5. 论文与实践脱节的5个高频坑真机白屏、登录失效与模拟数据翻车5.1 真机白屏但开发者工具正常合法域名与IP地址的真相现象开发者工具里页面一切正常点击预览用手机扫码打开页面空白或请求全部失败。原因几乎都是同一个小程序的request域名白名单校验。开发者工具里勾选了“不校验合法域名”开发环境能跑通但真机预览时微信会强制校验https和域名备案。开发阶段后端跑在局域网IP加8080端口这个地址在真机上根本不在白名单里。解决方案分两步。开发调试阶段可以在开发者工具里勾选“不校验合法域名”但真机预览默认仍会校验需要把真机调试的“开发调试”开关打开。要发布体验版或正式版必须准备一个已备案的https域名后端接口全部绑到这个域名上。有人问“家里电脑当服务器可以部署小程序吗”可以但正式版小程序对域名有备案和https要求家里服务器要能做端口映射常见做法是用frp把内网服务端口映射到有公网IP的云服务器上。这个方案能跑通但受家庭宽带公网IP限制和运营商策略影响不稳定只适合临时演示。后端服务的跨域头也要一并处理。Spring Boot里加一个CorsFilter允许所有来源访问不然前端请求能到后端但响应被浏览器拦截页面照样拿不到数据。这个坑藏在网络调试里看不出来报错往往只在控制台里闪一下。5.2 隔天打开就要重新登录token过期与401自动刷新现象开发时登录一次能玩一整天第二天打开小程序又回到登录页感觉像是登录态没记住。原因是token过期时间太短。很多教程里的JWT示例代码默认过期时间是30分钟或1小时这是给演示用的不是给实际系统用的。农场管理系统的用户使用频率不高一天可能只打开两三次token有效期建议设7天以上配合后端定时续期。更完善的方案是双token一个access_token有效期2小时一个refresh_token有效期30天。前端请求遇401时自动用refresh_token去换新access_token换完重放原请求全程用户无感。这个机制论文里写清楚能体现水平。但实现时要注意并发场景多个请求同时401会触发多次刷新需要定义一个pending队列只在refreshing状态为false时发起刷新。另外一个跟时间相关的坑微信开发者工具和真机的时间不统一如果后端在签发token时校验了iat签发时间前端设备时间慢了5分钟token直接被判定为“尚未生效”。这个玄学问题排查了很久才定位到处理方式是后端签发和校验时统一用服务器时间不依赖前端时间头。5.3 iOS时间显示NaN日期字符串的格式玄学现象同一个列表页面安卓手机上显示“2024-04-19 10:30”iOS真机上显示“NaN-NaN-NaN”。原因是iOS的JavaScript引擎JavaScriptCore不支持用new Date(2024-04-19 10:30:00)这种方式解析带中划线的日期字符串安卓的V8引擎却能正常解析。这是小程序开发里非常经典的跨端坑查资料时能看到大量“iOS new Date返回NaN”的讨论。解决办法有两条路径。后端直接把时间格式化好再返回比如Java后端用LocalDateTime加上JsonFormat注解输出yyyy-MM-dd HH:mm:ss给前端前端只当字符串显示不做任何转换一劳永逸。如果前端必须做日期计算或相对时间显示比如“3小时前”则在解析时先把中划线替换成斜杠new Date(2024-04-19 10:30:00.replace(/-/g, /))。注意这两种方式选一种就行统一约定。5.4 商城模块被答辩老师追问支付虚拟支付的边界很多农场管理系统会加一个农产品商城模块这本身没问题但一旦涉及在线支付就会踩到微信小程序对虚拟支付限制的坑。特别是卖的是“会员卡”“课程”这类虚拟商品微信会直接封禁或限制支付能力IAP退款纠纷也是审核常见拒因。农场卖的是实体农产品走小程序内的微信支付是允许的但如果论文里只做了个演示没有真实的微信商户号支付回调流程写不完整答辩时容易被追到底。我一般建议的折中方案是论文里的商城模块只做到“提交订单”为止支付方式字段设计成“线下支付”和“货到付款”两种订单状态枚举为待确认、已确认、已完成、已取消。这样绕开了微信支付商户接入和回调处理流程完整答辩老师再问支付细节可以答“根据微信小程序平台的虚拟支付限制当前版本采用线下支付方案后续可接入微信支付”。诚实且有边界感比硬编一个假支付回调要好。5.5 测试数据全是手打的写一个data.sql把演示数据做成连续时序现象答辩现场演示时页面上只有零星几条数据而且时间全部集中在今天一看就是临时录入的。原因是开发期没有造数据脚本。一个农场管理系统界面上的数据应该是连续的、符合农时的。番茄的定植、浇水、施肥、采收记录应该覆盖三四个月产量统计也应该有每周的趋势这才像真实系统。做法是写一个data.sql插一批相对日期生成的数据。用DATE_SUB(NOW(), INTERVAL n DAY)来生成相对于当天的日期这样无论哪一天打开演示数据都在时间轴上有合理分布。比如倒推120天插一条番茄定植记录倒推60天插一条施肥记录倒推10天插一条采收记录。批量插入用MySQL的存储过程或者Java的CommandLineRunner在启动时执行都行。演示时前端按时间倒序展示页面就有了一个完整的种植周期不用临时编造。6. 验证与收尾技巧抓包确认接口、录演示视频和答辩前的最后一轮检查6.1 用开发者工具的Network面板和抓包工具确认请求链路页面跑通不等于接口没问题有时页面显示的数据是写死在代码里的静态假数据论文里却说调了后端接口答辩细究起来容易被揭穿。验证的方法是确认页面数据真的来自后端。微信开发者工具的Network面板就能看到每个请求的域名、状态码和耗时点开请求还能看返回体定位是不是数据真从MySQL查出来。真机环境下的接口验证可以用Burp Suite或Fiddler Everywhere这类抓包工具做HTTPS解密在PC端把微信小程序的流量解密出来看请求明文确认小程序在真实网络环境下的请求和返回跟开发者工具一致。抓包的关键是看三个地方请求头里的Authorization是否带上了token、返回的statusCode是否为200、响应体的字段名和前端代码里取值的是否一致。字段名不一致是常见翻车点后端返回cropName前端取的crop_name页面看起来正常是因为那是假数据真后端一接上就全白了。6.2 录一段3分钟的演示视频按用例图走一遍答辩现场不可控因素多网络突然抖动、投影仪接口不兼容都有可能发生。准备一条录屏演示视频是双保险视频放U盘里拷到答辩教室电脑上10秒钟就能播放不依赖现场网络和手机。视频内容不要按代码功能点讲要按业务场景走。建议分四段第一段扫码打开小程序展示首页看板读一遍核心数据第二段进入地块列表点开一个地块看种植批次第三段新建一个农事任务提交成功后在任务列表里看到新记录第四段到“我的”页面展示用户信息和退出登录。全程3分钟以内每段之间留2秒黑屏过渡方便老师知道场景切换。录制时把微信开发者工具的模拟器关掉用手机真机录录屏分辨率默认就行别开省电模式省电模式会降帧率导致画面卡顿。6.3 答辩前最后一轮检查清单检查项检查方法失败处理开发版二维码是否过期微信扫一扫预览重新在开发者工具生成预览二维码后端服务是否存活浏览器访问接口地址重启Spring Boot看控制台日志request合法域名是否配置小程序后台查看request域名开发阶段勾选不校验合法域名token有效期查看JWT配置改配置后重新打包预览时区是否统一对比服务器和本机时间后端统一用Asia/Shanghai时区演示数据是否还在进入页面看列表是否为空重新执行data.sql脚本这个清单是我每做一个这类项目交付前都会完整走一遍的。里面每一条都是真实踩过的坑特别是第一项。有一次我做过一个类似的课程设计项目答辩前一晚开发版二维码还是好的第二天早上老师扫码系统提示“开发版小程序已过期请在开发者工具重新扫码”我在地铁上没法开电脑结果现场等了快十分钟才连上热点重新签发。那次以后我的习惯是答辩当天早上出门前、到教室后各扫一次二维码确认能打开才坐下。希望帮到你。本文还有配套的精品资源点击获取