醫(yī)院就診管理系統(tǒng)、在線問診系統(tǒng)這個(gè)組合我這兩年至少被問到二十次。很多人一上來就問PythonFlaskVue能不能做 我的回答是這套技術(shù)棧做醫(yī)療問診類系統(tǒng)非常合適而且是最容易短時(shí)間跑通全流程的組合之一。它解決的痛點(diǎn)也很明確線下門診的掛號(hào)、候診、接診、診斷、開方這些環(huán)節(jié)全部搬到線上患者不用排隊(duì)醫(yī)生能在后臺(tái)批量處理問診請求。這篇東西寫給三類人要做畢設(shè)或課設(shè)的同學(xué)、想給小型診所或內(nèi)部科室搭一個(gè)輕量問診原型的開發(fā)者、以及準(zhǔn)備學(xué)前后端分離項(xiàng)目但還沒選好題目的新手。我會(huì)把從數(shù)據(jù)庫設(shè)計(jì)到前端聯(lián)調(diào)、再到部署避坑的完整過程都拆開講盡量少說空話。我用這個(gè)標(biāo)題做了好幾輪迭代踩過的坑比想象的要多。最典型的就是以為在線問診就是個(gè)聊天室結(jié)果做著做著發(fā)現(xiàn)在問診狀態(tài)流轉(zhuǎn)、消息實(shí)時(shí)性、處方數(shù)據(jù)與病歷數(shù)據(jù)聯(lián)動(dòng)這些地方每個(gè)環(huán)節(jié)都能讓人卡住好幾天。這篇文章我按自己的開發(fā)順序來先梳理業(yè)務(wù)再定表結(jié)構(gòu)然后后端接口、前端頁面最后聊部署和問題排查。你照著這個(gè)路徑走基本不會(huì)出現(xiàn)模塊做完了但拼不起來的情況。1. 項(xiàng)目拆解在線問診系統(tǒng)到底在管哪些事1.1 線下門診流程搬到線上的關(guān)鍵映射做任何管理系統(tǒng)第一件事不是寫代碼而是把業(yè)務(wù)流程捋清楚。醫(yī)院就診系統(tǒng)和一般的信息管理系統(tǒng)有個(gè)很大的不同它存在一條強(qiáng)約束的流程鏈路。患者不是進(jìn)來隨便找個(gè)醫(yī)生聊天就行而是要經(jīng)歷選科室 - 選醫(yī)生 - 發(fā)起問診 - 醫(yī)生接診 - 在線交流 - 給出診斷與建議 - 開具處方 - 結(jié)束問診這樣的完整路徑。我第一次做的時(shí)候上來就建了一張message表和一個(gè)doctor表以為把聊天和醫(yī)生信息搞定就完了。結(jié)果做到一半才發(fā)現(xiàn)完全不是那么回事如果沒有問診單這個(gè)概念聊天記錄和醫(yī)生、患者的對應(yīng)關(guān)系就是亂的診斷和處方也沒地方掛靠。所以我在第二版設(shè)計(jì)里加了一張核心的consultation問診單表把整個(gè)流程的狀態(tài)都掛在它上面。這里你只要記住一個(gè)要點(diǎn)在線問診系統(tǒng)本質(zhì)上是一個(gè)訂單系統(tǒng)?；颊甙l(fā)起問診生成一張問診單醫(yī)生的接診、消息交流、開處方、結(jié)束問診都圍繞這張單子做狀態(tài)變更。想通了這一點(diǎn)后面的表設(shè)計(jì)和接口設(shè)計(jì)都會(huì)順暢很多。這也是為什么我建議所有人在建表之前先在紙上把這套狀態(tài)流轉(zhuǎn)畫出來。1.2 功能模塊與三角色權(quán)限劃分在線問診系統(tǒng)的使用者最少要有三類角色患者、醫(yī)生、管理員。每類角色看到的頁面和能操作的接口完全不一樣所以系統(tǒng)的功能模塊也要按角色來劃分?；颊叨撕诵墓δ苁亲缘卿?、瀏覽科室與醫(yī)生列表、發(fā)起問診、與醫(yī)生在線交流、查看問診記錄和電子處方。醫(yī)生端則包括查看待接診列表、接診處理、在會(huì)話中與患者溝通、填寫診斷和處方、管理自己的問診記錄。管理員端更偏向基礎(chǔ)數(shù)據(jù)維護(hù)科室管理、醫(yī)生信息管理、統(tǒng)計(jì)報(bào)表比如各科室問診量。權(quán)限管理不用做得太復(fù)雜但必須做。我的方案是user表里存一個(gè)role字段前端用路由守衛(wèi)攔截后端在接口里做角色校驗(yàn)。前后端兩層都校驗(yàn)才能避免繞過前端直接調(diào)用接口的問題。角色主要功能典型頁面患者掛號(hào)/發(fā)起問診、圖文咨詢、查看病歷、查看處方科室列表、醫(yī)生詳情、問診會(huì)話、處方詳情醫(yī)生接診、在線答復(fù)、寫診斷、開處方待接診列表、會(huì)話窗口、病歷填寫頁管理員科室與醫(yī)生管理、基礎(chǔ)數(shù)據(jù)維護(hù)科室管理、醫(yī)生審核、統(tǒng)計(jì)面板模塊理順之后你會(huì)發(fā)現(xiàn)頁面結(jié)構(gòu)也變得清晰。前端先按角色分路由再按功能分組件Vue的優(yōu)勢就體現(xiàn)出來了。1.3 為什么這套場景適合Flask VueFlask在整個(gè)Python后端生態(tài)里屬于輕量快跑的類型。它不像Django那樣自帶一整套Admin后臺(tái)和ORM約定但正因?yàn)檩p后端結(jié)構(gòu)可以由你自己掌控接口怎么寫、模塊怎么拆自由度很高。對一個(gè)問診系統(tǒng)來說核心業(yè)務(wù)是RESTful接口和狀態(tài)流轉(zhuǎn)Flask的Blueprint加上SQLAlchemy完全夠用不需要重型框架。Vue這邊組件化開發(fā)非常適合問診這種強(qiáng)交互的場景?；颊邌栐\會(huì)話窗口、醫(yī)生病歷填寫表單、消息列表每個(gè)頁面都是典型的多組件組合。用Vue Router做頁面路由用Pinia或Vuex管理登錄態(tài)和用戶信息配合Element Plus組件庫開發(fā)速度非?？?。還有一點(diǎn)是就業(yè)和學(xué)習(xí)生態(tài)。Python和Vue都是目前使用面極廣的技術(shù)棧做完這個(gè)項(xiàng)目以后簡歷上寫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è)計(jì)核心五張表一次說清數(shù)據(jù)庫設(shè)計(jì)是這套系統(tǒng)真正的骨架。我最終采用的表結(jié)構(gòu)大概是這樣的表名作用關(guān)鍵字段user登錄賬號(hào)與全局角色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)幾個(gè)設(shè)計(jì)細(xì)節(jié)。第一個(gè)是用戶和醫(yī)生分開存儲(chǔ)。user表作為所有角色的登錄憑證doctor表存醫(yī)生特有的業(yè)務(wù)信息所屬科室、職稱、簡介。為什么要分開因?yàn)橐粋€(gè)用戶可能先以患者身份注冊以后他又被管理員加為醫(yī)生如果所有信息都堆在同一張表要么字段冗余要么改角色的時(shí)候異常麻煩。分開之后user表承擔(dān)身份認(rèn)證doctor表承擔(dān)業(yè)務(wù)擴(kuò)展。第二個(gè)是密碼絕不能用明文。我在user表里用的是password_hash字段配合werkzeug.security的generate_password_hash和check_password_hash對密碼進(jìn)行不可逆的哈希存儲(chǔ)。登錄時(shí)只做哈希比對即使數(shù)據(jù)庫備份泄露也不會(huì)直接暴露明文密碼。第三個(gè)是問診單的status字段類型是字符串取值限制在四個(gè)狀態(tài)之間pending待接診、ongoing問診中、finished已結(jié)束、cancelled已取消。字符串比數(shù)字枚舉更直觀查數(shù)據(jù)的時(shí)候一眼能看出狀態(tài)含義調(diào)試也方便。2.2 接口設(shè)計(jì)RESTful風(fēng)格與統(tǒng)一返回結(jié)構(gòu)后端接口我全部走RESTful風(fēng)格資源用名詞動(dò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ī)生工作臺(tái)列表醫(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ù)錯(cuò)誤比如參數(shù)缺失、無權(quán)限、狀態(tài)不允許操作。前端axios攔截器里統(tǒng)一判斷code不是0就直接彈出msg提示減少了大量重復(fù)的異常處理代碼。Flask里用藍(lán)圖來組織接口一個(gè)模塊一個(gè)藍(lán)圖代碼結(jié)構(gòu)會(huì)清晰很多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ā)問題很容易被忽略。新手常見的坑是兩個(gè)醫(yī)生同時(shí)打開了同一個(gè)問診單然后都點(diǎn)了接診結(jié)果一個(gè)單子被兩個(gè)醫(yī)生接走。解決思路是在數(shù)據(jù)庫層面做條件更新而不是先查詢再更新from models import db, Consultation # 只有當(dāng)前狀態(tài)是 pending 時(shí)才允許接診 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說明更新時(shí)已經(jīng)不滿足statuspending這個(gè)條件說明別人搶先了。這種做法在數(shù)據(jù)庫層面鎖住了狀態(tài)變更不用額外引入Redis鎖對小型系統(tǒng)來說簡單又可靠。我建議問診單狀態(tài)的所有變更都走這個(gè)模式先filter_by帶上舊狀態(tài)條件再更新成新狀態(tài)提交后檢查受影響行數(shù)。這樣就算后續(xù)加了預(yù)約、排隊(duì)等復(fù)雜功能狀態(tài)也不會(huì)輕易亂掉。3. 前端Vue頁面組織與交互鏈路3.1 Vite Router Element Plus的項(xiàng)目骨架前端工程我用的是Vite Vue 3 Vue Router Pinia Element Plus這一套組合。Vite相比Webpack配置少很多啟動(dòng)速度快非常適合開發(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)限判斷集中在一個(gè)地方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)訪問。后端接口再做一層校驗(yàn)雙保險(xiǎn)基本夠用。3.2 患者端頁面掛號(hào)、發(fā)起問診、查看處方患者端的鏈路看起來簡單但頁面流轉(zhuǎn)是有狀態(tài)的。我的頁面順序是這樣的患者登錄后進(jìn)入科室列表頁點(diǎn)擊某個(gè)科室進(jìn)入醫(yī)生列表再點(diǎn)擊某個(gè)醫(yī)生進(jìn)入醫(yī)生詳情與發(fā)起問診頁填寫主訴之后提交問診單然后跳轉(zhuǎn)到問診會(huì)話頁。發(fā)起問診的表單是整個(gè)患者端的核心我設(shè)計(jì)了這幾個(gè)字段就診類型圖文問診、病情描述必填、補(bǔ)充信息選填比如持續(xù)時(shí)間、是否用藥以及一個(gè)簡單的上次就診情況文本域。主訴最好讓用戶寫得具體一些所以我在前端做了字?jǐn)?shù)校驗(yàn)最少10個(gè)字避免患者只輸入頭疼兩個(gè)字就讓醫(yī)生接診這樣對醫(yī)生端非常不友好。這里要提醒一下表單校驗(yàn)一定要前后端都做。前端做提示方便用戶后端做校驗(yàn)防止有人繞過頁面直接調(diào)接口寫臟數(shù)據(jù)。我的做法是后端用一個(gè)獨(dú)立的請求體校驗(yàn)流程字段缺失直接返回400。3.3 醫(yī)生端待接診列表、會(huì)話與病歷填寫醫(yī)生端的工作臺(tái)更像一個(gè)任務(wù)隊(duì)列。我用的是卡片列表形式待接診、問診中、已完成三個(gè)Tab切換。待接診卡片上只顯示患者的主訴摘要和發(fā)起時(shí)間醫(yī)生點(diǎn)接診按鈕后卡片狀態(tài)變成問診中然后進(jìn)入會(huì)話頁。醫(yī)生會(huì)話頁包含三塊區(qū)域左側(cè)是患者的基本信息與主訴中間是消息聊天窗口右側(cè)是病歷/處方操作區(qū)。為何要做成三欄因?yàn)獒t(yī)生在工作時(shí)習(xí)慣一邊看患者病史、一邊看當(dāng)前消息、一邊寫結(jié)論三者同時(shí)展示可以減少不必要的頁面跳轉(zhuǎn)。病歷填寫區(qū)我做了這么幾個(gè)表單項(xiàng)初步診斷、診斷說明、處理建議、是否開處方。是否開處方用了一個(gè)開關(guān)組件打開后動(dòng)態(tài)出現(xiàn)處方明細(xì)表格每行包含藥品名稱、用法、用量醫(yī)生可以點(diǎn)添加一行繼續(xù)增加。這個(gè)動(dòng)態(tài)表單用Vue的v-for渲染非常好寫具體代碼后面章節(jié)會(huì)提到。4. 在線問診核心功能從發(fā)起到結(jié)束的完整鏈路4.1 發(fā)起問診與接診流程的實(shí)現(xiàn)完整的問診鏈路后端涉及三個(gè)關(guān)鍵接口創(chuàng)建問診單、接診、結(jié)束問診。創(chuàng)建問診單時(shí)前端把doctorId、chiefComplaint、description這些字段傳過來。后端要做的事情是校驗(yàn)doctorId對應(yīng)的醫(yī)生是否存在校驗(yàn)當(dāng)前患者是否已經(jīng)有處于pending或ongoing狀態(tài)的問診單防止重復(fù)創(chuàng)建然后插入一條status為pending的記錄。接診接口就是我們前面說的條件更新把問診單從pending改為ongoing同時(shí)把doctorId綁定到當(dāng)前登錄醫(yī)生。這樣做不僅防止并發(fā)重復(fù)接診也保證每條問診單都有明確的接診醫(yī)生。結(jié)束問診的接口會(huì)稍微復(fù)雜一些它要同時(shí)做三件事把問診單狀態(tài)從ongoing改為finished保存診斷和建議文本如果醫(yī)生開了處方還要把處方主表和明細(xì)一起寫庫。為了保證數(shù)據(jù)不出現(xiàn)半成品比如狀態(tài)改了但處方?jīng)]存上我把這三個(gè)操作放在一個(gè)事務(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ù)時(shí)非常常用。flush會(huì)把數(shù)據(jù)發(fā)送到數(shù)據(jù)庫拿到ID但不會(huì)提交事務(wù)所以后續(xù)插入失敗還能整體回滾。4.2 實(shí)時(shí)消息選輪詢還是WebSocket在線問診最核心的交互就是消息。消息功能有兩條技術(shù)路線簡單輪詢和WebSocket。如果只是為了完成畢設(shè)或者演示原型輪詢完全可行。前端每隔3到5秒調(diào)用一次消息接口把新消息拉取出來渲染。實(shí)現(xiàn)簡單、部署方便也不依賴額外的連接管理。缺點(diǎn)是實(shí)時(shí)性一般而且患者和醫(yī)生同時(shí)在線時(shí)輪詢頻率高了會(huì)有一點(diǎn)無效請求。想做出真正像微信聊天的體驗(yàn)更推薦WebSocket方案。Flask這邊用Flask-SocketIO前端用socket.io-client事件驅(qū)動(dòng)雙向?qū)崟r(shí)通信。服務(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)入會(huì)話頁的時(shí)候連接WebSocket并加入對應(yīng)的房間。我實(shí)際測試下來基于SocketIO的聊天延遲基本可以忽略患者發(fā)一條消息醫(yī)生端幾乎是秒收。不過要提醒你SocketIO的會(huì)話管理和HTTP的JWT認(rèn)證怎么打通是這里比較繞的一個(gè)點(diǎn)后面排查章節(jié)我會(huì)專門說這個(gè)問題。如果你決定用輪詢我也給一個(gè)可行方案前端只在會(huì)話頁存活期間輪詢頁面離開就停掉后端在消息表中加last_id參數(shù)前端每次都傳當(dāng)前最新消息的ID后端只返回比這個(gè)ID大的新消息。這樣每次輪詢的數(shù)據(jù)量都很小體驗(yàn)雖然不如WebSocket但在課設(shè)里評分完全夠。4.3 電子病歷與處方數(shù)據(jù)如何落庫電子病歷和處方是和聊天截然不同的一類數(shù)據(jù)它們是結(jié)構(gòu)化的、有法律效應(yīng)的診療記錄不能像聊天記錄一樣隨便存。我的設(shè)計(jì)是診斷文本、處理建議存在consultation表上因?yàn)橐淮螁栐\對應(yīng)一組輕量的診斷信息處方單獨(dú)拆成prescription主表和prescription_item明細(xì)表因?yàn)橐粡執(zhí)幏娇赡馨喾N藥而且藥品明細(xì)未來可能要做庫存聯(lián)動(dòng)或統(tǒng)計(jì)報(bào)表。前端在醫(yī)生填寫處方時(shí)我用了一個(gè)可擴(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) }提交的時(shí)候?qū)rugs數(shù)組中的每條記錄作為對象傳給后端。后端的校驗(yàn)要點(diǎn)是藥品名稱、用法、用量都不能為空藥品數(shù)量最多不要超過20條。之所以加這個(gè)限制是防止某個(gè)醫(yī)生極端操作時(shí)一次性提交上百條明細(xì)導(dǎo)致前端渲染卡頓。這里有個(gè)我踩過的坑藥品字段的長度一定要給夠。有些中藥或者組合用藥的備注說明非常長我曾經(jīng)把drug_name設(shè)計(jì)成varchar(50)結(jié)果醫(yī)生錄入注射用頭孢曲松鈉羅氏芬就超了。后來改成Text類型一勞永逸。凡是涉及人工自由輸入的字段類型盡量放寬圖片路徑字段也一樣。5. 實(shí)操復(fù)盤本地跑通這套系統(tǒng)要多久5.1 環(huán)境準(zhǔn)備與依賴清單有一說一搭環(huán)境是最容易勸退新手的環(huán)節(jié)但按步驟來其實(shí)半小時(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一個(gè)參考的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)跨域與接口對接前后端分離項(xiàng)目最常見的聯(lián)調(diào)問題就是跨域。開發(fā)環(huán)境里Vite監(jiān)聽5173端口Flask監(jiān)聽5000端口兩個(gè)端口不同瀏覽器會(huì)攔截跨域請求。最省事的方法是在Vite的配置文件里加一個(gè)代理讓前端發(fā)請求的時(shí)候走同源路徑由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上的相對路徑不存在跨域問題。后端同時(shí)用flask-cors加上全局CORS支持雙保險(xiǎn)from flask_cors import CORS CORS(app, supports_credentialsTrue)不過要留意如果前端代理已經(jīng)配好后端CORS其實(shí)只在直接訪問5000端口調(diào)試時(shí)起作用所以兩者都配置屬于開發(fā)環(huán)境的基本配置。聯(lián)調(diào)時(shí)我都是先在瀏覽器Network面板里確認(rèn)請求發(fā)出去了、返回了什么再判斷是前端問題還是后端問題不要一看到報(bào)錯(cuò)就改代碼。5.3 部署到服務(wù)器的輕量方案開發(fā)環(huán)境跑通之后部署又是一個(gè)分水嶺。這里我給一個(gè)適合小型項(xiàng)目的方案后端用Gunicorn啟動(dòng)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)境聊天功能會(huì)退化。后端啟動(dòng)命令用gunicorn -w 3 -b 127.0.0.1:8000 app:app數(shù)據(jù)庫在演示項(xiàng)目里可以直接用SQLite文件幾乎零配置。但如果你想體驗(yàn)MySQL需要額外安裝PyMySQL并修改連接串。我的建議是原型階段直接用SQLite因?yàn)楸斫Y(jié)構(gòu)改動(dòng)頻繁SQLite遷庫非常方便到了真正要上線演示給更多人用的時(shí)候再遷MySQL加個(gè)連接配置就行。6. 高頻問題排查與避坑實(shí)錄6.1 前后端聯(lián)調(diào)階段的高頻報(bào)錯(cuò)下面這些報(bào)錯(cuò)是我在做這個(gè)項(xiàng)目過程中真真實(shí)實(shí)遇到過的每一項(xiàng)都花了時(shí)間排查。常見現(xiàn)象根本原因解決辦法瀏覽器控制臺(tái)報(bào)CORS錯(cuò)誤前端直接請求了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)]有加入同一個(gè)SocketIO房間檢查join_consult事件是否在進(jìn)入會(huì)話頁時(shí)執(zhí)行房間名是否統(tǒng)一用consult_id時(shí)間顯示差了8小時(shí)前后端時(shí)區(qū)不一致后端統(tǒng)一存UTC前端展示時(shí)用本地時(shí)間格式化6.2 數(shù)據(jù)一致性與并發(fā)問診的幾個(gè)坑在線問診的并發(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另一個(gè)坑是醫(yī)生結(jié)束問診時(shí)前端已經(jīng)把狀態(tài)改成finished了但后端事務(wù)沒提交成功導(dǎo)致前端顯示已結(jié)束、數(shù)據(jù)庫還是ongoing。排查這種問題要養(yǎng)成一個(gè)習(xí)慣以數(shù)據(jù)庫為準(zhǔn)不要以頁面為準(zhǔn)。頁面顯示錯(cuò)了可以刷新數(shù)據(jù)錯(cuò)了就要寫修復(fù)腳本。所以在所有寫操作里事務(wù)提交后我都建議立刻讀取一遍最新狀態(tài)返回給前端讓前端以接口返回為準(zhǔn)。6.3 安全與權(quán)限的幾個(gè)容易忽略的點(diǎn)最后說說安全。醫(yī)院問診系統(tǒng)涉及患者健康信息安全級別天然要高一些但很多課設(shè)和原型項(xiàng)目在安全上做得一塌糊涂。我覺得最基本的幾條底線一定不能丟。第一密碼必須哈希存儲(chǔ)前面已經(jīng)強(qiáng)調(diào)過用werkzeug自帶的工具就行。第二所有需要登錄的接口都要校驗(yàn)JWTFlask-JWT-Extended提供了現(xiàn)成的裝飾器比如jwt_required()。但要注意醫(yī)生患者的角色校驗(yàn)要自己處理不能只驗(yàn)證登錄就放行。第三患者只能查看自己的問診記錄醫(yī)生只能查看分配給自己的問診單。這個(gè)數(shù)據(jù)級權(quán)限很容易漏掉很多人寫接口時(shí)直接Consultation.query.all()返回全部記錄這是嚴(yán)重的越權(quán)漏洞。第四圖片上傳時(shí)一定要校驗(yàn)文件后綴和大小我建議最多允許5MB只接受jpg、png、webp等白名單格式不要接收可執(zhí)行文件。安全這東西對一個(gè)小型項(xiàng)目來說不用做到企業(yè)級那么復(fù)雜但上述幾條屬于基本素質(zhì)哪怕課設(shè)也值得做好。因?yàn)檫@些不僅是代碼問題更是設(shè)計(jì)態(tài)度的體現(xiàn)。最后再分享一點(diǎn)我的實(shí)際體會(huì)做完這套系統(tǒng)我最大的感覺是醫(yī)療問診類項(xiàng)目的核心難點(diǎn)不在技術(shù)炫技而在于把狀態(tài)管住。問診單的狀態(tài)、消息的狀態(tài)、用戶登錄的狀態(tài)只要這三類狀態(tài)清晰系統(tǒng)就穩(wěn)了一半。另一條建議是不要讓實(shí)時(shí)聊天綁架你的開發(fā)節(jié)奏——如果時(shí)間緊張輪詢方案完全夠交付先把問診主鏈路跑通再考慮用SocketIO提升體驗(yàn)。項(xiàng)目后續(xù)想擴(kuò)展還可以加排隊(duì)叫號(hào)、科室排班、藥品庫存管理、問診數(shù)據(jù)統(tǒng)計(jì)報(bào)表等功能基礎(chǔ)的表結(jié)構(gòu)和接口設(shè)計(jì)都能平滑支撐不會(huì)推翻重來。