企业官网建设流程全解析

简介：这是一套面向计算机专业本科生的毕业设计级微信小程序学生宿舍管理系统，专为课程设计、期末大作业及实践能力提升打造，兼顾教学需求与轻量级管理场景落地。资源包含完整前后端代码与数据库脚本：前端以194个Vue组件、160个WXML页面和162个WXSS样式文件构成小程序主体界面；后端逻辑由347个JS文件支撑；配套319个PNG图标、161个SVG矢量图及118个JPG/JPEG素材保障UI呈现；核心SQL数据库文件与173个JSON配置共同支撑用户、宿舍、报修、财务等七大功能模块运行。压缩包共1686个文件，大小19.64MB，结构清晰，含build脚本（bat）、备份文件（bak）及文档说明（md/docx），便于快速部署与二次开发。目前已有171人学习下载，适合零基础入门小程序开发、系统性实践全栈流程的学习者，可直接用于答辩演示、代码复现与模块化功能拓展。

1. 微信小程序的学生宿舍管理系统：为什么一个“轻量级”系统反而最难落地？

很多开发者拿到「微信小程序的学生宿舍管理系统」这个需求时，第一反应是：不就是个 CRUD 吗？学生查床位、辅导员改状态、宿管扫脸登记——界面清爽、逻辑清晰、API 简单，半天就能搭出原型。但真实项目里，90% 的翻车不是卡在登录态或云开发配置，而是卡在数据一致性边界和小程序生命周期约束的夹缝中：比如学生退宿后，宿舍状态没同步更新，下一位学生扫码入住时看到的仍是“已入住”；又比如批量导入 200 条床位数据，小程序在真机上因 setData 体积超限直接白屏，而开发者工具里一切正常。这不是玄学，是微信运行时对内存、渲染帧率、本地缓存容量的硬性限制，在 PC 端被忽略的细节，在小程序里会变成黑匣子式崩溃。本篇不讲“怎么注册小程序账号”，也不堆砌 WXML 标签语法，而是聚焦一线落地中最常被低估的三个断层：云数据库权限模型如何匹配宿舍管理的多角色视图、离线场景下扫码登记与状态回传的最终一致性保障、从 Excel 导入到小程序端实时渲染的全链路防抖设计。适合正在接手校内信息化二期、需要交付可运维系统的开发者，以及想把课程设计做出生产级质感的学生团队。

2. 用云开发快速搭建基础结构：数据库设计与角色权限隔离

微信小程序的宿舍管理系统，首选云开发（CloudBase）而非自建 Node.js 服务，核心原因不是“省事”，而是天然规避了鉴权穿透风险。传统方案中，前端调用后端接口时，需自行维护 token、校验 session，而宿舍系统涉及学生、辅导员、宿管三类角色，权限粒度细（如宿管只能改本楼栋数据，辅导员可查全院但不可删记录），手动实现极易留漏洞。云开发的数据库安全规则（Security Rules）把权限控制下沉到数据层，配合 openid 自动绑定，让“谁能看到什么”变成声明式配置，而非代码逻辑。

2.1 宿舍核心数据表结构设计（含字段说明与业务含义）

我们不采用单一大表存储所有信息，而是按业务域拆分为三张主表，每张表均以_id为唯一主键（云开发自动创建），并显式定义create_time和update_time字段用于审计：

提示：dorm_student表不存openid，而是用student_id关联教务系统——这是关键设计。小程序用户 openid 与学号无固定映射（学生换手机即变），而学号是学校权威身份标识。登录时，学生输入学号+验证码（短信或教务接口），后端校验通过后返回临时 token，小程序凭此 token 访问云数据库。这样既满足实名要求，又避免 openid 泄露导致的数据越权。

2.2 云数据库安全规则：用角色标签实现动态权限控制

云开发数据库规则不是 JSON Schema 校验，而是类似 Firebase 的表达式语言。我们为每个集合定义read和write规则，核心思路是：所有写操作必须携带role字段，且该字段值与当前用户 openid 在user_role表中的记录一致。

首先，在user_role表中预置角色映射（管理员后台录入）：

{ "openid": "oAbc...xyz", "role": "dorm_manager", "building_code": "D3" }

然后，在dorm_room集合的安全规则中写：

