1. 項(xiàng)目概述與需求拆解1.1 這個(gè)項(xiàng)目到底在解決什么問(wèn)題先聊一個(gè)讓我印象很深的場(chǎng)景。我有個(gè)朋友在某三甲醫(yī)院信息科每天接到的投訴電話里至少有三分之一跟掛號(hào)有關(guān)窗口排隊(duì)太久、掛錯(cuò)科室、號(hào)源被黃牛搶走、復(fù)診找不到同一個(gè)大夫。這些問(wèn)題的根源其實(shí)是傳統(tǒng)門診流程里那套到院-排隊(duì)-窗口掛號(hào)-候診-看診的線性模型把所有人在同一時(shí)間擠進(jìn)了同一個(gè)物理空間。所以當(dāng)他來(lái)找我說(shuō)想做一個(gè)醫(yī)院門診掛號(hào)系統(tǒng)時(shí)我第一反應(yīng)不是給他列技術(shù)棧而是問(wèn)了他三個(gè)問(wèn)題你的真實(shí)用戶是誰(shuí)醫(yī)院現(xiàn)有的信息化條件能支撐到什么程度這個(gè)系統(tǒng)是要替代現(xiàn)有HIS系統(tǒng)還是做增量補(bǔ)充聊完之后項(xiàng)目目標(biāo)就很清晰了做一個(gè)基于微信小程序的在線醫(yī)患交互預(yù)約平臺(tái)實(shí)現(xiàn)從查科室-看醫(yī)生-約號(hào)源-在線支付-到院簽到-就診-復(fù)診預(yù)約的完整閉環(huán)同時(shí)給醫(yī)生端留一個(gè)簡(jiǎn)單的排班和患者視圖入口。技術(shù)上用Python做后端框架在Django和Flask里選型小程序端用原生微信小程序開(kāi)發(fā)。整個(gè)系統(tǒng)的技術(shù)底座本質(zhì)上是微信生態(tài)前端 Python Web框架后端 關(guān)系型數(shù)據(jù)庫(kù)的組合。這個(gè)項(xiàng)目適合誰(shuí)參考三類人一是剛學(xué)完P(guān)ython基礎(chǔ)想做實(shí)戰(zhàn)項(xiàng)目的新手能從中理解一個(gè)真實(shí)業(yè)務(wù)系統(tǒng)是怎么從需求落到代碼的二是在醫(yī)院信息科或者醫(yī)療軟件公司工作、想了解小程序端如何跟現(xiàn)有系統(tǒng)對(duì)接的從業(yè)者三是打算接醫(yī)療類外包項(xiàng)目的開(kāi)發(fā)者這套流程能幫你少踩很多坑。1.2 為什么選擇微信小程序而不是App或H5這是項(xiàng)目啟動(dòng)前最關(guān)鍵的決策點(diǎn)直接決定后面所有開(kāi)發(fā)方向。我當(dāng)時(shí)給朋友畫了一張對(duì)比表這才是最終拍板微信小程序的依據(jù)。維度微信小程序H5移動(dòng)網(wǎng)頁(yè)原生App用戶獲取成本掃碼即用無(wú)需下載需保存鏈接或搜索應(yīng)用商店下載安裝用戶留存入口微信聊天列表下拉入口明顯收藏夾容易被遺忘桌面圖標(biāo)穩(wěn)定支付能力微信支付原生集成需額外對(duì)接需申請(qǐng)支付資質(zhì)開(kāi)發(fā)成本一套代碼適配兩端低但體驗(yàn)受限雙端分別開(kāi)發(fā)醫(yī)院推廣阻力低微信生態(tài)內(nèi)觸達(dá)中高消息觸達(dá)訂閱消息通知弱需要推送資質(zhì)對(duì)醫(yī)院這種場(chǎng)景來(lái)說(shuō)小程序用完即走、下次從聊天列表下拉就能進(jìn)的特性是殺手級(jí)優(yōu)勢(shì)。患者在大廳掃碼掛完號(hào)不用記網(wǎng)址、不用裝App下次復(fù)診直接下拉微信就能找到入口。再加上微信支付讓在線繳費(fèi)閉環(huán)變得極其順暢這體驗(yàn)是H5給不了的。原生App雖然體驗(yàn)最好但雙端開(kāi)發(fā)成本、醫(yī)院信息科后續(xù)維護(hù)人力、患者下載意愿這三個(gè)障礙疊在一起基本可以直接否決。技術(shù)上另一個(gè)考慮是小程序前端和公眾號(hào)生態(tài)、企業(yè)微信體系天然互通這為后續(xù)接入醫(yī)院的導(dǎo)診機(jī)器人、健康宣教推送、滿意度調(diào)查留了接口。選型不是看哪個(gè)技術(shù)最酷而是看哪個(gè)方案能在現(xiàn)有資源下跑得最穩(wěn)、維護(hù)成本最低。1.3 技術(shù)選型Django還是Flask這是個(gè)好問(wèn)題后端框架選型是這個(gè)項(xiàng)目里討論最久的話題。網(wǎng)上有個(gè)段子Django像五星級(jí)酒店什么都給你配好了Flask像毛坯房怎么裝修全靠自己。對(duì)這個(gè)項(xiàng)目來(lái)說(shuō)答案其實(shí)取決于你打算把系統(tǒng)做成什么樣。對(duì)比維度DjangoFlask開(kāi)發(fā)速度快內(nèi)置Admin后臺(tái)、ORM、認(rèn)證慢核心只有路由和模板學(xué)習(xí)曲線陡峭概念多平緩易上手?jǐn)?shù)據(jù)庫(kù)操作ORM完善自動(dòng)建表遷移需自行集成SQLAlchemyAdmin后臺(tái)開(kāi)箱即用適合運(yùn)營(yíng)管理無(wú)需自己搭建項(xiàng)目結(jié)構(gòu)有強(qiáng)制規(guī)范app模式自由靈活適合場(chǎng)景完整業(yè)務(wù)系統(tǒng)輕量API服務(wù)社區(qū)生態(tài)大而全第三方包豐富小而精我個(gè)人的建議分兩種情況。如果你要做的系統(tǒng)包含管理后臺(tái)、號(hào)源管理、排班管理、患者檔案這些完整的業(yè)務(wù)模塊直接選Django。它的Admin后臺(tái)在項(xiàng)目早期就是神兵利器醫(yī)院科室、醫(yī)生排班、號(hào)源池這些數(shù)據(jù)錄入和調(diào)整Django Admin改幾行代碼就給你生成一套可用的管理界面不用從頭寫。但如果你后續(xù)打算走前后端完全分離的微服務(wù)架構(gòu)或者只需要給小程序端提供純JSON接口那Flask更輕巧部署也簡(jiǎn)單。這個(gè)項(xiàng)目最終選了Django原因有三個(gè)。第一醫(yī)院門診系統(tǒng)天然是數(shù)據(jù)密集型業(yè)務(wù)Django的ORM在做號(hào)源查詢、余號(hào)扣減、重復(fù)預(yù)約校驗(yàn)這些操作時(shí)代碼量比Flask路線少30%以上。第二Django自帶用戶認(rèn)證系統(tǒng)雖然不能直接用但擴(kuò)展出醫(yī)生、患者兩種角色模型的成本很低。第三項(xiàng)目可能需要二次開(kāi)發(fā)的人接手Django的規(guī)范性讓任何有Python基礎(chǔ)的開(kāi)發(fā)都能快速上手不會(huì)出現(xiàn)Flask項(xiàng)目常見(jiàn)的每個(gè)人的代碼風(fēng)格都不一樣問(wèn)題。2. 系統(tǒng)核心模塊設(shè)計(jì)與數(shù)據(jù)建模2.1 門診系統(tǒng)的角色模型不止是患者和醫(yī)生兩個(gè)角色很多人第一次做這類系統(tǒng)習(xí)慣性地建兩張表一張用戶表、一張醫(yī)生表。但你真正跑一遍醫(yī)院的業(yè)務(wù)流程就會(huì)發(fā)現(xiàn)這個(gè)系統(tǒng)至少涉及四類角色而且每個(gè)角色對(duì)系統(tǒng)的權(quán)限訴求完全不一樣?；颊叨艘氖遣榭剖摇⒄裔t(yī)生、掛今天或明天的號(hào)、支付掛號(hào)費(fèi)、查看就診提醒、掛完號(hào)之后能自助取消。醫(yī)生端要的是查看自己的排班安排、看到底有哪些患者掛了號(hào)、一鍵點(diǎn)擊開(kāi)始就診來(lái)更新候診狀態(tài)。醫(yī)院管理員要的是維護(hù)科室信息、維護(hù)醫(yī)生基本信息、給醫(yī)生排班、設(shè)置每個(gè)時(shí)間段放多少號(hào)源、查看每天各科室的掛號(hào)和退號(hào)統(tǒng)計(jì)。系統(tǒng)超級(jí)管理員則是最高權(quán)限負(fù)責(zé)賬號(hào)管理、數(shù)據(jù)備份、參數(shù)配置。這種角色拆分決定了你Django項(xiàng)目里User模型的擴(kuò)展方案。不要直接在默認(rèn)User表上亂加字段而是用一對(duì)一擴(kuò)展Profile模式。核心User表只保留手機(jī)號(hào)、微信openid、姓名、密碼這些通用字段再建PatientProfile和DoctorProfile分表存各自特有信息比如醫(yī)生的職稱、擅長(zhǎng)領(lǐng)域、所屬科室患者的醫(yī)保卡號(hào)、過(guò)敏史。這樣做的好處是未來(lái)如果要在同一個(gè)微信賬號(hào)下綁定多個(gè)就診人很多患者幫父母掛號(hào)可以把就診人和登錄賬號(hào)徹底解耦擴(kuò)展起來(lái)不用動(dòng)底層結(jié)構(gòu)。2.2 號(hào)源模型核心難點(diǎn)不在表結(jié)構(gòu)在鎖號(hào)和防超賣號(hào)源系統(tǒng)是這個(gè)項(xiàng)目里最容易做崩的地方。我看到很多初學(xué)者寫的代碼預(yù)約邏輯就是簡(jiǎn)單的先查余號(hào)大于0就插入一條預(yù)約記錄。這在單人測(cè)試時(shí)沒(méi)問(wèn)題一旦上線并發(fā)上來(lái)兩個(gè)患者同時(shí)提交最后一個(gè)號(hào)位的預(yù)約請(qǐng)求就會(huì)同時(shí)查到余號(hào)1都插入成功最后超賣。解決超賣問(wèn)題的核心思路從業(yè)務(wù)層面要結(jié)合醫(yī)院的實(shí)際情況來(lái)設(shè)計(jì)。我采用的方案是號(hào)源按時(shí)間段生成 數(shù)據(jù)庫(kù)事務(wù)鎖。具體做法是為每個(gè)醫(yī)生的每個(gè)出診班次預(yù)先根據(jù)排班時(shí)間生成固定數(shù)量的號(hào)源記錄。例如一個(gè)上午班次從8點(diǎn)到12點(diǎn)每20分鐘一個(gè)時(shí)段就生成12條號(hào)源記錄每條記錄有一個(gè)唯一狀態(tài)字段可能是空閑鎖定已預(yù)約這樣可以把并發(fā)壓力從行級(jí)競(jìng)爭(zhēng)分散到號(hào)源記錄本身?；颊唿c(diǎn)擊預(yù)約時(shí)后端執(zhí)行的不再是查詢余號(hào)再插入而是直接執(zhí)行一條條件更新語(yǔ)句更新該號(hào)源記錄的狀態(tài)為鎖定或已預(yù)約但更新條件里必須包含當(dāng)前狀態(tài)為空閑。以Django ORM為例用update()方法配合條件過(guò)濾可以在一句SQL里完成原子操作從代碼層面避免超賣。關(guān)于鎖的補(bǔ)充說(shuō)明真正高并發(fā)場(chǎng)景下Django里的select_for_update()配合事務(wù)可以對(duì)號(hào)源行加數(shù)據(jù)庫(kù)行級(jí)鎖鎖住后再檢查狀態(tài)、創(chuàng)建訂單、扣減號(hào)源。這套組合拳有幾層防護(hù)建議有精力的讀者都掌握。實(shí)測(cè)門診系統(tǒng)的并發(fā)量級(jí)單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器完全扛得住。真正的瓶頸反而不是數(shù)據(jù)庫(kù)而是支付環(huán)節(jié)的重復(fù)回調(diào)處理這部分后面單獨(dú)講。2.3 數(shù)據(jù)表設(shè)計(jì)一張圖看懂核心表關(guān)系回到Spring那套思路用Django的模型定義核心表就這些科室表Department科室名稱、科室編碼、科室位置、是否支持在線掛號(hào)。注意科室編碼一定要唯一這是后續(xù)跟醫(yī)院HIS系統(tǒng)對(duì)接時(shí)的關(guān)鍵關(guān)聯(lián)字段。醫(yī)生表DoctorProfile姓名、職稱、擅長(zhǎng)領(lǐng)域、簡(jiǎn)介、所屬科室外鍵、是否出診狀態(tài)。這里有個(gè)我踩過(guò)的坑醫(yī)生的頭像圖片不能直接存數(shù)據(jù)庫(kù)要存圖片URL路徑文件放對(duì)象存儲(chǔ)或本地靜態(tài)目錄否則數(shù)據(jù)庫(kù)體積膨脹后備份和查詢都會(huì)變慢。排班表Schedule關(guān)聯(lián)醫(yī)生、科室、出診日期、午別、開(kāi)始時(shí)間、結(jié)束時(shí)間、放號(hào)總數(shù)、剩余號(hào)數(shù)。這個(gè)表是系統(tǒng)的心臟所有查詢?nèi)肟趲缀醵家嚷涞脚虐嗌稀Ｌ?hào)源表Slot關(guān)聯(lián)排班、時(shí)段開(kāi)始/結(jié)束時(shí)間、狀態(tài)、鎖定的訂單號(hào)。每個(gè)時(shí)段一個(gè)號(hào)源記錄。掛號(hào)單表Appointment關(guān)聯(lián)患者、醫(yī)生、排班、號(hào)源、就診狀態(tài)待就診/已就診/已取消/爽約、掛號(hào)的訂單號(hào)、支付狀態(tài)。這是貫穿全流程的核心業(yè)務(wù)記錄。支付訂單表PaymentOrder關(guān)聯(lián)掛號(hào)單、支付金額、支付渠道、支付狀態(tài)、回調(diào)通知狀態(tài)。這里要特別留一個(gè)唯一交易號(hào)字段用來(lái)處理支付回調(diào)的冪等性。系統(tǒng)數(shù)據(jù)字典表比如常見(jiàn)問(wèn)題類型、號(hào)源狀態(tài)字典等防止硬編碼寫死在代碼里。表設(shè)計(jì)時(shí)我個(gè)人強(qiáng)烈建議所有核心表都帶上created_at和updated_at兩個(gè)時(shí)間字段以及邏輯刪除字段這樣后端排查問(wèn)題看時(shí)間是幾點(diǎn)操作的、哪些數(shù)據(jù)被邏輯刪除了會(huì)方便很多醫(yī)院上線后運(yùn)維價(jià)值很大。3. 小程序前端與后端API的完整實(shí)現(xiàn)3.1 小程序端整體架構(gòu)與頁(yè)面路由設(shè)計(jì)小程序端我從零開(kāi)始搭用的是原生微信小程序框架沒(méi)有上uniapp或者Taro。原因一是醫(yī)院信息科后續(xù)維護(hù)的人比較熟悉原生語(yǔ)法二是原生開(kāi)發(fā)在真機(jī)調(diào)試、微信版本適配上的穩(wěn)定性都更好。頁(yè)面結(jié)構(gòu)按TabBar分四個(gè)入口首頁(yè)頂部搜索框科室宮格導(dǎo)航今日出診醫(yī)生推薦、預(yù)約我的掛號(hào)和待就診列表支持取消操作、消息系統(tǒng)消息和就診提醒、我的個(gè)人信息、就診人管理、支付記錄、幫助中心。另外還有兩層嵌套頁(yè)面科室詳情頁(yè)展示科室下所有出診醫(yī)生、醫(yī)生詳情頁(yè)展示醫(yī)生排班日歷和號(hào)源時(shí)段這是用戶操作的核心頁(yè)面。關(guān)鍵設(shè)計(jì)原則是讓用戶三步內(nèi)完成掛號(hào)第一步選科室第二步選醫(yī)生和日期第三步選時(shí)間段并確認(rèn)支付。超過(guò)三步中年用戶群體的流失率會(huì)顯著上升。我在醫(yī)生詳情頁(yè)做的是日歷橫滑組件展示未來(lái)一周的可預(yù)約日期日期下面直接列時(shí)段格子綠色代表可約、灰色代表約滿、紅色代表停診顏色語(yǔ)義貼合用戶直覺(jué)完全不用看文字說(shuō)明。3.2 核心流程預(yù)約掛號(hào)的完整鏈路這部分的代碼實(shí)現(xiàn)是整個(gè)項(xiàng)目里最重要的閉環(huán)。搭好了它其他功能都是在這個(gè)模式上做的加減法。我直接說(shuō)關(guān)鍵實(shí)現(xiàn)。第一步登錄與OpenID換取。小程序端調(diào)用wx.login()拿到臨時(shí)code傳給后端后端拿這個(gè)code加上小程序的AppID和AppSecret調(diào)用微信的code2Session接口換回用戶的openid和session_key。OpenID是用戶在微信生態(tài)里的唯一身份標(biāo)識(shí)后端拿它去匹配本地用戶表首次登錄自動(dòng)注冊(cè)完成綁定手機(jī)號(hào)的用戶就直接進(jìn)首頁(yè)。這個(gè)流程要注意APP_SECRET絕對(duì)不能暴露在小程序代碼里所有換取操作必須走服務(wù)端源碼一旦泄露攻擊者可以偽造任意用戶的登錄身份。第二步查詢排班和號(hào)源。后端提供兩個(gè)接口GET /api/doctors/id/schedule?date...返回指定日期范圍內(nèi)的排班GET /api/schedules/id/slots返回某個(gè)排班下所有時(shí)段的號(hào)源狀態(tài)。小程序拿到號(hào)源列表后只渲染狀態(tài)為可約的時(shí)段。第三步提交掛號(hào)請(qǐng)求。前端提交的數(shù)據(jù)包括排班ID、號(hào)源ID、患者就診人ID。后端在事務(wù)里執(zhí)行鎖定號(hào)源、創(chuàng)建掛號(hào)單、生成支付訂單、返回待支付訂單號(hào)。這里有個(gè)很關(guān)鍵的冪等設(shè)計(jì)同一個(gè)號(hào)源ID在300秒內(nèi)的重復(fù)提交請(qǐng)求直接返回已有訂單防止前端超時(shí)重試導(dǎo)致重復(fù)下單。第四步調(diào)起微信支付。前端拿到后端生成的預(yù)支付訂單參數(shù)后調(diào)用wx.requestPayment()彈出支付面板。用戶輸入密碼完成支付微信服務(wù)器向你的支付回調(diào)地址推送異步通知后端驗(yàn)證簽名后把支付狀態(tài)改為已支付再把掛號(hào)單狀態(tài)從待支付改為待就診。第五步就診狀態(tài)流轉(zhuǎn)。患者到院后可以在小程序里看到自己的候診序號(hào)醫(yī)生點(diǎn)擊開(kāi)始就診后患者的就診狀態(tài)變?yōu)榫驮\中結(jié)束后變?yōu)橐淹瓿?。整個(gè)鏈路閉合每一步都有操作記錄可追溯。3.3 醫(yī)生端與Admin管理后臺(tái)最小可用版本醫(yī)生端我偷懶直接復(fù)用了小程序前端的一部分頁(yè)面沒(méi)有單獨(dú)做App。醫(yī)生登錄后看到的是當(dāng)天的排班卡片點(diǎn)擊進(jìn)入后展示患者列表每位患者顯示姓名脫敏保留姓末位、掛號(hào)時(shí)段、候診序號(hào)。醫(yī)生按順序點(diǎn)擊叫號(hào)患者小程序端會(huì)通過(guò)訂閱消息收到叫號(hào)提示。這個(gè)功能量級(jí)對(duì)一家醫(yī)院來(lái)說(shuō)基本夠用醫(yī)生不需要額外培訓(xùn)會(huì)點(diǎn)手機(jī)就會(huì)操作。管理后臺(tái)用Django Admin做二次開(kāi)發(fā)重點(diǎn)在三個(gè)頁(yè)面。排班管理頁(yè)面支持按周視圖批量生成排班選擇一個(gè)醫(yī)生、設(shè)置周一到周五的出診時(shí)間段系統(tǒng)自動(dòng)在后臺(tái)生成對(duì)應(yīng)時(shí)段的號(hào)源記錄這一步把醫(yī)院排班員從手工一條條錄號(hào)源中解放出來(lái)了。數(shù)據(jù)統(tǒng)計(jì)頁(yè)面直接寫SQL聚合統(tǒng)計(jì)各科室每日掛號(hào)和退號(hào)量、醫(yī)生退號(hào)率、患者爽約率。導(dǎo)出功能用pandas加openpyxl生成Excel報(bào)表支持按項(xiàng)目周期篩選支持權(quán)限控制。4. 技術(shù)難點(diǎn)復(fù)盤支付回調(diào)、消息推送與并發(fā)控制4.1 微信支付回調(diào)冪等性是我被坑得最慘的地方微信支付回調(diào)是整個(gè)系統(tǒng)里最容易出線上事故的環(huán)節(jié)。微信服務(wù)器的策略是你的回調(diào)接口如果在5秒內(nèi)沒(méi)返回成功或者返回的不是合法JSON它會(huì)自動(dòng)重試最多重試15次間隔時(shí)間遞增。很多人第一次寫回調(diào)接口時(shí)直接寫了修改訂單狀態(tài)為已支付然后一上線就發(fā)現(xiàn)兩個(gè)問(wèn)題第一回調(diào)重復(fù)觸發(fā)導(dǎo)致?tīng)顟B(tài)被反復(fù)翻改第二用戶支付成功了但你沒(méi)處理完回調(diào)就超時(shí)用戶錢扣了掛號(hào)單還是待支付。正確的回調(diào)處理姿勢(shì)是第一步驗(yàn)簽。用微信支付平臺(tái)證書驗(yàn)證回調(diào)消息的簽名防止偽造通知。第二步按微信支付商戶訂單號(hào)和交易號(hào)去查本地支付訂單是否存在不存在則返回失敗讓微信重試。第三步冪等校驗(yàn)——如果訂單狀態(tài)已經(jīng)是已支付/已退款直接返回成功不再重復(fù)處理。第四步開(kāi)啟事務(wù)同時(shí)更新支付訂單狀態(tài)和掛號(hào)單狀態(tài)。第五步返回微信約定的成功報(bào)文{code: SUCCESS}。這五步順序錯(cuò)了任何一步都會(huì)在你上線后變成線上事故。4.2 訂閱消息小程序里最實(shí)用的觸達(dá)手段患者掛完號(hào)之后怎么提醒怎么告訴醫(yī)生來(lái)新患者了微信對(duì)小程序TemplateMessage做了改版現(xiàn)在叫訂閱消息。規(guī)則是一次訂閱授權(quán)只能向用戶下發(fā)一次消息。用戶若想每次掛號(hào)后都收到提醒就得在掛號(hào)確認(rèn)前反復(fù)用wx.requestSubscribeMessage()引導(dǎo)授權(quán)訂閱。實(shí)操中我的做法是掛號(hào)確認(rèn)頁(yè)設(shè)計(jì)兩個(gè)授權(quán)觸達(dá)點(diǎn)。第一個(gè)是在用戶點(diǎn)了確認(rèn)預(yù)約但還沒(méi)支付時(shí)彈一個(gè)訂閱授權(quán)請(qǐng)求就診提醒的消息模板第二個(gè)是支付成功頁(yè)面再請(qǐng)求預(yù)約成功通知。這樣用戶一次掛了號(hào)就能合法下發(fā)兩條消息。很多產(chǎn)品的訂閱率低問(wèn)題往往出在授權(quán)時(shí)機(jī)不對(duì)——不是在用戶最需要消息觸達(dá)的時(shí)刻彈窗而是在用戶根本不知道這條消息會(huì)怎么騷擾他的時(shí)候直接彈了授權(quán)框用戶自然一拒了之。微信對(duì)訂閱消息的使用也有頻率審查如果你的系統(tǒng)惡意引導(dǎo)或者濫用會(huì)被封模板配額得不償失。認(rèn)真設(shè)計(jì)授權(quán)時(shí)機(jī)比多申請(qǐng)幾個(gè)模板資質(zhì)的價(jià)值大得多。4.3 頁(yè)面秒開(kāi)與弱網(wǎng)容錯(cuò)門診大廳的wifi可能比你家寬帶差多了醫(yī)院的網(wǎng)絡(luò)環(huán)境是我之前沒(méi)預(yù)料到的坑。三甲醫(yī)院門診大廳高峰期的無(wú)線網(wǎng)絡(luò)質(zhì)量很差人多、墻體厚、基建老舊小程序頁(yè)面經(jīng)常加載慢甚至白屏。這部分的優(yōu)化做了三件事。第一頁(yè)面靜態(tài)資源本地化。圖片、圖標(biāo)、公共組件庫(kù)盡量走小程序分包或本地包不發(fā)網(wǎng)絡(luò)請(qǐng)求。首頁(yè)的科室圖標(biāo)全部本地化只有醫(yī)生頭像這種必須傳到服務(wù)器的才走CDN。第二本地緩存策略結(jié)合過(guò)期時(shí)間?？剖伊斜?、醫(yī)生排班表這類變更頻率低的數(shù)據(jù)在本地緩存中存一份并帶上時(shí)間戳。下次進(jìn)入頁(yè)面先渲染緩存同時(shí)異步請(qǐng)求接口數(shù)據(jù)有變化再刷新視圖。參數(shù)上科室列表存24小時(shí)當(dāng)天排班存5分鐘。這樣患者第二次打開(kāi)小程序首頁(yè)幾乎秒開(kāi)。第三請(qǐng)求封裝統(tǒng)一處理弱網(wǎng)。給所有wx.request封裝一層自動(dòng)帶token、統(tǒng)一錯(cuò)誤提示、超時(shí)時(shí)間設(shè)置。網(wǎng)絡(luò)出錯(cuò)時(shí)把錯(cuò)誤信息可視化地反饋給用戶讓用戶知道是網(wǎng)絡(luò)問(wèn)題而不是小程序壞了能少一大半的客服電話。5. 部署上線與運(yùn)維實(shí)戰(zhàn)經(jīng)驗(yàn)5.1 服務(wù)器部署阿里云ECS Nginx uWSGI(Gunicorn)Python后端部署Django項(xiàng)目我推薦Nginx uWSGI(Gunicorn) 阿里云ECS MySQL的組合。原因很簡(jiǎn)單可靠、資料多、排障容易。我的習(xí)慣是先用uWSGI把Django應(yīng)用跑在本地端口比如8001再用Nginx做反向代理和靜態(tài)文件服務(wù)。部署前按慣例先關(guān)了Debug模式、配好ALLOWED_HOSTS、把SECRET_KEY換掉、開(kāi)啟HTTPS證書。這里要特別提醒一個(gè)新手最容易漏掉的步驟Django靜態(tài)文件收集。Django開(kāi)發(fā)環(huán)境能自動(dòng)處理靜態(tài)文件但一到生產(chǎn)環(huán)境所有靜態(tài)文件推薦用python manage.py collectstatic統(tǒng)一收集到STATIC_ROOT目錄再交給Nginx直接服務(wù)。第二步是設(shè)置CSRF_TRUSTED_ORIGINS加上自己的域名否則小程序里的POST請(qǐng)求會(huì)被403。數(shù)據(jù)庫(kù)方面項(xiàng)目推薦用MySQL字符集一定設(shè)utf8mb4排序規(guī)則設(shè)utf8mb4_unicode_ci這樣存用戶姓名的生僻字和特殊表情符號(hào)不出亂碼。后端ORM連MySQL時(shí)別忘了配置CONN_MAX_AGE持久連接參數(shù)否則每個(gè)請(qǐng)求都新建數(shù)據(jù)庫(kù)連接高峰期會(huì)直接把MySQL連接數(shù)打爆。5.2 HTTPS證書與小程序合法域名微信小程序有個(gè)鐵律所有請(qǐng)求域名必須是HTTPS而且必須在小程序管理后臺(tái)配置合法域名。開(kāi)發(fā)時(shí)可以在開(kāi)發(fā)者工具里勾選不校驗(yàn)合法域名但上線前必須把Request域名、UploadFile域名、Download域名都配置全。證書我推薦直接用阿里云免費(fèi)版DV證書或者用Certbot自動(dòng)簽發(fā)Lets Encrypt證書一年一續(xù)別忘了加個(gè)定時(shí)任務(wù)自動(dòng)續(xù)期。一個(gè)很少人提的細(xì)節(jié)是微信小程序?qū)φ?qǐng)求域名還有速率和頻率限制。如果你的某個(gè)接口被頻繁調(diào)用微信會(huì)直接攔截并提示request:fail url not in domain list或者網(wǎng)絡(luò)異常。上線后一定要做接口限流防止個(gè)別用戶的異常操作拖垮整個(gè)服務(wù)。5.3 運(yùn)維監(jiān)控日志、報(bào)警、備份醫(yī)院系統(tǒng)的特點(diǎn)是業(yè)務(wù)不能斷。運(yùn)維層面的三件套日志集中收集、監(jiān)控報(bào)警、數(shù)據(jù)庫(kù)自動(dòng)備份。日志我用loguru做Python日志配合cron定時(shí)切割歸檔避免日志文件無(wú)限膨脹。監(jiān)控報(bào)警用阿里云的云監(jiān)控對(duì)CPU、內(nèi)存、磁盤、數(shù)據(jù)庫(kù)連接數(shù)做告警閾值設(shè)置。數(shù)據(jù)庫(kù)備份我寫了兩個(gè)腳本每天凌晨2點(diǎn)全量備份一次MySQL中午再增量備一次備份文件自動(dòng)同步到OSS對(duì)象存儲(chǔ)。上線后發(fā)生過(guò)一次實(shí)例宕機(jī)2天內(nèi)靠備份恢復(fù)到了丟失數(shù)據(jù)前1小時(shí)的狀態(tài)這是真實(shí)教訓(xùn)。6. 常見(jiàn)問(wèn)題與避坑總結(jié)6.1 小程序真機(jī)調(diào)試的坑本地環(huán)境與線上域名切換開(kāi)發(fā)時(shí)后端跑在本機(jī)HTTP小程序開(kāi)發(fā)者工具能正常訪問(wèn)但真機(jī)預(yù)覽就全崩。原因是手機(jī)無(wú)法訪問(wèn)你電腦上的localhost。解決方法是開(kāi)發(fā)階段在工具里勾選不校驗(yàn)合法域名真機(jī)調(diào)試時(shí)用局域網(wǎng)的電腦IP或者干脆直接用內(nèi)網(wǎng)穿透工具暴露本地后端服務(wù)。上線前記得把這些配置都統(tǒng)一切到線上域名不要留在代碼里寫死。6.2 DjangoCORS跨域問(wèn)題小程序前端和后端域名不同會(huì)產(chǎn)生跨域問(wèn)題。雖然微信小程序的網(wǎng)絡(luò)請(qǐng)求不受瀏覽器同源策略限制但管理后臺(tái)的網(wǎng)頁(yè)版可能會(huì)踩。配置Django的django-cors-headers把允許的域名列表填進(jìn)去加上CORS_ALLOW_CREDENTIALS True支持?jǐn)y帶憑證。這個(gè)坑通常在開(kāi)發(fā)階段不出現(xiàn)部署后前端一上就報(bào)跨域錯(cuò)誤排查起來(lái)特別費(fèi)時(shí)間。6.3 并發(fā)扣減號(hào)源還是超賣怎么辦如果用了select_for_update和條件更新還是有偶發(fā)超賣我建議把扣減操作收口到同一個(gè)服務(wù)節(jié)點(diǎn)處理配合Redis分布式鎖做二次校驗(yàn)。Redis鎖設(shè)計(jì)成鎖的key是號(hào)源IDvalue是請(qǐng)求唯一ID設(shè)置過(guò)期時(shí)間防止死鎖。每次扣減前先拿鎖拿到鎖后再次檢查號(hào)源狀態(tài)然后扣減釋放鎖。數(shù)據(jù)庫(kù)層做最終一致Redis層做并發(fā)控制雙保險(xiǎn)。6.4 小程序?qū)徍吮痪艿某Ｒ?jiàn)原因醫(yī)療類小程序?qū)徍撕車?yán)格。如果小程序涉及在線支付類目必須是醫(yī)療-就醫(yī)服務(wù)需要提供醫(yī)療機(jī)構(gòu)執(zhí)業(yè)許可證等資質(zhì)文件。另外小程序內(nèi)不能出現(xiàn)首診承諾、不能做疾病診斷結(jié)論、不能宣傳療效。你的內(nèi)容不要繞過(guò)審核、不要做虛假宣傳。提前把這些合規(guī)問(wèn)題處理了審核周期能縮短一半。6.5 Django版本選擇別用最新版用穩(wěn)定版很多教程一上來(lái)就是最新版Django但我個(gè)人強(qiáng)烈建議項(xiàng)目用Django 4.2 LTS或5.0 LTS版本不要追新。LTS版本有長(zhǎng)期安全補(bǔ)丁支持社區(qū)生態(tài)兼容性最好。Flask同理選2.x穩(wěn)定版。Python版本用3.10或3.11。這個(gè)組合在2024年到2025年之間是穩(wěn)定且資料最多的踩坑時(shí)能搜到的答案也最豐富。6.6 微信支付的退款接口退款也是高頻需求。用戶掛錯(cuò)號(hào)要退醫(yī)生停診要退。微信支付退款接口是同步返回受理結(jié)果的但實(shí)際退到用戶賬戶零錢是實(shí)時(shí)的退到銀行卡會(huì)T1或更久。后端處理退款時(shí)有兩個(gè)注意點(diǎn)一是退款需要退款單號(hào)確保退款單號(hào)唯一二是退款接口同樣要做冪等防止重復(fù)退款把用戶的錢退兩次。退款回調(diào)通知同樣要驗(yàn)簽處理邏輯照搬支付回調(diào)那套。7. 我的實(shí)操體會(huì)與后續(xù)擴(kuò)展建議7.1 這個(gè)項(xiàng)目做下來(lái)我最大的感受是什么先說(shuō)結(jié)論一個(gè)看似簡(jiǎn)單的門診掛號(hào)小程序真正開(kāi)發(fā)的難點(diǎn)不在某一個(gè)技術(shù)點(diǎn)上而在把醫(yī)院里的人、流程、規(guī)則翻譯成代碼的過(guò)程。需求表面上是掛號(hào)背后卻是醫(yī)院排班規(guī)則停診改診怎么處理、號(hào)源容量每個(gè)時(shí)段放多少號(hào)、醫(yī)生資質(zhì)哪些科室必須線下首診不能在線掛號(hào)這些業(yè)務(wù)規(guī)則的深度耦合。寫得再漂亮的代碼不貼合這些真實(shí)規(guī)則上線也是廢的。我的建議是無(wú)論你是練手還是真接項(xiàng)目動(dòng)手寫代碼之前至少去醫(yī)院掛號(hào)窗口蹲半天觀察患者的問(wèn)題、窗口人員的操作步驟、退號(hào)改號(hào)的流程。這半天給你的業(yè)務(wù)理解比看十篇技術(shù)博客都管用。7.2 后續(xù)可以怎么擴(kuò)展這個(gè)系統(tǒng)做完之后的擴(kuò)展空間很大。方向上可以加患者的電子健康檔案模塊醫(yī)生可以查看患者歷史就診記錄和歷次處方檢驗(yàn)檢查結(jié)果查詢患者做完檢驗(yàn)后小程序直接推送報(bào)告省得打印窗口排隊(duì)候診排隊(duì)叫號(hào)大屏的對(duì)接把虛擬叫號(hào)搬到候診區(qū)的電視屏幕上在線問(wèn)診圖文咨詢模塊把復(fù)診續(xù)方這個(gè)需求承接住患者在線上跟醫(yī)生聊幾句就能拿到續(xù)方。技術(shù)上還可以把Django后端拆成微服務(wù)掛號(hào)服務(wù)單獨(dú)部署用消息隊(duì)列削峰填谷處理號(hào)源搶購(gòu)的突發(fā)流量。7.3 最后分享一個(gè)壓箱底的小技巧如果你發(fā)現(xiàn)用戶經(jīng)常在選擇時(shí)間段的頁(yè)面流失不要急著改UI。先把用戶的操作日志打出來(lái)看看他到底卡在哪一步。我當(dāng)時(shí)查日志發(fā)現(xiàn)很多用戶是選擇了日期但當(dāng)天醫(yī)生正好停診整個(gè)排班區(qū)是空的頁(yè)面看起來(lái)像壞了。后來(lái)我在空狀態(tài)加了一句話今日無(wú)號(hào)源請(qǐng)選擇其他日期流失率立刻降了三分之一。很多時(shí)候產(chǎn)品的轉(zhuǎn)化問(wèn)題不是技術(shù)問(wèn)題而是信息反饋的問(wèn)題。這句話送給所有正在做這類系統(tǒng)的朋友。