1. 項目背景與需求分析2020年以來的特殊時期催生了大量數字化防疫需求其中居家健康監測成為基層管理的核心痛點。傳統紙質登記存在數據滯后、統計困難、易造假等問題而基于微信小程序的解決方案具有天然優勢無需安裝、即用即走、用戶覆蓋率高。這正是我選擇疫情居家檢測管理系統作為畢業設計課題的現實意義。從技術角度看該系統需要實現三個核心功能模塊居民端健康打卡、異常申報、核酸結果上傳社區端數據看板、預警通知、統計導出管理端權限分配、區域配置、審核流程特別值得注意的是微信小程序在疫情期間開放了特殊接口權限如獲取用戶實名信息、調用衛健委核酸數據等這為系統開發提供了官方支持。同時uni-app跨端框架的成熟使得一套代碼同時適配小程序和H5成為可能這對畢設的完整性和擴展性都是加分項。2. 技術選型與架構設計2.1 前端技術棧決策經過對比測試最終選擇uni-appVue3組合而非原生小程序開發主要基于以下考量開發效率使用熟悉的Vue語法比學習WXML/WXSS更高效跨端能力通過條件編譯可同時輸出H5版本實測打包差異僅增加約200KB組件生態uView組件庫提供現成的表單、圖表等組件關鍵配置示例manifest.json{ mp-weixin: { appid: wx你的appid, usingComponents: true, permission: { scope.userLocation: { desc: 用于自動填充社區信息 } } } }2.2 后端服務搭建考慮到畢設周期和答辯演示需求采用Node.jsMySQL輕量級方案使用Koa2框架而非Express因其更優雅的中間件機制數據庫選用MySQL5.7而非MongoDB因防疫數據需要嚴格的事務支持部署方案本地測試用PM2守護進程演示時使用騰訊云基礎版CVM典型API接口設計// 健康打卡提交接口 router.post(/api/checkin, async (ctx) { const { temperature, symptoms } ctx.request.body if (!temperature || temperature 37.3) { ctx.body { code: 400, msg: 體溫異常 } return } // 數據庫操作... })3. 核心功能實現細節3.1 居民健康打卡模塊采用微信表單組件自定義校驗規則關鍵實現點體溫輸入框增加0.1℃步進控制input typenumber step0.1 blurcheckTemp /癥狀選擇使用多級聯動參考衛健委標準分類地理位置自動填充需處理用戶拒絕授權的情況實測中發現的問題及解決方案在華為機型上連續快速提交會導致表單數據丟失。通過添加防抖函數和提交狀態鎖解決let isSubmitting false const submitForm debounce(() { if (isSubmitting) return isSubmitting true //...提交邏輯 }, 500)3.2 社區數據看板開發使用ECharts微信小程序版實現可視化特別注意數據聚合策略按樓棟/單元分級統計性能優化對超過1000條記錄啟用分頁查詢緩存機制首頁數據本地緩存2小時典型圖表配置option { dataset: { source: [ [單元, 正常, 異常], [1單元, 45, 2], [2單元, 38, 5] ] }, series: [ { type: bar, encode: { x: 單元, y: 正常 } } ] }4. 項目難點與解決方案4.1 實名認證對接微信小程序實名信息獲取流程前端調用wx.getWeRunData獲取encryptedData后端使用session_key解密數據與公安庫比對使用第三方服務如阿里云實名認證API遇到的坑初期直接在前端解密導致敏感信息暴露后改為后端解密并立即脫敏存儲。同時發現iOS和Android的解密結果格式不一致需要做平臺判斷處理。4.2 高并發提交處理在模擬壓力測試時1000次/分鐘打卡出現數據庫連接池耗盡問題。通過以下優化解決使用Knex連接池配置提升到20個連接對打卡記錄采用批量插入每次最多50條添加Redis緩存層減輕數據庫壓力優化前后對比指標優化前優化后平均響應時間1200ms300ms錯誤率23%0.5%CPU占用85%40%5. 項目擴展與答辯建議5.1 可擴展方向物聯網集成通過藍牙連接智能體溫計自動上傳數據消息推送對接模板消息實現異常預警數字孿生結合三維樓宇模型展示疫情分布5.2 答辯注意事項根據個人答辯經驗建議重點準備演示時準備兩個賬號居民/管理員隨時切換提前錄制異常情況處理視頻如網絡中斷時的本地緩存機制打印關鍵代碼片段如解密算法供評委查閱實際開發中我發現微信小程序的scroll-view組件在渲染長列表時性能較差最終改用recycle-view實現虛擬滾動這使得居民歷史記錄查詢頁面的渲染時間從3秒降至0.5秒。這種具體問題的解決過程往往是答辯加分項。