// dorm_room 安全规则 { "rules": { ".read": "auth != null && (auth.token.role == 'admin' || auth.token.role == 'dorm_manager' && resource.data.building_code == auth.token.building_code)", ".write": "auth != null && (auth.token.role == 'admin' || auth.token.role == 'dorm_manager' && request.resource.data.building_code == auth.token.building_code)" } }

注意：auth.token.role来源于登录时后端签发的 JWT 中的role字段，而非前端伪造。小程序端调用wx.cloud.callFunction获取登录凭证后，后端服务校验学号，生成含role和building_code的 token 并返回给前端，前端再将此 token 作为header传入云函数或数据库请求。这一步是权限可信链的起点，绝不能省略。

2.3 初始化脚本：用云函数批量导入楼栋与房间数据

手工在控制台一条条加数据不现实。我们写一个云函数initDormData，接收 Excel 文件 base64 编码（前端上传），解析后批量写入。关键点在于分片提交——云开发单次add最多 50 条，且总数据量不能超 1MB：

// 云函数 initDormData/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event, context) => { const { fileBase64 } = event // 前端传来的 Excel base64 const buffer = Buffer.from(fileBase64, 'base64') // 使用 xlsx 解析（需在云函数依赖中安装） const XLSX = require('xlsx') const workbook = XLSX.read(buffer, { type: 'buffer' }) const sheet = workbook.Sheets[workbook.SheetNames[0]] const jsonData = XLSX.utils.sheet_to_json(sheet) // 分片：每 40 条一组（留 10 条余量防字段膨胀） const chunkSize = 40 const chunks = [] for (let i = 0; i < jsonData.length; i += chunkSize) { chunks.push(jsonData.slice(i, i + chunkSize)) } try { for (const chunk of chunks) { await db.collection('dorm_room').add({ data: chunk.map(item => ({ room_number: item['房间号'], building_code: item['楼栋编码'], bed_count: parseInt(item['床位数']), occupied_count: 0, status: 'vacant', create_time: new Date(), update_time: new Date() })) }) } return { success: true, total: jsonData.length } } catch (err) { console.error('批量插入失败', err) throw err } }

参数说明：chunkSize = 40是血泪经验。曾设为 50，某次导入含长文本备注的 Excel 时，单条数据体积超 20KB，40 条即达 800KB，触发云开发写入超时。降为 40 后，即使字段稍长，也能稳定在 1MB 内。另外，create_time和update_time必须显式赋值为new Date()，云开发不会自动填充时间戳字段。

3. 宿舍状态实时同步：扫码入住与离线回传的最终一致性方案

小程序端扫码入住看似简单：扫房间二维码 → 调用 API 更新dorm_room.occupied_count→ 刷新页面。但真实场景中，学生站在楼道里扫码，信号可能只有 1-2 格；宿管在地下室巡检，Wi-Fi 断连是常态。若此时直接setData并调用云数据库update，失败即意味着状态丢失——学生以为已登记成功，后台却仍是空房。我们必须把“操作意图”和“状态结果”解耦，引入本地队列 + 服务端幂等校验机制。

3.1 本地操作队列设计：用 Storage 模拟事务日志

小程序没有 SQLite，但wx.setStorageSync可靠性极高（iOS/Android 均落盘）。我们设计一个轻量队列pending_ops，每条记录包含操作类型、目标 ID、参数及时间戳：

// utils/queue.js const QUEUE_KEY = 'pending_ops' // 添加待执行操作 export const pushOp = (opType, targetId, params = {}) => { const queue = getQueue() const op = { id: Date.now().toString(36) + Math.random().toString(36).substr(2, 5), // 短唯一ID type: opType, // 'checkin', 'checkout', 'update_status' target: targetId, // room_number 或 student_id params, timestamp: Date.now(), status: 'pending' // pending / success / failed } queue.push(op) wx.setStorageSync(QUEUE_KEY, queue) } // 获取队列 export const getQueue = () => { const raw = wx.getStorageSync(QUEUE_KEY) return Array.isArray(raw) ? raw : [] } // 标记操作为成功 export const markSuccess = (opId) => { const queue = getQueue() const idx = queue.findIndex(op => op.id === opId) if (idx !== -1) { queue[idx].status = 'success' wx.setStorageSync(QUEUE_KEY, queue) } }

当学生扫码入住时，不直接调云数据库，而是：

1. 调用pushOp('checkin', 'D3-302', { studentId: '20230001', bedNumber: 2 })
2. 本地setData更新 UI 显示“已提交，等待同步”
3. 启动后台同步任务（见 3.2）

