电梯智慧监管小程序实战：扫码巡检、维保工单与部署避坑

简介基于微信小程序打造的电梯智慧监管系统完整源码工程适合有Java后端和小程序开发基础的读者用于毕业设计、课程设计或实际项目参考。系统覆盖管理后台、接口服务与微信小程序端可对电梯维保、检验、检测、巡检等监管业务进行统一管理。压缩包共2436个文件约182.14MB主要包含Java后端源码与class文件、war包运行文件、小程序前端js/wxml/wxss、后台html页面、json配置、yml配置及mp4演示视频并按管理界面代码、后端代码、微信小程序代码、演示视频四类目录组织方便按模块索引。从内容预览可见包内包含后台控制类、服务实现类等Java分层代码体现Controller-Service-Impl的典型工程结构和数据统计展示逻辑。已有136人学习下载适合希望通读完整源码、理解电梯监管业务模块、掌握前后端协作流程和部署要点的读者。1. 电梯智慧监管小程序从扫码签到到工单闭环它到底解决什么基于微信小程序开发的电梯智慧监管系统解决的是电梯维保记录“纸面化、碎片化、难追溯”的老问题。巡检员扫一下电梯里的二维码小程序自动记录时间、定位和现场照片工单在系统里流转后台能查到每台电梯的维保历史和故障处置链路。物业设备科想摆脱Excel台账、维保公司想核实员工真实到岗、系统集成商想拿一套可二次开发的项目骨架这三类人都能在这个方向里找到自己想要的。整套系统其实不复杂但链路很长小程序扫码、图片上传、定位打卡、工单状态机、后台可视化任何一个环节的权限或配置问题都会把流程卡死。下面按数据模型、小程序端实现、后端接口落地、部署调试避坑的顺序把从源码和数据库跑通这套系统的关键步骤拆开讲最后补三个能让系统真正耐用的进阶改造。2. 把监管业务拆成数据模型电梯台账、维保工单与巡检流水怎么落库电梯智慧监管系统的数据模型是整套系统里最不起眼、但最不能错的部分。维保公司做二次开发时改得最多的往往不是页面而是表和字段。设计原则很简单把“电梯是谁的、什么时候该保养、保养了没有、谁来保养的、现场什么情况”这几个问题拆成表字段宁可多留一个也不要后期补迁移。2.1 电梯档案、维保计划、工单三张核心表的字段取舍第一张核心表是电梯档案它是全部业务的根。每台电梯一个二维码二维码里存的不应该是数据库自增id而是一个在整张表里唯一的业务编码。二维码一旦印刷贴出去就不好改了用业务编码的好处是后续换id、做数据迁移都不影响现场扫码。-- 电梯档案表 elevator一台电梯一条记录二维码内容即elevator_code CREATE TABLE elevator ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, elevator_code VARCHAR(32) NOT NULL UNIQUE COMMENT 二维码/业务编码全局唯一, device_no VARCHAR(64) DEFAULT NULL COMMENT 特种设备注册代码用于对接监管平台, address VARCHAR(255) NOT NULL COMMENT 电梯所在地址列表页直接展示, longitude DECIMAL(10,6) DEFAULT NULL COMMENT 梯位经度冗余自后台维护, latitude DECIMAL(10,6) DEFAULT NULL COMMENT 梯位纬度冗余自后台维护, property_company VARCHAR(128) DEFAULT NULL COMMENT 物业公司名称, manage_unit VARCHAR(128) DEFAULT NULL COMMENT 使用管理单位维保合同主体, next_inspect_date DATE DEFAULT NULL COMMENT 下次年检日期超期变红预警, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2检修中 3停梯, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段取舍上有几个经验点。elevator_code用32位字符串不用整数id是为了二维码的安全性和可替换性device_no独立存放因为特种设备注册代码在年检对接时才用得上没必要混在业务主键里。经纬度用DECIMAL(10,6)精度大约到米级足够定位展示别用FLOAT否则经纬度在列表展示时会多出一堆尾数。status用TINYINT而不是字符串方便以后扩展“4维保超期”这类状态不用改表结构。第二张表是维保计划它解决“什么时候该保养”的问题。电梯维保不是临时起意而是周期性的半月保、季度保、半年保、年度保。把计划独立成表让维保周期成为可配置参数而不是把“下次保养时间”写死在电梯表里。-- 维保计划表 maintain_plan一梯多条计划按周期自动滚动 CREATE TABLE maintain_plan ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, elevator_id INT UNSIGNED NOT NULL COMMENT 关联elevator.id, plan_type TINYINT NOT NULL COMMENT 1半月保 2季度保 3半年保 4年度保, executor VARCHAR(64) DEFAULT NULL COMMENT 默认维保负责人做任务分派时用, period_days SMALLINT UNSIGNED NOT NULL DEFAULT 15 COMMENT 周期天数半月保配15天, last_finish_time DATETIME DEFAULT NULL COMMENT 上次完成时间, next_plan_time DATETIME DEFAULT NULL COMMENT 下次计划时间列表页按它倒排, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待执行 1已完成 2已逾期, KEY idx_next_time (next_plan_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有一个容易被忽略的参数period_days。常见做法是在后端写死“半月保就是15天”但真实业务里法定维保周期按自然月/自然季度计算2月只有28天下次计划时间用DATE_ADD加15天并不完全准确。我习惯把period_days做成可配置后台管理员能在界面上调整维保计划生成时再按自然月做一次矫正。第三张表是工单表它是维保和维修的执行记录。工单表字段设计要同时满足两个人维保工在小程序里填单子监管后台按工单汇总统计。-- 工单表 work_order维保、维修、巡检、年检统一走工单 CREATE TABLE work_order ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务单号前端生成UUID后传入, elevator_id INT UNSIGNED NOT NULL COMMENT 关联电梯, plan_id INT UNSIGNED DEFAULT NULL COMMENT 关联维保计划维修单可为空, type TINYINT NOT NULL COMMENT 1维保 2维修 3巡检 4年检, desc_text VARCHAR(500) DEFAULT NULL COMMENT 故障描述或维保记录, photos VARCHAR(1000) DEFAULT NULL COMMENT 现场照片URL逗号分隔, longitude DECIMAL(10,6) DEFAULT NULL, latitude DECIMAL(10,6) DEFAULT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待接单 1执行中 2待验收 3已完成 4已取消, finish_time DATETIME DEFAULT NULL COMMENT 完成时间统计超时时长用, created_by INT UNSIGNED NOT NULL COMMENT 创建人用户ID, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_elevator_time (elevator_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;photos字段用逗号拼接URL不单独建图片子表这是刻意的取舍。一套监管系统里工单图片量不大一台电梯一个月最多几十张单表冗余足够还能避免多表联查和跨表事务。图片量真到了单条几兆、超大内容时再拆表也不迟。order_no必须前端生成并保证唯一因为后端接口要用它做幂等防止维修人员在弱网环境重复点击提交产生两张一模一样的工单。2.2 巡检打卡记录与定位数据的防作弊字段设计电梯智慧监管最核心的诉求不是“记录”而是“人真的到了现场”。单纯让维保工在小程序里填单没用后台必须能证明这个人当时就在那台电梯旁边。所以单独设计了一张巡检打卡记录表inspect_log每次扫码、上报、签到都往里写一条。-- 巡检日志表 inspect_log记录一次扫码或上报行为用来还原现场 CREATE TABLE inspect_log ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL COMMENT 操作人用户ID, elevator_id INT UNSIGNED NOT NULL COMMENT 被操作的电梯, action_type TINYINT NOT NULL COMMENT 1扫码 2上报故障 3签到打卡 4年检提醒, longitude DECIMAL(10,6) DEFAULT NULL COMMENT 当时定位经度, latitude DECIMAL(10,6) DEFAULT NULL COMMENT 当时定位纬度, address_text VARCHAR(255) DEFAULT NULL COMMENT wx.getLocation返回的地址文本留底, device_platform VARCHAR(16) DEFAULT NULL COMMENT iOS或Android排查兼容性问题用, brand VARCHAR(32) DEFAULT NULL COMMENT 手机品牌华为/小米/iPhone等, app_version VARCHAR(16) DEFAULT NULL COMMENT 小程序版本号灰度发布排查用, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这张表在设计阶段常被低估上线后就成了审计和扯皮的关键证据。字段选型要特别注意device_platform和brand它们不是给前端展示用的而是出问题时定位“为什么只有某品牌手机扫码失败”的钥匙。created_at写入的是后端数据库时间不要拿小程序端传来的时间做业务判断因为手机本地时间可以被用户随意修改。定位防作弊的常见做法是“扫码为主、定位为辅”。手机定位在室内经常漂移几十米电梯机房和轿厢里GPS信号基本不可用单纯靠定位判定是否到场会误杀一半。所以巡检日志里的经纬度只作为佐证后台校验规则是同一用户在同一台电梯的两次扫码之间必须有时间差且当日最早扫码时间和最晚扫码时间的间隔不小于计划维保时长。更严格的方案会在后台计算“用户连续三天在同一经纬度打卡”的聚集度检测出代打卡的嫌疑点这一块放到第六章细说。2.3 工单完成时的MySQL事务改状态、翻计划、记日志电梯维保工单完成的瞬间后台要做三件事把工单状态改成已完成、把维保计划滚动到下一个周期、在操作日志里记录这次行为。这三件事要么全成要么全败不能出现“工单已提交但计划没滚动”的中间状态。START TRANSACTION; -- 1. 条件更新工单状态只更新“执行中”的工单防止重复完成 UPDATE work_order SET status 3, finish_time NOW() WHERE order_no WO-SG-202410001 AND status 2; -- 2. 滚动维保计划把上次完成时间改成现在下次计划时间按周期推进 UPDATE maintain_plan SET last_finish_time NOW(), next_plan_time DATE_ADD(last_finish_time, INTERVAL period_days DAY), status 1 WHERE id 101; -- 3. 记录操作日志保证可追溯 INSERT INTO operate_log(work_order_id, action, operator_id, created_at) VALUES (102, 完成工单维保计划已滚动至下一周期, 202, NOW()); COMMIT;这个事务里的关键参数是status 2这个更新条件。工单在执行中只能被完成一次如果维修人员网络不好重发了两次请求第二次的UPDATE因为status已经不是2影响行数为0业务层就能判断出这是重复请求不会连续翻两次计划。这是比“先查再改”更稳的乐观锁写法也是这套系统防重复提交的第一道防线。DATE_ADD(last_finish_time, INTERVAL period_days DAY)这个写法也值得注意它用的是last_finish_time而不是next_plan_time意思是从实际完成那天往后推周期而不是从理论计划日推。电梯维保经常提前或延后两三天如果用计划时间去加周期会出现“这次做完下次还是按老计划来”的错位。3. 小程序端从零跑通请求封装、扫码绑梯与图片上传的三个关键代码小程序端的技术选型最常见的是微信原生框架。用原生还是用uni-app取决于团队是否要同时出H5和App版本如果只做小程序内使用原生框架引入的依赖最少调试时踩的坑也最少。下面这三个模块是我每次都要优先跑通的请求封装、扫码绑梯、图片上传。3.1 封装wx.request统一前缀、状态码约定与token续期小程序自带的wx.request是一个很原始的API直接写在页面里会导致几十个页面重复处理登录态、超时和错误码。第一件事就是把它封装成一个返回Promise的请求函数让页面侧只关心业务成功和失败。// utils/request.js const BASE_URL https://api.elevator-monitor.example.cn/v1; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${path}, method: method, data: data, header: { Content-Type: application/json, Authorization: Bearer ${wx.getStorageSync(token) || } }, success: (res) { // HTTP 401token过期或无效走刷新逻辑后重放请求 if (res.statusCode 401) { refreshToken() .then(() request(path, method, data)) .then(resolve) .catch(reject); return; } // 业务约定HTTP 200且code0才算成功其余都弹错误提示 if (res.statusCode 200 res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request, BASE_URL };封装逻辑里有三个约定要提前定死第一后端返回体统一是{ code, msg, data }前端只看业务码codeHTTP状态码只处理401这一个特例第二token过期不直接跳登录页而是先刷新token再重放请求因为维保工可能在填写工单中途刷新一下就丢了表单体验很差第三全局把BASE_URL集中管理从开发环境切正式环境时只改一个文件。refreshToken函数在读wx.getStorageSync(refresh_token)去换新token换回来后要同步更新本地存储这层操作放在请求内部可以让调用方完全无感。3.2 扫码绑定电梯二维码内容是业务主键不是数据库id扫码是整个系统的入口动作。wx.scanCode把二维码内容扫描出来后小程序拿到的是一段字符串不要直接拿这段字符串去数据库查id而是先调后端接口做校验和业务映射。// pages/inspect/inspect.js scanElevator() { wx.scanCode({ scanType: [qrCode], success: async (res) { const code res.result; // 例如 ELEV-SG-2024-0001 if (!code || code.indexOf(ELEV-) ! 0) { wx.showToast({ title: 不是本系统电梯码, icon: none }); return; } try { const data await request( /elevator/bind?code${encodeURIComponent(code)}, GET ); if (data data.id) { this.setData({ elevatorName: data.address, elevatorId: data.id, canSubmit: true }); // 把最近一次扫码的电梯码存起来下次进入巡检页直接回显 wx.setStorageSync(last_elevator_code, code); } } catch (e) { wx.showModal({ title: 绑定失败, content: 该二维码未在平台登记请联系物业在后台录入电梯档案 }); } } }); }这里有个新手常犯的错在小程序端校验完二维码前缀就直接进巡检页不调后端。这样做的风险是二维码内容一旦被复制转发任何人都能冒充巡检。后端/elevator/bind接口要做两件事校验elevator_code存在且status1再返回电梯的必要信息。wx.setStorageSync(last_elevator_code, code)是个很实用的小技巧维保师傅一天扫几十台电梯第二次到同一栋楼时列表里能直接点选上次的电梯不用再走到电梯前扫码。3.3 图片上传压缩与临时文件管理维保现场的照片是小程序端最头疼的部分。安卓手机拍一张照片动辄三五兆电梯井道里光线差还会拍出一堆大图。直接传给后端服务器存储压力大用户流量也扛不住。微信提供了wx.chooseMedia的compressed压缩选项但实际经验是压缩后仍可能有1到2兆更稳的做法是拿到临时文件后先做尺寸缩放再上传。// pages/report/report.js const MAX_IMAGE_SIZE_MB 2; chooseAndUploadImages() { const choose wx.chooseMedia({ count: 3, mediaType: [image], sizeType: [compressed], // 优先拿系统压缩过的图 success: async (res) { const tasks res.tempFiles.map((file) this.compressAndUpload(file)); try { const urls await Promise.all(tasks); this.setData({ photoUrls: urls }); // 后台返回的图片URL数组 } catch (e) { wx.showToast({ title: 有图片上传失败请检查网络, icon: none }); } } }); } compressAndUpload(file) { // 对大文件二次压缩小于2MB直接走上传 return new Promise((resolve, reject) { if (file.size MAX_IMAGE_SIZE_MB * 1024 * 1024) { this.doUpload(file.tempFilePath).then(resolve).catch(reject); return; } wx.compressImage({ src: file.tempFilePath, quality: 75, success: (cRes) this.doUpload(cRes.tempFilePath).then(resolve).catch(reject), fail: reject }); }); } doUpload(filePath) { return new Promise((resolve, reject) { wx.uploadFile({ url: ${BASE_URL}/file/upload, filePath: filePath, name: file, formData: { elevatorCode: this.data.code }, header: { Authorization: Bearer ${wx.getStorageSync(token)} }, success: (r) { const resp JSON.parse(r.data); if (resp.code 0) resolve(resp.data.url); else reject(resp); }, fail: reject }); }); }图片上传逻辑里最容易被忽略的是两个点。第一个是wx.uploadFile的header它和wx.request不一样Content-Type默认是multipart/form-data你不需要手动设Content-Type: application/json但Authorization头照样要带。第二个是上传接口返回的URL必须持久化不能直接把file.tempFilePath存入数据库这个临时路径在小程序重启或者杀进程后就会失效。后端拿到图片后要存到正式目录返回一个可访问的静态URL这个坑在第5章会单独展开。4. 让DEMO先转起来Spring Boot接口、初始化脚本与演示数据落地套系统拿回来第一步不是看业务代码而是先把后端跑起来、数据库建起来、小程序连上、把演示视频里的业务链路复现一遍。这个过程做得越顺后续改代码的信心越足。4.1 Spring Boot最小服务端包结构、数据源配置与JWT拦截器电梯监管系统的后端技术栈我见过最多的是Java Spring Boot配MyBatis-Plus少数小团队用Node.js极少有纯PHP。Spring Boot的生态对政企项目更友好会后端的人多出问题好找人。服务端包结构按controller、service、mapper、config四层拆就够不需要上微服务那套。核心配置集中在application.yml下面这段是跑通的最小配置server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:mysql://localhost:3306/elevator_monitor?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghairewriteBatchedStatementstrue username: elevator_user password: change-me servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl几个参数值得较真。context-path: /api给所有接口加了前缀小程序端BASE_URL和后端部署都能统一对齐以后加网关也方便。serverTimezoneAsia/Shanghai必须设置否则MySQL连接池会用JVM默认时区在中国服务器上通常没问题但一旦把数据库迁到云上其他区域的实例时间就会差8小时。rewriteBatchedStatementstrue是给批量插入维保记录做准备的不上这个参数MyBatis的批量insert只走单条执行数据量上来后很慢。JWT拦截器是接口安全的骨架。登录接口放行其余接口都要求Authorization头里带Bearer tokenComponent public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String auth request.getHeader(Authorization); if (auth null || !auth.startsWith(Bearer )) { response.setStatus(401); response.getWriter().write({\code\:401,\msg\:\未登录\}); return false; } String token auth.substring(7); UserContext user JwtUtil.parseToken(token); if (user null) { response.setStatus(401); response.getWriter().write({\code\:401,\msg\:\登录过期\}); return false; } request.setAttribute(currentUser, user); return true; } }拦截器逻辑里有一个实践细节解析完token后把用户信息放进request.setAttribute而不是放进static变量或ThreadLocal。虽然ThreadLocal性能更好但一次请求中如果内部调用了异步线程ThreadLocal会失效排查起来很玄。request.setAttribute在Filter和Interceptor链路里都能拿到改动成本最低。注册拦截器时注意排除路径/auth/login、/file/upload这两个必须放行/file/upload里虽然在拦截器之外但业务层仍要校验token才能拿到上传后的文件URL归属不能完全开放。4.2 初始化脚本与演示数据列表页、详情页和图表同时要有数据数据库初始化脚本通常包含三部分建库建表语句、核心索引、演示数据。建表语句在第2章已经给出这一节重点说的是演示数据怎么插才能让前端页面不空白。拿到一套带数据库的源码初始化脚本跑完后第一件事是登录后台看三个地方电梯列表页有没有数据、电梯详情页的维保记录有没有时间线、数据看板的统计图表有没有柱状图。很多项目源码自带的数据库只插了两三台电梯列表页能显示但维保统计页面前端按月份分组后一片空白看起来像是崩溃了。-- 演示数据三台电梯 三条维保记录 两个月巡检统计 INSERT INTO elevator (elevator_code, address, longitude, latitude, property_company, status) VALUES (ELEV-SG-2024-0001, 演示花园1栋1单元, 120.123456, 30.123456, 演示物业公司, 1), (ELEV-SG-2024-0002, 演示花园1栋2单元, 120.123789, 30.123879, 演示物业公司, 1), (ELEV-SG-2024-0003, 演示花园2栋, 120.124000, 30.124100, 演示物业公司, 2); -- 维保计划3台梯都生成半月保计划让后台“待办计划”有内容 INSERT INTO maintain_plan (elevator_id, plan_type, period_days, next_plan_time, status) VALUES (1, 1, 15, DATE_ADD(CURDATE(), INTERVAL 3 DAY), 0), (2, 1, 15, DATE_ADD(CURDATE(), INTERVAL 5 DAY), 0), (3, 1, 15, DATE_ADD(CURDATE(), INTERVAL 7 DAY), 0);演示数据里的时间和日期千万别写死。比如今天是2024年10月脚本里写2024-10-01三个月后演示的时候维保计划已经全过期了后台看板满屏红色警告。正确的做法是用CURDATE()和DATE_ADD动态生成保证任何时候初始化都能看到“3天后待维保、7天后待维保”的健康状态。演示账号表里至少要三个角色admin/123456给后台管理员worker/123456给维保工manager/123456给物业查看。密码在后端用BCrypt加密存储直接在SQL里写明文是演示数据最不该犯的懒。4.3 接口幂等与扫码上报限流防重复提交的兜底方案电梯维保工在电梯井道里手机信号不稳定点“提交工单”按钮后界面卡住他大概率会再点一次。如果后端不做幂等数据库里就会出现两条一模一样的工单。常见的做法是用Redis的SETNX做短时间窗口去重。PostMapping(/work-order) public Result createWorkOrder(RequestBody WorkOrderVO vo) { // order_no由前端生成UUID后端拿它做幂等键 String idemKey idem:order: vo.getOrderNo(); Boolean firstTry stringRedisTemplate.opsForValue() .setIfAbsent(idemKey, 1, Duration.ofSeconds(10)); if (firstTry null || !firstTry) { return Result.error(正在提交中请勿重复操作); } // 继续执行创建工单逻辑成功后幂等键自然过期 workOrderService.create(vo); return Result.ok(); }幂等键的有效期10秒就够了超过10秒用户肯定已经感知到失败并重新操作。这里有个细节如果业务执行失败比如电梯档案不存在应该手动删除幂等键否则用户改完数据在10秒内再次提交会被误拦截。限流方面扫码绑定接口按用户维度限到5次每秒即可超过就返回“操作过于频繁”。电梯扫码绑定的场景是人工扫码不是机器调用不需要太高阈值反而是上传图片接口要适当放宽维保工一次传3张照片每张上传间隔几十毫秒限流设太紧会把正常请求误伤。5. 部署调试避坑审核资质、定位权限、时间兼容与文件失效这套系统从开发到真正用起来最大的阻力不在技术而在小程序的平台规则和几个隐蔽的兼容性问题。下面五条都是亲手踩过的按严重程度排个序。5.1 类目审核被拒特种设备监管需要企业资质与经营范围现象小程序代码写完了提交审核时提示“当前类目与小程序实际功能不符”或者直接要求提供特种设备相关的资质文件。个人开发者账号几乎第一时间被拒。原因电梯维保涉及特种设备、公共安全微信对这类场景管控很严。智慧监管四个字在类目审核里容易被识别为政府或监管类应用个人主体没有资质能过。解决用企业主体注册小程序选择商业服务 物业管理或生活服务 城市服务里的市场监管类目。如果拿不到相关资质一个务实的做法是把产品定位改成“企业内部维保巡检工具”服务对象是物业公司和维保公司员工而不是面向公众的投诉举报平台。面向内部人员的小程序在审核时被当成企业管理工具类目要求会宽松很多。这个定位调整不改变代码结构只改变小程序服务类目和简介文案。5.2 iOS与安卓日期解析不一致导致工单时间错乱现象同一台手机小程序页面显示的工单完成时间是上午10点整但同一数据在iOS上显示下午6点安卓上又正常。后台看板里的超时统计数字对不上。原因后端返回的日期字符串是2024-10-22 14:30:00这种MySQL默认格式。iOS的JavaScript引擎对不带T的日期格式解析行为不一样部分版本会直接返回Invalid Date部分版本按UTC解析多加了8小时。安卓的V8引擎则按本地时区解析所以两头差出8小时。解决后端接口统一返回毫秒时间戳前端用dayjs格式化。改动方法是把后端JSON序列化的LocalDateTime输出成yyyy-MM-dd HH:mm的字符串或者直接输出long。前端统一加一行转换function formatTime(ts) { if (!ts) return -; const d new Date(Number(ts)); // 统一按毫秒时间戳构造 const pad (n) n.toString().padStart(2, 0); return ${d.getFullYear()}-${pad(d.getMonth() 1)}-${pad(d.getDate())} ${pad(d.getHours())}:${pad(d.getMinutes())}; }时间戳方案虽然可读性差但它是跨iOS、安卓、后台管理端最不会出错的格式。条件允许的话前端不要自己写格式化函数装一个dayjs体积只有几KB处理时区和格式化都稳定得多。5.3 定位授权被拒后不再弹窗需要“去设置”引导现象用户第一次进小程序时点了“拒绝”定位授权后面再也弹不出授权窗扫码打卡功能一直失败。让他删除小程序重进也还是失败。原因小程序的wx.getLocation授权是一次性决策用户拒绝后不会再自动弹窗。即使他在手机系统设置里重新打开了定位权限小程序内部的scope.userLocation状态仍然是false必须通过wx.openSetting让用户手动重新授权。解决在巡检首页先用wx.getSetting判断授权状态再分别引导。checkLocationAuth() { wx.getSetting({ success: (res) { if (res.authSetting[scope.userLocation] false) { wx.showModal({ title: 需要定位权限, content: 扫梯打卡需要获取您的当前位置请在设置中重新授权, confirmText: 去设置, success: (r) { if (r.confirm) { wx.openSetting(); // 引导用户到小程序设置页打开定位开关 } } }); } } }); }这里有两个细节第一wx.getLocation的type参数建议用wgs84默认值也是wgs84前端展示用没问题但如果要做距离计算后端要转成gcj02再算这个转换很容易被忽略第二不要在首页onLoad里直接调getLocation用户连系统弹窗都没看懂就被拒绝了把定位请求放在用户明确点击“开始打卡”按钮之后授权通过率会高很多。5.4 上传图片隔天失效临时目录和正式目录混用现象当天上传的照片在工单详情里能正常显示第二天再打开同一张工单图片全部裂开。后台服务器上看文件还在但URL访问返回404。原因后端文件上传代码把图片存到了系统临时目录比如Linux的/tmp下或者云服务器的临时盘中。/tmp目录会被系统定期清理服务重启也会清掉一部分文件。演示环境里最容易出现这个问题因为开发时往往随便写了个路径。解决把文件存储路径固化成独立的项目目录比如/data/elevator/files/用Nginx映射成静态资源访问。Nginx配置片段location /files/ { alias /data/elevator/files/; expires 7d; add_header Cache-Control public, no-transform; }上传代码里要做目录检查不存在就创建不能假设目录一定存在。更省心的做法是直接接入云对象存储上传接口把文件丢到对象存储桶里返回桶的URL。对于电梯监管这种存量和增量都不大的场景用对象存储的额外成本每月几乎可以忽略不计。数据库里存的应该是相对路径/files/2024/10/xxx.jpg不要存全域名否则换域名或者从http切https后历史图片全部要改库。5.5 合法域名校验开发者工具不弹错真机就是连不上现象微信开发者工具里能正常登录、能拉数据点“预览”用真机扫码头一次就白屏报url not in domain list。原因微信小程序的生产环境对wx.request和wx.uploadFile的域名有严格白名单限制。开发者工具默认勾选了“不校验合法域名”所以本地调试畅通无阻真机上这个自动开关失效必须保证你的接口域名在微信后台的服务器域名列表里。解决在微信公众平台后台的“开发管理-开发设置-服务器域名”里配置request和uploadFile合法域名。要求是域名必须已经备案、必须HTTPS、不能带端口和路径。如果开发阶段买不起独立域名或没有备案可以用微信开发者工具 详情 本地设置 不校验合法域名继续调试但发布体验版和正式版前一定要切到合法域名。实际操作里最坑的是配了request域名但忘了配uploadFile域名结果是登录正常传照片失败报错还很隐晦。配置完域名后至少要等10分钟再试微信有缓存生效延迟。6. 从能跑到能用NFC替代扫码、离线巡检与数据链路校验前面的内容把一套基于微信小程序的电梯智慧监管系统从数据库、接口到小程序端跑通了但一个能演示的系统和一套每天在用的系统之间还差几个长期运营才暴露的改造点。6.1 用NFC标签替代二维码解决磨损和反光电梯井道和轿厢里二维码贴纸的寿命通常不超过三个月不是被撕就是被磨损反光材质在手机镜头下经常识别失败。后续改造可以引入NFC标签每台电梯预埋一个NTAG215芯片维保工手机碰一下标签就触发事件。工程上要做两层兼容主场景NFC失败时回退扫码录入。小程序端使用wx.getNFCAdapter来读取标签核心是拿到NFC的identifier后转成电梯编码。但要注意NFC适配在iPhone上不如安卓顺畅项目的演示环境、开发工具都不支持NFC模拟只能真机调试这决定了巡检主流程必须保留扫码兜底。6.2 离线巡检本地队列与联网补传电梯机房和地下车库经常没有手机信号维保工进了井道填完的巡检单发送失败界面转圈半天。改造方案是做一个本地待同步队列提交不成功的工单先存进wx.setStorageSync的本地数组每次切到前台或者网络恢复时按时间顺序逐条补传。补传时要带上order_no这个唯一键后端在幂等逻辑的协助下能安全接收重复推送。这个队列不需要做得太重一个数组、一个上传状态标记、一个网络监听回调就够。6.3 用统计SQL验证前端看板数字的真实性最后养成一个习惯每周花十分钟用SQL去核一遍后台看板的数字。维保完成率、超期工单数、巡检覆盖率这些指标前端是查接口算出来的接口出bug就会让看板数字虚高。核对脚本很简单比如统计维保完成率SELECT DATE_FORMAT(created_at, %Y-%m) AS month, COUNT(*) AS total_orders, SUM(CASE WHEN status 3 THEN 1 ELSE 0 END) AS finished_orders, ROUND(SUM(CASE WHEN status 3 THEN 1 ELSE 0 END) / COUNT(*) * 100, 1) AS finish_rate FROM work_order WHERE type 1 GROUP BY DATE_FORMAT(created_at, %Y-%m) ORDER BY month DESC;看板数字和SQL结果对不上时先怀疑后端接口的查询条件再怀疑前端缓存最后才怀疑数据库脏数据。电梯监管系统的核心资产是可追溯的维保记录而不是前端那些花花绿绿的图表数据链路跑通后再去优化界面这个习惯帮我避免了好几次项目验收时的尴尬。希望这篇笔记能帮你把这个方向跑顺少踩几个我当年熬夜排查的坑。本文还有配套的精品资源点击获取