醫(yī)院就診管理系統(tǒng)、在線問診系統(tǒng)這個組合我這兩年至少被問到二十次。很多人一上來就問PythonFlaskVue能不能做 我的回答是這套技術(shù)棧做醫(yī)療問診類系統(tǒng)非常合適而且是最容易短時間跑通全流程的組合之一。它解決的痛點(diǎn)也很明確線下門診的掛號、候診、接診、診斷、開方這些環(huán)節(jié)全部搬到線上患者不用排隊醫(yī)生能在后臺批量處理問診請求。這篇東西寫給三類人要做畢設(shè)或課設(shè)的同學(xué)、想給小型診所或內(nèi)部科室搭一個輕量問診原型的開發(fā)者、以及準(zhǔn)備學(xué)前后端分離項目但還沒選好題目的新手。我會把從數(shù)據(jù)庫設(shè)計到前端聯(lián)調(diào)、再到部署避坑的完整過程都拆開講盡量少說空話。我用這個標(biāo)題做了好幾輪迭代踩過的坑比想象的要多。最典型的就是以為在線問診就是個聊天室結(jié)果做著做著發(fā)現(xiàn)在問診狀態(tài)流轉(zhuǎn)、消息實(shí)時性、處方數(shù)據(jù)與病歷數(shù)據(jù)聯(lián)動這些地方每個環(huán)節(jié)都能讓人卡住好幾天。這篇文章我按自己的開發(fā)順序來先梳理業(yè)務(wù)再定表結(jié)構(gòu)然后后端接口、前端頁面最后聊部署和問題排查。你照著這個路徑走基本不會出現(xiàn)模塊做完了但拼不起來的情況。1. 項目拆解在線問診系統(tǒng)到底在管哪些事1.1 線下門診流程搬到線上的關(guān)鍵映射做任何管理系統(tǒng)第一件事不是寫代碼而是把業(yè)務(wù)流程捋清楚。醫(yī)院就診系統(tǒng)和一般的信息管理系統(tǒng)有個很大的不同它存在一條強(qiáng)約束的流程鏈路?；颊卟皇沁M(jìn)來隨便找個醫(yī)生聊天就行而是要經(jīng)歷選科室 - 選醫(yī)生 - 發(fā)起問診 - 醫(yī)生接診 - 在線交流 - 給出診斷與建議 - 開具處方 - 結(jié)束問診這樣的完整路徑。我第一次做的時候上來就建了一張message表和一個doctor表以為把聊天和醫(yī)生信息搞定就完了。結(jié)果做到一半才發(fā)現(xiàn)完全不是那么回事如果沒有問診單這個概念聊天記錄和醫(yī)生、患者的對應(yīng)關(guān)系就是亂的診斷和處方也沒地方掛靠。所以我在第二版設(shè)計里加了一張核心的consultation問診單表把整個流程的狀態(tài)都掛在它上面。這里你只要記住一個要點(diǎn)在線問診系統(tǒng)本質(zhì)上是一個訂單系統(tǒng)?；颊甙l(fā)起問診生成一張問診單醫(yī)生的接診、消息交流、開處方、結(jié)束問診都圍繞這張單子做狀態(tài)變更。想通了這一點(diǎn)后面的表設(shè)計和接口設(shè)計都會順暢很多。這也是為什么我建議所有人在建表之前先在紙上把這套狀態(tài)流轉(zhuǎn)畫出來。1.2 功能模塊與三角色權(quán)限劃分在線問診系統(tǒng)的使用者最少要有三類角色患者、醫(yī)生、管理員。每類角色看到的頁面和能操作的接口完全不一樣所以系統(tǒng)的功能模塊也要按角色來劃分。患者端核心功能是注冊登錄、瀏覽科室與醫(yī)生列表、發(fā)起問診、與醫(yī)生在線交流、查看問診記錄和電子處方。醫(yī)生端則包括查看待接診列表、接診處理、在會話中與患者溝通、填寫診斷和處方、管理自己的問診記錄。管理員端更偏向基礎(chǔ)數(shù)據(jù)維護(hù)科室管理、醫(yī)生信息管理、統(tǒng)計報表比如各科室問診量。權(quán)限管理不用做得太復(fù)雜但必須做。我的方案是user表里存一個role字段前端用路由守衛(wèi)攔截后端在接口里做角色校驗。前后端兩層都校驗才能避免繞過前端直接調(diào)用接口的問題。角色主要功能典型頁面患者掛號/發(fā)起問診、圖文咨詢、查看病歷、查看處方科室列表、醫(yī)生詳情、問診會話、處方詳情醫(yī)生接診、在線答復(fù)、寫診斷、開處方待接診列表、會話窗口、病歷填寫頁管理員科室與醫(yī)生管理、基礎(chǔ)數(shù)據(jù)維護(hù)科室管理、醫(yī)生審核、統(tǒng)計面板模塊理順之后你會發(fā)現(xiàn)頁面結(jié)構(gòu)也變得清晰。前端先按角色分路由再按功能分組件Vue的優(yōu)勢就體現(xiàn)出來了。1.3 為什么這套場景適合Flask VueFlask在整個Python后端生態(tài)里屬于輕量快跑的類型。它不像Django那樣自帶一整套Admin后臺和ORM約定但正因為輕后端結(jié)構(gòu)可以由你自己掌控接口怎么寫、模塊怎么拆自由度很高。對一個問診系統(tǒng)來說核心業(yè)務(wù)是RESTful接口和狀態(tài)流轉(zhuǎn)Flask的Blueprint加上SQLAlchemy完全夠用不需要重型框架。Vue這邊組件化開發(fā)非常適合問診這種強(qiáng)交互的場景。患者問診會話窗口、醫(yī)生病歷填寫表單、消息列表每個頁面都是典型的多組件組合。用Vue Router做頁面路由用Pinia或Vuex管理登錄態(tài)和用戶信息配合Element Plus組件庫開發(fā)速度非常快。還有一點(diǎn)是就業(yè)和學(xué)習(xí)生態(tài)。Python和Vue都是目前使用面極廣的技術(shù)棧做完這個項目以后簡歷上寫Flask后端開發(fā)或Vue前端開發(fā)都拿得出手。而換成Spring Boot那套雖然企業(yè)級程度更高但對剛?cè)腴T的人來說光是環(huán)境配置和Maven依賴就能勸退一批人。在線問診這種體量FlaskVue是投入產(chǎn)出比最高的方案之一。2. 后端Flask接口、數(shù)據(jù)模型與問診狀態(tài)機(jī)2.1 數(shù)據(jù)庫表設(shè)計核心五張表一次說清數(shù)據(jù)庫設(shè)計是這套系統(tǒng)真正的骨架。我最終采用的表結(jié)構(gòu)大概是這樣的表名作用關(guān)鍵字段user登錄賬號與全局角色id, username, password_hash, role, created_atdoctor醫(yī)生擴(kuò)展信息id, user_id, dept_id, name, title, introdepartment科室id, name, descriptionconsultation問診單id, patient_id, doctor_id, status, chief_complaint, diagnosis, advicemessage在線消息id, consultation_id, sender_type, content, is_read, created_atprescription處方主表id, consultation_id, summary, created_atprescription_item處方明細(xì)id, prescription_id, drug_name, dosage, frequency這里需要特別強(qiáng)調(diào)幾個設(shè)計細(xì)節(jié)。第一個是用戶和醫(yī)生分開存儲。user表作為所有角色的登錄憑證doctor表存醫(yī)生特有的業(yè)務(wù)信息所屬科室、職稱、簡介。為什么要分開因為一個用戶可能先以患者身份注冊以后他又被管理員加為醫(yī)生如果所有信息都堆在同一張表要么字段冗余要么改角色的時候異常麻煩。分開之后user表承擔(dān)身份認(rèn)證doctor表承擔(dān)業(yè)務(wù)擴(kuò)展。第二個是密碼絕不能用明文。我在user表里用的是password_hash字段配合werkzeug.security的generate_password_hash和check_password_hash對密碼進(jìn)行不可逆的哈希存儲。登錄時只做哈希比對即使數(shù)據(jù)庫備份泄露也不會直接暴露明文密碼。第三個是問診單的status字段類型是字符串取值限制在四個狀態(tài)之間pending待接診、ongoing問診中、finished已結(jié)束、cancelled已取消。字符串比數(shù)字枚舉更直觀查數(shù)據(jù)的時候一眼能看出狀態(tài)含義調(diào)試也方便。2.2 接口設(shè)計RESTful風(fēng)格與統(tǒng)一返回結(jié)構(gòu)后端接口我全部走RESTful風(fēng)格資源用名詞動作用HTTP方法。比如方法路徑功能角色POST/api/auth/register注冊公開POST/api/auth/login登錄公開GET/api/departments科室列表登錄用戶GET/api/doctors?dept_id1按科室查醫(yī)生登錄用戶POST/api/consultations發(fā)起問診患者GET/api/consultations/patient我的問診列表患者GET/api/consultations/doctor醫(yī)生工作臺列表醫(yī)生POST/api/consultations/ /accept接診醫(yī)生POST/api/consultations/ /finish結(jié)束問診醫(yī)生GET/api/messages?consultation_id1消息記錄雙方POST/api/prescriptions開具處方醫(yī)生統(tǒng)一返回結(jié)構(gòu)我強(qiáng)烈建議從一開始就定好不然后端前端各寫各的聯(lián)調(diào)階段一定吵架。我的格式是{ code: 0, msg: success, data: {} }code為0表示成功非0表示業(yè)務(wù)錯誤比如參數(shù)缺失、無權(quán)限、狀態(tài)不允許操作。前端axios攔截器里統(tǒng)一判斷code不是0就直接彈出msg提示減少了大量重復(fù)的異常處理代碼。Flask里用藍(lán)圖來組織接口一個模塊一個藍(lán)圖代碼結(jié)構(gòu)會清晰很多from flask import Blueprint, request, jsonify auth_bp Blueprint(auth, __name__) auth_bp.route(/register, methods[POST]) def register(): data request.get_json() username data.get(username) password data.get(password) if not username or not password: return jsonify(code1, msg用戶名和密碼不能為空), 400 # 業(yè)務(wù)邏輯檢查用戶名是否已存在、創(chuàng)建User記錄 ... return jsonify(code0, msgsuccess, data{user_id: user.id})2.3 問診狀態(tài)機(jī)與并發(fā)控制問診單的狀態(tài)流轉(zhuǎn)是有方向的不能亂跳。我的規(guī)則只有四條新建的單子是pending醫(yī)生接診后變?yōu)閛ngoing醫(yī)生結(jié)束問診后變?yōu)閒inished只有pending狀態(tài)的單子可以被取消取消后變?yōu)閏ancelled。狀態(tài)機(jī)的代碼實(shí)現(xiàn)不難但并發(fā)問題很容易被忽略。新手常見的坑是兩個醫(yī)生同時打開了同一個問診單然后都點(diǎn)了接診結(jié)果一個單子被兩個醫(yī)生接走。解決思路是在數(shù)據(jù)庫層面做條件更新而不是先查詢再更新from models import db, Consultation # 只有當(dāng)前狀態(tài)是 pending 時才允許接診 result Consultation.query.filter_by( idconsult_id, statuspending ).update({ status: ongoing, doctor_id: current_doctor_id }) db.session.commit() if result 0: return jsonify(code1, msg該問診單已被其他醫(yī)生接診), 409這里的關(guān)鍵是update方法返回的行數(shù)。如果返回0說明更新時已經(jīng)不滿足statuspending這個條件說明別人搶先了。這種做法在數(shù)據(jù)庫層面鎖住了狀態(tài)變更不用額外引入Redis鎖對小型系統(tǒng)來說簡單又可靠。我建議問診單狀態(tài)的所有變更都走這個模式先filter_by帶上舊狀態(tài)條件再更新成新狀態(tài)提交后檢查受影響行數(shù)。這樣就算后續(xù)加了預(yù)約、排隊等復(fù)雜功能狀態(tài)也不會輕易亂掉。3. 前端Vue頁面組織與交互鏈路3.1 Vite Router Element Plus的項目骨架前端工程我用的是Vite Vue 3 Vue Router Pinia Element Plus這一套組合。Vite相比Webpack配置少很多啟動速度快非常適合開發(fā)迭代頻繁的頁面。創(chuàng)建工程很簡單npm create vitelatest hospital-front cd hospital-front npm install npm install vue-router4 pinia element-plus axios裝完依賴之后第一件事是配路由。在線問診系統(tǒng)的頁面按角色劃分我建議在路由meta里直接聲明需要的角色然后通過全局守衛(wèi)攔截這樣權(quán)限判斷集中在一個地方const routes [ { path: /, component: Home }, { path: /login, component: Login, meta: { guest: true } }, { path: /patient, component: PatientLayout, meta: { role: patient }, children: [ { path: departments, component: DepartmentList }, { path: doctors/:deptId, component: DoctorList }, { path: consult/:doctorId, component: StartConsult }, { path: records, component: PatientRecords } ] }, { path: /doctor, component: DoctorLayout, meta: { role: doctor }, children: [ { path: workbench, component: DoctorWorkbench }, { path: session/:consultId, component: DoctorSession } ] } ] router.beforeEach((to, from, next) { const token localStorage.getItem(token) const role localStorage.getItem(role) if (to.meta.role to.meta.role ! role) { next(/login) } else if (!token !to.meta.guest) { next(/login) } else { next() } })有了路由守衛(wèi)前端就能擋住未登錄用戶和角色越權(quán)訪問。后端接口再做一層校驗雙保險基本夠用。3.2 患者端頁面掛號、發(fā)起問診、查看處方患者端的鏈路看起來簡單但頁面流轉(zhuǎn)是有狀態(tài)的。我的頁面順序是這樣的患者登錄后進(jìn)入科室列表頁點(diǎn)擊某個科室進(jìn)入醫(yī)生列表再點(diǎn)擊某個醫(yī)生進(jìn)入醫(yī)生詳情與發(fā)起問診頁填寫主訴之后提交問診單然后跳轉(zhuǎn)到問診會話頁。發(fā)起問診的表單是整個患者端的核心我設(shè)計了這幾個字段就診類型圖文問診、病情描述必填、補(bǔ)充信息選填比如持續(xù)時間、是否用藥以及一個簡單的上次就診情況文本域。主訴最好讓用戶寫得具體一些所以我在前端做了字?jǐn)?shù)校驗最少10個字避免患者只輸入頭疼兩個字就讓醫(yī)生接診這樣對醫(yī)生端非常不友好。這里要提醒一下表單校驗一定要前后端都做。前端做提示方便用戶后端做校驗防止有人繞過頁面直接調(diào)接口寫臟數(shù)據(jù)。我的做法是后端用一個獨(dú)立的請求體校驗流程字段缺失直接返回400。3.3 醫(yī)生端待接診列表、會話與病歷填寫醫(yī)生端的工作臺更像一個任務(wù)隊列。我用的是卡片列表形式待接診、問診中、已完成三個Tab切換。待接診卡片上只顯示患者的主訴摘要和發(fā)起時間醫(yī)生點(diǎn)接診按鈕后卡片狀態(tài)變成問診中然后進(jìn)入會話頁。醫(yī)生會話頁包含三塊區(qū)域左側(cè)是患者的基本信息與主訴中間是消息聊天窗口右側(cè)是病歷/處方操作區(qū)。為何要做成三欄因為醫(yī)生在工作時習(xí)慣一邊看患者病史、一邊看當(dāng)前消息、一邊寫結(jié)論三者同時展示可以減少不必要的頁面跳轉(zhuǎn)。病歷填寫區(qū)我做了這么幾個表單項初步診斷、診斷說明、處理建議、是否開處方。是否開處方用了一個開關(guān)組件打開后動態(tài)出現(xiàn)處方明細(xì)表格每行包含藥品名稱、用法、用量醫(yī)生可以點(diǎn)添加一行繼續(xù)增加。這個動態(tài)表單用Vue的v-for渲染非常好寫具體代碼后面章節(jié)會提到。4. 在線問診核心功能從發(fā)起到結(jié)束的完整鏈路4.1 發(fā)起問診與接診流程的實(shí)現(xiàn)完整的問診鏈路后端涉及三個關(guān)鍵接口創(chuàng)建問診單、接診、結(jié)束問診。創(chuàng)建問診單時前端把doctorId、chiefComplaint、description這些字段傳過來。后端要做的事情是校驗doctorId對應(yīng)的醫(yī)生是否存在校驗當(dāng)前患者是否已經(jīng)有處于pending或ongoing狀態(tài)的問診單防止重復(fù)創(chuàng)建然后插入一條status為pending的記錄。接診接口就是我們前面說的條件更新把問診單從pending改為ongoing同時把doctorId綁定到當(dāng)前登錄醫(yī)生。這樣做不僅防止并發(fā)重復(fù)接診也保證每條問診單都有明確的接診醫(yī)生。結(jié)束問診的接口會稍微復(fù)雜一些它要同時做三件事把問診單狀態(tài)從ongoing改為finished保存診斷和建議文本如果醫(yī)生開了處方還要把處方主表和明細(xì)一起寫庫。為了保證數(shù)據(jù)不出現(xiàn)半成品比如狀態(tài)改了但處方?jīng)]存上我把這三個操作放在一個事務(wù)里。Flask-SQLAlchemy里事務(wù)的使用非常直接from models import db, Consultation, Prescription, PrescriptionItem def finish_consultation(consult_id, doctor_id, payload): consult Consultation.query.filter_by( idconsult_id, doctor_iddoctor_id, statusongoing ).first() if not consult: raise BusinessError(問診單不存在或已結(jié)束) consult.diagnosis payload.get(diagnosis) consult.advice payload.get(advice) consult.status finished if payload.get(drugs): prescription Prescription(consultation_idconsult.id, summarypayload.get(summary, )) db.session.add(prescription) db.session.flush() for item in payload[drugs]: db.session.add(PrescriptionItem( prescription_idprescription.id, drug_nameitem[name], dosageitem[dosage], frequencyitem[frequency] )) db.session.commit()用db.session.flush()獲取自增主鍵后再寫明細(xì)這招在處理主從表數(shù)據(jù)時非常常用。flush會把數(shù)據(jù)發(fā)送到數(shù)據(jù)庫拿到ID但不會提交事務(wù)所以后續(xù)插入失敗還能整體回滾。4.2 實(shí)時消息選輪詢還是WebSocket在線問診最核心的交互就是消息。消息功能有兩條技術(shù)路線簡單輪詢和WebSocket。如果只是為了完成畢設(shè)或者演示原型輪詢完全可行。前端每隔3到5秒調(diào)用一次消息接口把新消息拉取出來渲染。實(shí)現(xiàn)簡單、部署方便也不依賴額外的連接管理。缺點(diǎn)是實(shí)時性一般而且患者和醫(yī)生同時在線時輪詢頻率高了會有一點(diǎn)無效請求。想做出真正像微信聊天的體驗更推薦WebSocket方案。Flask這邊用Flask-SocketIO前端用socket.io-client事件驅(qū)動雙向?qū)崟r通信。服務(wù)端核心可以這樣寫from flask_socketio import SocketIO, emit, join_room socketio SocketIO(app, cors_allowed_origins*) socketio.on(join_consult) def on_join(data): # 以問診單ID作為房間名 join_room(data[consult_id]) socketio.on(send_message) def handle_message(data): # 保存消息到數(shù)據(jù)庫 save_message(data) # 廣播給房間內(nèi)所有客戶端 emit(receive_message, data, roomdata[consult_id])前端這邊在進(jìn)入會話頁的時候連接WebSocket并加入對應(yīng)的房間。我實(shí)際測試下來基于SocketIO的聊天延遲基本可以忽略患者發(fā)一條消息醫(yī)生端幾乎是秒收。不過要提醒你SocketIO的會話管理和HTTP的JWT認(rèn)證怎么打通是這里比較繞的一個點(diǎn)后面排查章節(jié)我會專門說這個問題。如果你決定用輪詢我也給一個可行方案前端只在會話頁存活期間輪詢頁面離開就停掉后端在消息表中加last_id參數(shù)前端每次都傳當(dāng)前最新消息的ID后端只返回比這個ID大的新消息。這樣每次輪詢的數(shù)據(jù)量都很小體驗雖然不如WebSocket但在課設(shè)里評分完全夠。4.3 電子病歷與處方數(shù)據(jù)如何落庫電子病歷和處方是和聊天截然不同的一類數(shù)據(jù)它們是結(jié)構(gòu)化的、有法律效應(yīng)的診療記錄不能像聊天記錄一樣隨便存。我的設(shè)計是診斷文本、處理建議存在consultation表上因為一次問診對應(yīng)一組輕量的診斷信息處方單獨(dú)拆成prescription主表和prescription_item明細(xì)表因為一張?zhí)幏娇赡馨喾N藥而且藥品明細(xì)未來可能要做庫存聯(lián)動或統(tǒng)計報表。前端在醫(yī)生填寫處方時我用了一個可擴(kuò)展的明細(xì)數(shù)組const drugs ref([{ name: , dosage: , frequency: }]) function addDrugRow() { drugs.value.push({ name: , dosage: , frequency: }) } function removeDrugRow(index) { drugs.value.splice(index, 1) }提交的時候?qū)rugs數(shù)組中的每條記錄作為對象傳給后端。后端的校驗要點(diǎn)是藥品名稱、用法、用量都不能為空藥品數(shù)量最多不要超過20條。之所以加這個限制是防止某個醫(yī)生極端操作時一次性提交上百條明細(xì)導(dǎo)致前端渲染卡頓。這里有個我踩過的坑藥品字段的長度一定要給夠。有些中藥或者組合用藥的備注說明非常長我曾經(jīng)把drug_name設(shè)計成varchar(50)結(jié)果醫(yī)生錄入注射用頭孢曲松鈉羅氏芬就超了。后來改成Text類型一勞永逸。凡是涉及人工自由輸入的字段類型盡量放寬圖片路徑字段也一樣。5. 實(shí)操復(fù)盤本地跑通這套系統(tǒng)要多久5.1 環(huán)境準(zhǔn)備與依賴清單有一說一搭環(huán)境是最容易勸退新手的環(huán)節(jié)但按步驟來其實(shí)半小時內(nèi)能搞定。后端我用Python 3.10Windows、macOS、Linux都行。建議一定用虛擬環(huán)境別直接裝到全局mkdir hospital-backend cd hospital-backend python -m venv venv source venv/bin/activate # Windows下執(zhí)行 venv\Scripts\activate pip install flask flask-sqlalchemy flask-cors flask-jwt-extended flask-socketio一個參考的requirements.txt大概是Flask3.0.0 flask-sqlalchemy3.1.2 flask-cors4.0.1 flask-jwt-extended4.6.0 flask-socketio5.3.6 gunicorn21.2.0前端部分Node.js版本建議18以上然后用Vite創(chuàng)建工程。遇到npm安裝慢就把registry切換成國內(nèi)鏡像源千萬別硬等。5.2 前后端聯(lián)調(diào)跨域與接口對接前后端分離項目最常見的聯(lián)調(diào)問題就是跨域。開發(fā)環(huán)境里Vite監(jiān)聽5173端口Flask監(jiān)聽5000端口兩個端口不同瀏覽器會攔截跨域請求。最省事的方法是在Vite的配置文件里加一個代理讓前端發(fā)請求的時候走同源路徑由Vite轉(zhuǎn)發(fā)到后端// vite.config.js export default { server: { port: 5173, proxy: { /api: { target: http://127.0.0.1:5000, changeOrigin: true } } } }這樣前端axios請求的baseURL寫成/api瀏覽器看到的就是5173上的相對路徑不存在跨域問題。后端同時用flask-cors加上全局CORS支持雙保險from flask_cors import CORS CORS(app, supports_credentialsTrue)不過要留意如果前端代理已經(jīng)配好后端CORS其實(shí)只在直接訪問5000端口調(diào)試時起作用所以兩者都配置屬于開發(fā)環(huán)境的基本配置。聯(lián)調(diào)時我都是先在瀏覽器Network面板里確認(rèn)請求發(fā)出去了、返回了什么再判斷是前端問題還是后端問題不要一看到報錯就改代碼。5.3 部署到服務(wù)器的輕量方案開發(fā)環(huán)境跑通之后部署又是一個分水嶺。這里我給一個適合小型項目的方案后端用Gunicorn啟動Flask前端打包后交給Nginx托管Nginx反向代理API請求。前端打包npm run build生成dist目錄后把dist里的文件上傳到服務(wù)器Nginx的html目錄。Nginx配置里最關(guān)鍵的是解決Vue Router的history模式刷新404問題加上try_filesserver { listen 80; server_name your_domain; root /var/www/hospital; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /socket.io/ { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }注意socket.io的WebSocket升級也需要Nginx放行否則線上環(huán)境聊天功能會退化。后端啟動命令用gunicorn -w 3 -b 127.0.0.1:8000 app:app數(shù)據(jù)庫在演示項目里可以直接用SQLite文件幾乎零配置。但如果你想體驗MySQL需要額外安裝PyMySQL并修改連接串。我的建議是原型階段直接用SQLite因為表結(jié)構(gòu)改動頻繁SQLite遷庫非常方便到了真正要上線演示給更多人用的時候再遷MySQL加個連接配置就行。6. 高頻問題排查與避坑實(shí)錄6.1 前后端聯(lián)調(diào)階段的高頻報錯下面這些報錯是我在做這個項目過程中真真實(shí)實(shí)遇到過的每一項都花了時間排查。常見現(xiàn)象根本原因解決辦法瀏覽器控制臺報CORS錯誤前端直接請求了5000端口沒有走代理把a(bǔ)xios baseURL改成/api確保請求走Vite代理POST請求到達(dá)后端但data是None前端沒有設(shè)置Content-Type: application/json在axios請求頭設(shè)置或直接JSON.stringify并在headers里標(biāo)明application/json登錄后刷新頁面就退出只存在了內(nèi)存里沒有持久化登錄后把token寫入localStorage路由守衛(wèi)里從localStorage讀取醫(yī)生接診后發(fā)現(xiàn)患者消息收不到雙方?jīng)]有加入同一個SocketIO房間檢查join_consult事件是否在進(jìn)入會話頁時執(zhí)行房間名是否統(tǒng)一用consult_id時間顯示差了8小時前后端時區(qū)不一致后端統(tǒng)一存UTC前端展示時用本地時間格式化6.2 數(shù)據(jù)一致性與并發(fā)問診的幾個坑在線問診的并發(fā)量雖然不如電商但并發(fā)誤操作出現(xiàn)的概率一點(diǎn)都不低。最典型的就是患者重復(fù)提交問診單用戶網(wǎng)絡(luò)卡頓連點(diǎn)兩次提交結(jié)果生成了兩條問診單。我的解決辦法是后端在創(chuàng)建接口里先查一下當(dāng)前患者是否有未結(jié)束的問診單existing Consultation.query.filter( Consultation.patient_id patient_id, Consultation.status.in_([pending, ongoing]) ).first() if existing: return jsonify(code1, msg你還有未完成的問診請先處理), 409另一個坑是醫(yī)生結(jié)束問診時前端已經(jīng)把狀態(tài)改成finished了但后端事務(wù)沒提交成功導(dǎo)致前端顯示已結(jié)束、數(shù)據(jù)庫還是ongoing。排查這種問題要養(yǎng)成一個習(xí)慣以數(shù)據(jù)庫為準(zhǔn)不要以頁面為準(zhǔn)。頁面顯示錯了可以刷新數(shù)據(jù)錯了就要寫修復(fù)腳本。所以在所有寫操作里事務(wù)提交后我都建議立刻讀取一遍最新狀態(tài)返回給前端讓前端以接口返回為準(zhǔn)。6.3 安全與權(quán)限的幾個容易忽略的點(diǎn)最后說說安全。醫(yī)院問診系統(tǒng)涉及患者健康信息安全級別天然要高一些但很多課設(shè)和原型項目在安全上做得一塌糊涂。我覺得最基本的幾條底線一定不能丟。第一密碼必須哈希存儲前面已經(jīng)強(qiáng)調(diào)過用werkzeug自帶的工具就行。第二所有需要登錄的接口都要校驗JWTFlask-JWT-Extended提供了現(xiàn)成的裝飾器比如jwt_required()。但要注意醫(yī)生患者的角色校驗要自己處理不能只驗證登錄就放行。第三患者只能查看自己的問診記錄醫(yī)生只能查看分配給自己的問診單。這個數(shù)據(jù)級權(quán)限很容易漏掉很多人寫接口時直接Consultation.query.all()返回全部記錄這是嚴(yán)重的越權(quán)漏洞。第四圖片上傳時一定要校驗文件后綴和大小我建議最多允許5MB只接受jpg、png、webp等白名單格式不要接收可執(zhí)行文件。安全這東西對一個小型項目來說不用做到企業(yè)級那么復(fù)雜但上述幾條屬于基本素質(zhì)哪怕課設(shè)也值得做好。因為這些不僅是代碼問題更是設(shè)計態(tài)度的體現(xiàn)。最后再分享一點(diǎn)我的實(shí)際體會做完這套系統(tǒng)我最大的感覺是醫(yī)療問診類項目的核心難點(diǎn)不在技術(shù)炫技而在于把狀態(tài)管住。問診單的狀態(tài)、消息的狀態(tài)、用戶登錄的狀態(tài)只要這三類狀態(tài)清晰系統(tǒng)就穩(wěn)了一半。另一條建議是不要讓實(shí)時聊天綁架你的開發(fā)節(jié)奏——如果時間緊張輪詢方案完全夠交付先把問診主鏈路跑通再考慮用SocketIO提升體驗。項目后續(xù)想擴(kuò)展還可以加排隊叫號、科室排班、藥品庫存管理、問診數(shù)據(jù)統(tǒng)計報表等功能基礎(chǔ)的表結(jié)構(gòu)和接口設(shè)計都能平滑支撐不會推翻重來。