3.2 后台同步服务：定时拉取 + 网络恢复触发双保险

单纯靠onNetworkStatusChange不够——它只通知网络通断，不保证服务器可达。我们采用“定时轮询 + 事件触发”双策略：

// app.js onLaunch 中初始化 App({ onLaunch() { // 1. 网络恢复时立即同步 wx.onNetworkStatusChange((res) => { if (res.isConnected) { this.syncPendingOps() } }) // 2. 每 30 秒检查一次（节电模式下会降频，但至少保证后台存活时有兜底） this.syncTimer = setInterval(() => { this.syncPendingOps() }, 30 * 1000) }, syncPendingOps() { const queue = getQueue() const pending = queue.filter(op => op.status === 'pending') if (pending.length === 0) return // 逐条执行，失败则中断，下次重试（避免雪崩） for (const op of pending) { try { if (op.type === 'checkin') { await this.handleCheckin(op) markSuccess(op.id) } } catch (err) { console.warn('同步失败，保留待重试', op.id, err) break // 中断，不继续执行后续 } } }, async handleCheckin(op) { const { studentId, bedNumber } = op.params const roomNumber = op.target.split('-')[1] // D3-302 → 302 // 关键：服务端幂等校验 const result = await wx.cloud.callFunction({ name: 'checkinStudent', data: { studentId, roomNumber, bedNumber, // 传入客户端时间戳，服务端校验是否重复（同一学生 5 分钟内不可重复入住） clientTime: op.timestamp } }) if (!result.result.success) { throw new Error(result.result.message) } } })

为什么需要服务端幂等？因为小程序可能因网络抖动多次触发handleCheckin（用户狂点“确认”按钮），或同步定时器重叠执行。服务端云函数checkinStudent必须先查dorm_student表是否存在studentId + roomNumber的未退宿记录，存在则直接返回成功，避免重复插入。这是最终一致性的最后一道闸门。

3.3 云函数 checkinStudent：原子化更新与状态联动

该云函数是整个流程的核心，必须保证数据库操作的原子性（虽云开发不支持事务，但可通过单次update+ 条件过滤模拟）：

// 云函数 checkinStudent/index.js exports.main = async (event, context) => { const { studentId, roomNumber, bedNumber, clientTime } = event const db = cloud.database() const _ = db.command try { // 1. 检查学生是否已入住其他房间（防止重复分配） const existing = await db.collection('dorm_student').where({ student_id: studentId, status: _.neq('checked_out') // status 字段需提前加 }).get() if (existing.data.length > 0) { return { success: false, message: '该学生已在其他房间入住' } } // 2. 检查房间是否满员 const room = await db.collection('dorm_room').where({ room_number: roomNumber }).field({ bed_count: true, occupied_count: true }).get() if (room.data.length === 0) { return { success: false, message: '房间不存在' } } const r = room.data[0] if (r.occupied_count >= r.bed_count) { return { success: false, message: '房间已满' } } // 3. 原子化：同时更新房间占用数 + 插入学生记录 // 使用 transaction（云开发支持）确保两步不割裂 const wxContext = cloud.getWXContext() const res = await db.collection('dorm_room').doc(room.data[0]._id).update({ data: { occupied_count: _.inc(1), status: r.occupied_count + 1 === r.bed_count ? 'occupied' : 'vacant', update_time: new Date() } }) await db.collection('dorm_student').add({ data: { student_id: studentId, name: '待同步', // 实际应从教务接口获取，此处简化 building_code: 'D3', // 可从 room 推导 room_number: roomNumber, bed_number: bedNumber, checkin_time: new Date(), status: 'checked_in', create_time: new Date(), update_time: new Date() } }) return { success: true, message: '入住成功' } } catch (err) { console.error('入住失败', err) return { success: false, message: '系统繁忙，请稍后重试' } } }

注意：dorm_student表必须增加status字段（枚举：checked_in/checked_out/transferred），否则无法准确判断学生当前状态。这是很多初版翻车的根源——只靠删除记录来表示退宿，导致历史数据丢失且无法审计。

4. Excel 批量导入与数据校验：从教务系统对接到小程序端零误差呈现

宿舍管理系统最频繁的运维操作不是扫码，而是开学季的批量导入：教务处发来 Excel，含 2000+ 学生的学号、姓名、专业、班级、意向楼栋。人工录入效率低、易出错，但全自动导入又怕格式错位（如“D3”被 Excel 自动转成日期“2023/3/1”）。我们必须在小程序端构建一个带预览、可编辑、强校验的导入工作流，而不是简单上传就完事。

4.1 前端 Excel 解析与智能列映射

小程序不支持FileReader，需用wx.chooseMessageFile选择文件，再用wx.getFileSystemManager().readFile读取二进制：

// pages/import/import.js Page({ data: { previewData: [], // 解析后的前 10 行预览 mapping: { studentId: 0, name: 1, buildingCode: 2, roomNumber: 3 } // 列索引映射 }, async chooseFile() { try { const res = await wx.chooseMessageFile({ count: 1, type: 'file' }) const file = res.tempFiles[0] // 读取文件 const fs = wx.getFileSystemManager() const buffer = await new Promise((resolve, reject) => { fs.readFile({ filePath: file.path, success: resolve, fail: reject }) }) // 解析 Excel（使用 SheetJS 的精简版 xlsx.mini.min.js） const XLSX = require('../../utils/xlsx.mini.min.js') const data = new Uint8Array(buffer.data) const workbook = XLSX.read(data, { type: 'array' }) const sheet = workbook.Sheets[workbook.SheetNames[0]] const jsonData = XLSX.utils.sheet_to_json(sheet, { header: 1 }) // 返回二维数组 // 取前 10 行做预览（避免大文件卡死） const preview = jsonData.slice(0, 10).map(row => row.map(cell => cell === undefined ? '' : String(cell)) ) this.setData({ previewData: preview }) } catch (err) { wx.showToast({ title: '解析失败', icon: 'error' }) } } })

关键点在于header: 1—— 它让sheet_to_json返回原始二维数组，而非自动转对象。因为 Excel 表头可能缺失或错位，我们必须让用户手动指定哪一列是学号、哪一列是楼栋编码。

4.2 可视化列映射界面：拖拽调整 + 实时校验反馈

在预览表格下方，提供一个映射配置区：

<!-- pages/import/import.wxml --> <view class="mapping-section"> <text>请指定各列对应字段：</text> <view class="mapping-row" wx:for="{{['studentId','name','buildingCode','roomNumber']}}" wx:key="index"> <text>{{item}}</text> <picker bindchange="bindColumnChange" value="{{mapping[item]}}" range="{{columnIndices}}"> <view class="picker">第 {{mapping[item] + 1}} 列</view> </picker> </view> </view>

columnIndices是根据previewData[0]长度生成的数组[0,1,2,...]。用户选择后，我们实时高亮预览表中对应列，并用正则校验该列数据是否符合预期：

// pages/import/import.js bindColumnChange(e) { const field = e.currentTarget.dataset.field const colIndex = parseInt(e.detail.value) const mapping = { ...this.data.mapping, [field]: colIndex } // 实时校验：学号列必须全为数字+字母，长度6-12 if (field === 'studentId') { const sample = this.data.previewData.slice(1, 6).map(row => row[colIndex]) const valid = sample.every(val => /^[a-zA-Z0-9]{6,12}$/.test(val)) if (!valid) { wx.showToast({ title: '学号列含非法字符', icon: 'none' }) } } this.setData({ mapping }) },

血泪经验：必须校验sample（前 5 行），而非整列。整列遍历 2000 行会卡死 UI。只要前几行合规，大概率整列合规；若前几行就不对，用户会立刻修正。

4.3 服务端校验与差异报告生成

前端校验只是第一道关。真正危险的是“看起来对”的数据：比如楼栋编码D03（多了一个 0）与数据库中的D3不匹配，或房间号302A（带字母）无法入库。这些必须由服务端兜底，并返回结构化错误：

// 云函数 validateImport/index.js exports.main = async (event, context) => { const { rows, mapping } = event // rows 是前端传来的二维数组 const db = cloud.database() const errors = [] // 1. 提前查出所有有效楼栋编码 const buildings = await db.collection('dorm_building').field({ building_code: true }).get() const validBuildings = new Set(buildings.data.map(b => b.building_code)) // 2. 遍历每一行 for (let i = 0; i < rows.length; i++) { const row = rows[i] const studentId = row[mapping.studentId] const buildingCode = row[mapping.buildingCode] const roomNumber = row[mapping.roomNumber] if (!studentId || !/^[a-zA-Z0-9]{6,12}$/.test(studentId)) { errors.push({ row: i + 1, field: 'studentId', reason: '学号为空或格式错误' }) continue } if (!validBuildings.has(buildingCode)) { errors.push({ row: i + 1, field: 'buildingCode', reason: `楼栋编码 ${buildingCode} 不存在` }) continue } // 检查房间是否存在（需联合楼栋） const room = await db.collection('dorm_room').where({ building_code: buildingCode, room_number: roomNumber }).get() if (room.data.length === 0) { errors.push({ row: i + 1, field: 'roomNumber', reason: `房间 ${buildingCode}-${roomNumber} 不存在` }) continue } } return { errors, validCount: rows.length - errors.length } }

前端收到errors后，生成一个 Markdown 格式的报告页，用<rich-text>渲染，清晰标出错误行、字段和原因。用户可下载此报告，交教务处核对，而非盲目重传。

5. 常见问题排查：5 个让开发者凌晨三点还在抓头发的真实坑

做宿舍管理系统，80% 的时间花在解决那些“理论上不该发生”的问题上。以下是我在多个校内项目中踩过的坑，按出现频率排序，每条都附带复现方式、根因分析和可立即执行的修复命令。

5.1 现象：学生扫码后 UI 显示“入住成功”，但云数据库dorm_room.occupied_count未增加，且无任何报错日志

原因：云函数checkinStudent中更新dorm_room的update操作未加.get()等待，导致 Promise 未被 await，函数提前返回，后续add操作被丢弃。云开发日志中只显示“函数执行完成”，不报错，因为.update()返回的是Promise，未await就相当于“fire and forget”。
解决：在云函数中，所有数据库操作必须显式await。检查checkinStudent代码，确认db.collection(...).update(...)前有await。修复后重新部署云函数，并在日志中搜索checkinStudent，确认有update和add两条成功日志。

5.2 现象：Excel 导入时，楼栋编码D3被自动转成44200（Excel 的日期序列值）

原因：Excel 对“D3”这种格式会误判为日期（D3 是第 4 行第 3 列的单元格地址），并存储为数值44200（2021-01-01 起的天数）。xlsx库默认按单元格类型解析，若类型为n（number），就会返回数字而非字符串。
解决：解析时强制指定列类型为字符串。修改前端解析代码：

const jsonData = XLSX.utils.sheet_to_json(sheet, { header: 1, defval: '', // 空单元格填空字符串 raw: false, // 关键！禁用原始类型，强制转字符串 })

同时，在服务端validateImport中，对buildingCode字段做String(buildingCode)转换，避免数字44200直接参与比较。

5.3 现象：宿管切换楼栋后，dorm_room列表仍显示全部房间，未按building_code过滤

原因：前端wx.cloud.database().collection('dorm_room').where({ building_code: 'D3' })查询时，building_code字段在数据库中实际存储为'd3'（小写），而查询条件是'D3'（大写），大小写不匹配导致无结果。云开发数据库区分大小写，且未建索引时，where查询会全表扫描，但大小写不一致仍返回空。
解决：统一数据规范。在初始化脚本和所有写入操作中，对building_code强制toUpperCase()。同时，在数据库控制台为building_code字段添加索引（提升查询速度）。验证方法：在控制台直接执行db.collection('dorm_room').where({ building_code: 'D3' }).get()，确认返回结果。

5.4 现象：小程序在 iOS 真机上扫码后白屏，开发者工具中完全正常

原因：iOS Safari 对setData数据体积限制更严（约 2MB），而某次导入的dorm_room列表含 500 条数据，每条含 10 个字段，JSON 序列化后超 2.1MB。开发者工具无此限制，故不暴露问题。
解决：分页加载 + 虚拟滚动。前端不再一次性setData全部房间，而是：

• 首次加载只取limit(20)
• 下拉到底部时，offset增加，再get下一批
• 列表组件使用wx:for时，绑定data仅为当前页 20 条，而非全部 500 条
  代码示例：

// data 中只存当前页 data: { roomList: [], offset: 0, limit: 20, hasMore: true }, loadMore() { if (!this.data.hasMore) return db.collection('dorm_room') .skip(this.data.offset) .limit(this.data.limit) .get() .then(res => { const newList = this.data.roomList.concat(res.data) this.setData({ roomList: newList, offset: this.data.offset + this.data.limit, hasMore: res.data.length === this.data.limit }) }) }

5.5 现象：学生退宿后，dorm_student记录被删除，但dorm_room.occupied_count未减 1，导致房间状态永远为occupied

原因：退宿操作未走checkinStudent的逆向逻辑，而是前端直接调用db.collection('dorm_student').remove()，绕过了状态联动。数据库无外键约束，删除学生记录不会触发房间计数更新。
解决：废除直接remove，统一走云函数checkoutStudent。该函数必须包含：

1. 查询dorm_student记录，获取其room_number
2. dorm_room的occupied_count减 1，并更新status
3. 将dorm_student记录的status改为checked_out（而非删除），保留历史
   这样，所有状态变更都经过同一入口，保证一致性。前端退宿按钮的bindtap必须调用wx.cloud.callFunction({ name: 'checkoutStudent' })，而非db.remove。

6. 进阶技巧：用云开发日志 + 自定义指标监控系统健康度

交付系统不是终点，运维才是长期挑战。我见过太多项目上线后，宿管反馈“有时扫不上码”，但日志里全是200，查不出问题。真正的瓶颈往往藏在云函数冷启动延迟、数据库查询慢查询、小程序 setData 频率过高触发渲染阻塞这些灰色地带。下面这套组合拳，能让你在用户投诉前就感知异常。

6.1 云函数性能监控：给每个关键函数打上耗时标签

云开发控制台的日志是平铺的，难以关联一次扫码操作的完整链路。我们在每个云函数开头和结尾打点：

// 云函数通用模板 exports.main = async (event, context) => { const startTime = Date.now() const traceId = Math.random().toString(36).substr(2, 9) // 简单 traceId console.log(`[TRACE:${traceId}] START ${context.functionName}`, event) try { // 你的业务逻辑 const result = await doSomething(event) const duration = Date.now() - startTime console.log(`[TRACE:${traceId}] END ${context.functionName} in ${duration}ms`, { result }) return result } catch (err) { const duration = Date.now() - startTime console.error(`[TRACE:${traceId}] ERROR ${context.functionName} in ${duration}ms`, err) throw err } }

然后，在云开发控制台日志检索中，用TRACE:abc123即可查到一次完整调用的所有日志，包括耗时、入参、出参、错误堆栈。我们约定：耗时 > 1000ms 的函数调用，必须优化。常见原因：未加索引的where查询、get大量数据、update未加id导致全表扫描。

6.2 数据库慢查询识别：用聚合管道定位性能杀手

云开发数据库不直接暴露慢查询日志，但我们可以通过aggregate统计高频查询的响应时间分布。新建一个云函数analyzeDBPerformance：

// 云函数 analyzeDBPerformance/index.js exports.main = async (event, context) => { const db = cloud.database() const $ = db.command.aggregate // 统计最近 1 小时内，dorm_room 查询的平均耗时（需开启云开发性能监控） // 实际中，我们用云开发提供的「性能分析」功能，但这里模拟一个聚合 const stats = await db.collection('dorm_room').aggregate() .match({ update_time: $.gt(new Date(Date.now() - 60 * 60 * 1000)) }) .group({ _id: null, avgDuration: $.avg('$duration'), // 假设日志中存了 duration 字段 count: $.sum(1) }) .end() return stats }

更实用的方法是：在云开发控制台 → 「数据库」→ 「性能分析」中，开启「慢查询日志」（阈值设为 500ms），每天定时查看 Top 5 慢查询。你会发现，90% 的慢查询来自dorm_room表未对building_code建索引的where查询。

6.3 小程序端渲染健康度埋点：用 Performance API 监测卡顿

小程序基础库 2.27.0+ 支持wx.getPerformance()，可获取页面渲染帧率、脚本执行时间。我们在app.js中全局监听：

// app.js App({ onLaunch() { // 启动性能监控 if (wx.getPerformance) { const perf = wx.getPerformance() perf.mark('app_launch_start') // 监听页面渲染完成 wx.onPageNotFound(() => { perf.mark('page_not_found') }) // 每 5 秒上报一次 FPS this.fpsTimer = setInterval(() => { const fps = perf.getFPS() if (fps < 30) { // 持续低于 30fps 视为卡顿 console.warn('页面卡顿，FPS:', fps) // 上报到自定义监控服务（如 Sentry） } }, 5000) } } })

当FPS < 30持续 3 次，我们就知道setData

本文还有配套的精品资源，点击获取