簡(jiǎn)介一份面向慢性病管理場(chǎng)景的Web系統(tǒng)課程報(bào)告資源適合醫(yī)療信息化方向的學(xué)生或開發(fā)者借鑒完整設(shè)計(jì)與實(shí)現(xiàn)流程。壓縮包共包含3個(gè)文件分別為PDF報(bào)告、Markdown源文件與HTML可視化演示頁整體僅1.28MB便于閱讀、編輯與直接查看圖表效果。系統(tǒng)采用Flask、Pandas與PyEcharts分層架構(gòu)涵蓋血糖血壓數(shù)據(jù)采集、缺失值與異常值清洗、統(tǒng)計(jì)分析與基于規(guī)則的預(yù)警引擎例如連續(xù)三天空腹血糖高于7.0 mmol/L即觸發(fā)高血糖提醒同時(shí)通過趨勢(shì)折線圖和箱線圖展示健康變化。文檔按摘要、緒論、相關(guān)技術(shù)、需求分析、總體設(shè)計(jì)、詳細(xì)實(shí)現(xiàn)、系統(tǒng)測(cè)試與總結(jié)展望等章節(jié)組織并附帶實(shí)現(xiàn)指南可完整還原開發(fā)脈絡(luò)其中還涉及基于角色的訪問控制保障數(shù)據(jù)安全。資源已有63人學(xué)習(xí)可作為課程報(bào)告范例或慢性病管理系統(tǒng)開發(fā)的重要參考。1. 慢性病管理數(shù)據(jù)追蹤與可視化系統(tǒng)從課程報(bào)告到能演示的完整項(xiàng)目如果你正在為課程報(bào)告或畢設(shè)選題發(fā)愁這套基于 Python 的慢性病數(shù)據(jù)追蹤與可視化系統(tǒng)是我拆過最省心的方向之一。它不依賴復(fù)雜的硬件設(shè)備也不需要真實(shí)的醫(yī)院數(shù)據(jù)接口——用公開的模擬數(shù)據(jù)就能跑通全流程。系統(tǒng)核心是圍繞血壓、血糖、心率等關(guān)鍵指標(biāo)完成從數(shù)據(jù)采集、清洗、趨勢(shì)追蹤到可視化看板的閉環(huán)最終產(chǎn)出一份能直接在答辯現(xiàn)場(chǎng)演示的交互式大屏。很多學(xué)生卡在「數(shù)據(jù)有了但不知道怎么講故事」這一步而這個(gè)項(xiàng)目恰好補(bǔ)上了這個(gè)缺口。它會(huì)幫你建立一套完整的數(shù)據(jù)處理思維數(shù)據(jù)規(guī)范是根基、趨勢(shì)算法是中堅(jiān)、可視化是門面。不管你未來是做數(shù)據(jù)分析還是后端開發(fā)這套流程都能復(fù)用。下面按我實(shí)際動(dòng)手的順序把每個(gè)環(huán)節(jié)的參數(shù)、代碼和坑位都攤開講。2. 數(shù)據(jù)模型設(shè)計(jì)先定字段再談分析2.1 為什么選 SQLite 而不是 MySQL課程報(bào)告場(chǎng)景下我強(qiáng)烈建議用 SQLite 而不是 MySQL。原因很簡(jiǎn)單SQLite 是文件型數(shù)據(jù)庫不需要單獨(dú)安裝服務(wù)代碼里連接一下就能用交作業(yè)時(shí)把.db文件一起打包就行。MySQL 需要配置賬號(hào)密碼、處理端口占用很多同學(xué)在環(huán)境搭建階段就勸退了。另一個(gè)理由是數(shù)據(jù)量。慢性病追蹤系統(tǒng)單機(jī)演示的數(shù)據(jù)量級(jí)基本在幾萬條以內(nèi)SQLite 的讀寫性能完全夠用。你在課程報(bào)告里寫「選用輕量級(jí)嵌入式數(shù)據(jù)庫降低部署復(fù)雜度」這句話在答辯時(shí)是加分項(xiàng)。2.2 三張核心表的結(jié)構(gòu)設(shè)計(jì)這套系統(tǒng)的數(shù)據(jù)模型我拆成三張表患者信息表、健康記錄表、用藥記錄表。健康記錄表是核心每行對(duì)應(yīng)一次測(cè)量關(guān)聯(lián)患者 ID 和記錄時(shí)間。-- patients: 患者基礎(chǔ)信息 CREATE TABLE patients ( patient_id TEXT PRIMARY KEY, name TEXT NOT NULL, age INTEGER, gender TEXT CHECK(gender IN (M, F)), diagnosis TEXT, created_at TEXT DEFAULT (datetime(now)) ); -- health_records: 核心健康指標(biāo)記錄 CREATE TABLE health_records ( record_id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id TEXT NOT NULL, record_date TEXT NOT NULL, systolic INTEGER, diastolic INTEGER, heart_rate INTEGER, blood_glucose REAL, spo2 INTEGER, note TEXT, FOREIGN KEY (patient_id) REFERENCES patients(patient_id) ); -- medications: 用藥記錄 CREATE TABLE medications ( record_id INTEGER PRIMARY KEY AUTOINCREMENT, patient_id TEXT NOT NULL, med_name TEXT NOT NULL, dosage REAL, frequency TEXT, start_date TEXT, end_date TEXT, FOREIGN KEY (patient_id) REFERENCES patients(patient_id) );字段設(shè)計(jì)的核心理念是「寧寬勿窄」——額外的note字段用來記特殊情況比如「測(cè)量前運(yùn)動(dòng)了」「空腹血糖」這在你分析異常值時(shí)非常有幫助。spo2是血氧飽和度疫情期間很多慢病管理項(xiàng)目都加了這項(xiàng)如果你不需要可以留空但字段先占位。關(guān)鍵參數(shù)說明blood_glucose用REAL而不是INTEGER因?yàn)檠侵到?jīng)常出現(xiàn) 5.6、7.8 這樣的帶小數(shù)數(shù)值用整型會(huì)直接截?cái)鄶?shù)據(jù)就廢了。systolic和diastolic是收縮壓和舒張壓用INTEGER沒問題血壓計(jì)讀出來就是整數(shù)。2.3 索引查詢性能的隱形加速器數(shù)據(jù)量小的時(shí)候你可能感受不到索引的價(jià)值但當(dāng)你演示時(shí)篩選某個(gè)患者的全部記錄或者按日期范圍聚合數(shù)據(jù)沒有索引的表會(huì)全表掃描體感上會(huì)卡頓。CREATE INDEX idx_health_patient_date ON health_records(patient_id, record_date); CREATE INDEX idx_health_date ON health_records(record_date); CREATE INDEX idx_med_patient ON medications(patient_id);復(fù)合索引(patient_id, record_date)是最關(guān)鍵的查詢場(chǎng)景永遠(yuǎn)是「先定位患者再按時(shí)間排序」。我把日期放第二列是因?yàn)閷?shí)際查詢中過濾患者的頻率遠(yuǎn)高于過濾日期這個(gè)順序能讓索引最大化命中。3. 數(shù)據(jù)清洗與追蹤邏輯臟數(shù)據(jù)是常態(tài)不是異常3.1 模擬數(shù)據(jù)生成的正確姿勢(shì)課程報(bào)告最怕的是「數(shù)據(jù)不夠分析深度」。我見過太多人只造了 30 條數(shù)據(jù)畫出來的折線圖毫無說服力。我的習(xí)慣是模擬生成至少 3 個(gè)患者、每人 60 天、每天 1-3 條記錄總量在 500 條以上這樣趨勢(shì)分析才有意義。import sqlite3 import random import pandas as pd from datetime import datetime, timedelta random.seed(42) conn sqlite3.connect(chronic.db) cursor conn.cursor() base_date datetime(2024, 1, 1) patients [ (P001, Zhang, 58, M, 糖尿病), (P002, Li, 62, F, 高血壓), (P003, Wang, 55, M, 冠心病) ] for pid, name, age, gender, diag in patients: cursor.execute( INSERT INTO patients VALUES (?,?,?,?,?, datetime(now)), (pid, name, age, gender, diag) ) # 每個(gè)患者回歸一個(gè)基準(zhǔn)血壓/血糖加隨機(jī)波動(dòng) base_sbp {P001: 125, P002: 145, P003: 135}[pid] base_dbp {P001: 78, P002: 92, P003: 85}[pid] base_glu {P001: 7.2, P002: 5.8, P003: 5.5}[pid] for day in range(60): d (base_date timedelta(daysday)).strftime(%Y-%m-%d) for _ in range(random.randint(1, 3)): sbp base_sbp random.randint(-8, 10) dbp base_dbp random.randint(-5, 6) hr random.randint(58, 92) glu round(base_glu random.uniform(-0.8, 1.2), 1) spo2 random.randint(94, 99) cursor.execute( INSERT INTO health_records (patient_id, record_date, systolic, diastolic, heart_rate, blood_glucose, spo2) VALUES (?,?,?,?,?,?,?), (pid, d, sbp, dbp, hr, glu, spo2) ) conn.commit()這段代碼的關(guān)鍵設(shè)計(jì)是「基準(zhǔn)值 隨機(jī)波動(dòng)」模式。如果沒有基準(zhǔn)值血壓會(huì)在 80-180 之間完全隨機(jī)跳動(dòng)畫出來的圖像波形一樣毫無規(guī)律可循加了基準(zhǔn)值后P002 的血壓穩(wěn)定在 145 附近波動(dòng)P001 的血糖穩(wěn)定在 7.2 附近這樣才能讓追蹤和趨勢(shì)分析有素材。random.seed(42)這行非常關(guān)鍵加了種子后無論你運(yùn)行多少次生成的數(shù)據(jù)完全一致。這意味著你的課程報(bào)告結(jié)果可復(fù)現(xiàn)導(dǎo)師問「你這個(gè)數(shù)據(jù)哪來的」時(shí)你可以當(dāng)場(chǎng)重新生成一遍給他看。3.2 空值與異常值的清理策略模擬數(shù)據(jù)不會(huì)自動(dòng)產(chǎn)生空值但真實(shí)數(shù)據(jù)一定會(huì)。我建議在清洗代碼里故意構(gòu)造一些臟數(shù)據(jù)場(chǎng)景來演示你的清洗邏輯——這在答辯時(shí)是亮點(diǎn)。def clean_health_records(df): 清洗健康記錄處理空值、邏輯錯(cuò)誤、異常范圍 df df.copy() # 1. 缺失值處理記錄日期與空腹血糖強(qiáng)相關(guān)日期缺失直接刪除 before len(df) df df.dropna(subset[record_date, patient_id]) print(f刪除日期/患者缺失記錄: {before} - {len(df)}) # 2. 血壓范圍檢查收縮壓 70-200舒張壓 40-120 df df[(df[systolic].between(70, 200)) (df[diastolic].between(40, 120))] # 3. 心率范圍 40-130超出視為測(cè)量誤差 df df[df[heart_rate].between(40, 130)] # 4. 血糖范圍 2.0-20.0 mmol/L df df[df[blood_glucose].between(2.0, 20.0)] # 5. 血氧 85-100低于 85 屬于嚴(yán)重異常保留但標(biāo)記 df[spo2_abnormal] df[spo2] 90 return df這里的邊界值不是隨便寫的。收縮壓下限 70 是臨床上嚴(yán)重低血壓的閾值低于這個(gè)值人已經(jīng)休克了血糖上限 20 是血糖儀的常見量程上限超過說明設(shè)備可能已經(jīng)測(cè)不準(zhǔn)了。這些閾值在課程報(bào)告里寫清楚依據(jù)是體現(xiàn)專業(yè)度的方式。我對(duì)缺失值的處理原則是「能留不留廢」日期和患者 ID 缺失的記錄直接刪因?yàn)檫@兩項(xiàng)沒法推斷數(shù)值字段缺失則用前向填充慢病數(shù)據(jù)具有連續(xù)性今天的血壓和昨天大概率接近。3.3 趨勢(shì)追蹤算法移動(dòng)平均與變化率判定追蹤的「追」字核心在于判斷指標(biāo)在變好還是變差。單個(gè)點(diǎn)的波動(dòng)毫無意義需要滑動(dòng)窗口看趨勢(shì)。我用的方案是 7 日移動(dòng)平均加上變化率閾值。def trend_analysis(df, window7, threshold5): 計(jì)算移動(dòng)平均與趨勢(shì)方向 df df.sort_values(record_date) df[sbp_ma7] df[systolic].rolling(windowwindow, min_periods1).mean() # 變化率: (今日均值 - 窗口起始均值) / 窗口起始均值 * 100 df[change_pct] df[sbp_ma7].pct_change(periodswindow) * 100 # 趨勢(shì)判定: 變化率超過正向閾值 - 惡化; 低于負(fù)向閾值 - 好轉(zhuǎn) df[trend] stable df.loc[df[change_pct] threshold, trend] worsening df.loc[df[change_pct] -threshold, trend] improving return dfpct_change(periodswindow)計(jì)算的是「第 n 天的 7 日均值 相對(duì) 第 n-7 天的 7 日均值」的變化百分比。如果連續(xù)兩周血壓升高超過 5%系統(tǒng)標(biāo)記為「惡化」這個(gè)標(biāo)記會(huì)同步到可視化看板上變色圖塊。閾值 5% 不是拍腦袋定的。血壓 130 的 5% 就是 6.5mmHg而臨床指南通常認(rèn)為收縮壓波動(dòng)超過 10mmHg 才需要調(diào)整用藥我取半量作為預(yù)警線靈敏度更高。如果你處理的指標(biāo)是血糖閾值可以改到 10%因?yàn)檠堑娜諆?nèi)波動(dòng)比血壓大得多。4. 可視化方案設(shè)計(jì)與實(shí)現(xiàn)讓數(shù)據(jù)替你把話說清楚4.1 圖表選型邏輯不是所有數(shù)據(jù)都配得上折線圖課程報(bào)告和答辯演示里最常見的扣分項(xiàng)是圖表選型錯(cuò)誤。柱狀圖硬畫成折線圖、多指標(biāo)擠在一張圖里——這些問題一眼就能看出來。我按「時(shí)間序列、分布、組成、相關(guān)」四類場(chǎng)景來做選型決策血壓/血糖/心率隨時(shí)間變化折線圖加移動(dòng)平均趨勢(shì)線各指標(biāo)分布區(qū)間箱線圖能看出中位數(shù)、四分位距和離群點(diǎn)一日內(nèi)多次測(cè)量的波動(dòng)規(guī)律熱力圖縱軸是時(shí)間點(diǎn)橫軸是日期舒張壓與收縮壓相關(guān)性散點(diǎn)圖能直觀看到二者聯(lián)動(dòng)這套選型邏輯各自獨(dú)立又能互相印證。折線圖講趨勢(shì)箱線圖講分布特征答辯時(shí)導(dǎo)師問「為什么這里用箱線圖」你回答「為了展示數(shù)據(jù)分布形態(tài)并識(shí)別離群點(diǎn)」這就是專業(yè)術(shù)語。4.2 pyecharts 交互式看板的代碼實(shí)現(xiàn)我在課程設(shè)計(jì)里選 pyecharts 而不是 matplotlib核心原因是交互性。matplotlib 輸出的是靜態(tài)圖而 pyecharts 渲染成 HTML鼠標(biāo)懸停能看到具體數(shù)值還能縮放時(shí)間范圍——答辯演示的觀感差距是碾壓性的。另一個(gè)原因是 pyecharts 圖表種類豐富地圖、儀表盤、熱力圖開箱即用。from pyecharts.charts import Line, Bar, Tab, Grid from pyecharts import options as opts import pandas as pd def build_dashboard(db_pathchronic.db): 構(gòu)建數(shù)據(jù)可視化看板 conn sqlite3.connect(db_path) df pd.read_sql_query( SELECT h.record_date, h.systolic, h.diastolic, h.blood_glucose, h.heart_rate, p.name, p.diagnosis FROM health_records h JOIN patients p ON h.patient_id p.patient_id ORDER BY h.record_date, conn ) # 按患者分組計(jì)算日均值 df[record_date] pd.to_datetime(df[record_date]) daily df.groupby([name, record_date])[[systolic, diastolic]].mean().reset_index() p001 daily[daily[name] Zhang] # 圖表1: 血壓趨勢(shì) 移動(dòng)平均 line (Line() .add_xaxis(p001[record_date].dt.strftime(%m-%d).tolist()) .add_yaxis(收縮壓, p001[systolic].round(1).tolist(), is_smoothTrue, symbolcircle, symbol_size6) .add_yaxis(舒張壓, p001[diastolic].round(1).tolist(), is_smoothTrue, symbolcircle, symbol_size6) .set_global_opts( title_optsopts.TitleOpts(titleZhang 血壓趨勢(shì)追蹤), tooltip_optsopts.TooltipOpts(triggeraxis), datazoom_opts[opts.DataZoomOpts(range_start20, range_end100)], yaxis_optsopts.AxisOpts( namemmHg, min_70, max_200, splitline_optsopts.SplitLineOpts(is_showTrue) ) )) line.render(dashboard/templates/patient_trend.html) build_dashboard()代碼里的關(guān)鍵參數(shù)有三個(gè)is_smoothTrue讓折線平滑化避免鋸齒感觀感更專業(yè)datazoom_opts加了一個(gè)拖動(dòng)條允許查看任意時(shí)段細(xì)節(jié)splitline_opts加了橫向網(wǎng)格線方便讀取具體數(shù)值。我提到的Grid和Tab是 pyecharts 里的布局容器。單個(gè) HTML 里放多個(gè)圖表用Grid做上下分欄多個(gè)頁面切換用Tab做標(biāo)簽頁。課程設(shè)計(jì)中我做的是一個(gè)Tab總頁面每個(gè)患者一個(gè)標(biāo)簽頁點(diǎn)一下就能切換演示效果非常好。4.3 大屏布局的 CSS 網(wǎng)格方案如果內(nèi)容是「數(shù)據(jù)可視化大屏」就涉及布局問題。pyecharts 本身只負(fù)責(zé)生成單個(gè)圖表 HTML多個(gè)圖表拼成一個(gè)大屏需要用 HTML 模板做網(wǎng)格布局。!DOCTYPE html html head meta charsetutf-8 style .grid-container { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-template-rows: 300px 300px; gap: 12px; padding: 12px; background: #0f1420; } .grid-item { background: #1a2130; border-radius: 8px; padding: 8px; border: 1px solid #2a3441; } .grid-item iframe { width: 100%; height: 100%; border: none; } .header { color: #e6e9ef; text-align: center; font-size: 22px; padding: 16px; background: #1a2130; font-weight: 600; } /style /head body div classheader慢性病管理數(shù)據(jù)追蹤看板/div div classgrid-container div classgrid-item iframe srcpatient_trend.html/iframe /div !-- 其他圖表 iframe 嵌入 -- /div /body /htmliframe 嵌入方案是我總結(jié)出來的最優(yōu)解。pyecharts 的 render API 本身就是生成完整 HTML你直接在網(wǎng)格的每個(gè)單元格里嵌 iframe 指向?qū)?yīng) HTML 文件不用手動(dòng)改 pyecharts 模板源碼——那個(gè)模板改起來又長(zhǎng)又容易出錯(cuò)。顏色配比上深色背景配亮色圖表這是數(shù)據(jù)可視化大屏的通用做法能讓圖表的主體色彩更突出。后臺(tái)開著python app.py瀏覽器打開本地服務(wù)地址是一個(gè)完整系統(tǒng)該有的樣子。5. 數(shù)據(jù)追蹤與可視化系統(tǒng)的避坑指南五個(gè)高頻翻車點(diǎn)5.1 中文亂碼與字體缺失圖表標(biāo)題變方塊現(xiàn)象圖表標(biāo)題、軸標(biāo)簽里的中文全部顯示為方塊或問號(hào)導(dǎo)出的 HTML 在答辯電腦上也一樣。原因pyecharts 渲染時(shí)默認(rèn)用的字體不含中文字形或者操作系統(tǒng)沒安裝對(duì)應(yīng)的中文字體。在未安裝中文字體的 Linux 服務(wù)器上尤其常見學(xué)校實(shí)驗(yàn)室的電腦有些精簡(jiǎn)系統(tǒng)也有這個(gè)問題。解決在圖表配置里顯式指定中文字體二選一即可。一是本地安裝字體后配置opts.TitleOpts(title血壓趨勢(shì), title_textstyle_optsopts.TextStyleOpts(font_familyMicrosoft YaHei))二是確保系統(tǒng)有可用中文字體。我在代碼里統(tǒng)一用font_familyMicrosoft YaHeiWindows 和 macOS 都有這個(gè)字體是兼容性最好的方案。5.2 SQLite 時(shí)間用文本存儲(chǔ)日期排序錯(cuò)亂現(xiàn)象ORDER BY record_date排序后數(shù)據(jù)亂序比如 2024-02-01 排到了 2024-01-31 前面或者同一天的數(shù)據(jù)順序不對(duì)。原因如果你把日期存成了TEXT類型并且格式不統(tǒng)一有的是2024-1-1有的是2024-01-01文本排序按字符逐個(gè)比較2024-1-1會(huì)排在2024-01-02后面。解決所有日期統(tǒng)一用YYYY-MM-DD格式存儲(chǔ)零填充是必須的。我在建表時(shí)用datetime(now)生成的默認(rèn)值天然就是標(biāo)準(zhǔn)格式但插入模擬數(shù)據(jù)時(shí)用strftime(%Y-%m-%d)顯式格式化日期確保格式一致。5.3 pandas 讀入 SQLite 后日期自動(dòng)多 8 小時(shí)現(xiàn)象讀取數(shù)據(jù)后record_date從2024-01-01變成了2024-01-01 08:00:00做時(shí)間序列分析時(shí)按日聚合會(huì)出錯(cuò)。原因SQLite 的 TEXT 日期被 pandas 識(shí)別后自動(dòng)推斷為 datetime64默認(rèn)按本地時(shí)區(qū)東八區(qū)解析。由于 TEXT 里沒有時(shí)區(qū)信息pandas 會(huì)補(bǔ)一個(gè)默認(rèn) UTC 的假定時(shí)區(qū)再轉(zhuǎn)換導(dǎo)致偏移。解決讀取 SQL 時(shí)不用 pandas 自動(dòng)推斷而是手動(dòng)指定解析格式df pd.read_sql_query(sql, conn) df[record_date] pd.to_datetime(df[record_date], format%Y-%m-%d %H:%M:%S)這里顯式告訴 pandas 日期字符串的完整格式它就不會(huì)自作主張補(bǔ)時(shí)區(qū)。如果你在 pandas 2.0 以上版本遇到報(bào)錯(cuò)可以加errorscoerce把無法解析的日期置為 NaT用完再 dropna。5.4 滾動(dòng)平均出現(xiàn) NaN圖表前半段空白現(xiàn)象計(jì)算 7 日移動(dòng)平均后前 6 天的數(shù)值是 NaN折線圖上開頭一段是空的看起來像數(shù)據(jù)缺損。原因rolling(window7)默認(rèn)要求窗口內(nèi)有 7 個(gè)完整數(shù)據(jù)點(diǎn)才計(jì)算。某天有 1 次測(cè)量、有時(shí) 3 次如果某天缺失記錄窗口湊不齊 7 個(gè)點(diǎn)就會(huì)一直 NaN。解決rolling有三個(gè)方案。其一用min_periods1我在前面代碼里用的窗口內(nèi)有 1 個(gè)數(shù)據(jù)就算均值其二用min_periods3至少 3 個(gè)點(diǎn)參與計(jì)算平衡穩(wěn)定性和空值其三先用resample(D).mean()把數(shù)據(jù)重采樣成按天的規(guī)整序列再滾動(dòng)平均。我實(shí)際用的是第三種因?yàn)橹夭蓸雍髷?shù)據(jù)結(jié)構(gòu)更規(guī)整后續(xù)其他分析也方便。5.5 pyecharts 圖表在 Jupyter 里不顯示但 HTML 文件正?，F(xiàn)象同樣的代碼render(x.html)能正常打開但寫在 Jupyter Notebook 里運(yùn)行時(shí)圖表區(qū)域空白或者只有一行提示文字。原因pyecharts 在 Jupyter 里走的是內(nèi)聯(lián)渲染inline render需要加載相應(yīng)的 JS 資源如果你的網(wǎng)絡(luò)被限制、無法訪問 CDN 資源圖表就放不出來。解決換render_notebook()無效就先排查網(wǎng)絡(luò)。更穩(wěn)妥的方案是調(diào)整資源加載方式from pyecharts.globals import CurrentConfig CurrentConfig.ONLINE_HOST https://cdn.jsdelivr.net/npm/echarts5/dist/把遠(yuǎn)程資源指向 jsdelivr它比默認(rèn)的 bootcdn 穩(wěn)定性更好。如果對(duì)離線環(huán)境有要求就把echarts.min.js下載到本地設(shè)置CurrentConfig.ONLINE_HOST ./static/js/。我最后是用 HTML 展示而不是 Jupyter省掉所有依賴問題。6. 進(jìn)階把分析流程裝進(jìn) Flask讓系統(tǒng)變成可演示的產(chǎn)品前面所有分析都是腳本級(jí)別的但課程設(shè)計(jì)答辯時(shí)腳本和系統(tǒng)的區(qū)別很直觀。我給你一套把追蹤和可視化整合到 Flask 服務(wù)的方案讓整個(gè)系統(tǒng)可以交互式使用。6.1 核心服務(wù)模塊與路由設(shè)計(jì)from flask import Flask, render_template, jsonify, request import sqlite3 import pandas as pd app Flask(__name__) DB_PATH chronic.db def get_records(patient_idNone, startNone, endNone): 查詢健康記錄支持患者和時(shí)間范圍過濾 conn sqlite3.connect(DB_PATH) sql SELECT * FROM health_records WHERE 11 params [] if patient_id: sql AND patient_id ? params.append(patient_id) if start: sql AND record_date ? params.append(start) if end: sql AND record_date ? params.append(end) sql ORDER BY record_date df pd.read_sql_query(sql, conn, paramsparams) conn.close() return df app.route(/) def index(): 看板首頁渲染大屏模板 return render_template(dashboard.html) app.route(/api/trend/patient_id) def api_trend(patient_id): 趨勢(shì)數(shù)據(jù)接口返回患者時(shí)間序列 df get_records(patient_id) df trend_analysis(df) return jsonify({ dates: df[record_date].tolist(), systolic: df[systolic].tolist(), sbp_ma7: df[sbp_ma7].round(2).tolist(), trend: df[trend].tolist() }) if __name__ __main__: app.run(debugTrue, port5000)這段代碼把前面所有分析邏輯串成 HTTP 接口。/api/trend/patient_id接口接受患者 ID 參數(shù)返回該患者的血壓時(shí)間序列和趨勢(shì)判定前端可以動(dòng)態(tài)渲染圖表。WHERE 11這種寫法是動(dòng)態(tài)構(gòu)建 SQL 的經(jīng)典技巧——先寫一個(gè)恒真條件后面拼接的過濾條件都用AND連接省去了判斷「是否第一個(gè)條件」的麻煩。雖然有點(diǎn) hack但在課程設(shè)計(jì)場(chǎng)景下完全沒問題也不會(huì)造成性能消耗。6.2 動(dòng)態(tài)傳參的圖表渲染方法接口就緒后前端圖表用 JavaScript 發(fā)請(qǐng)求拿數(shù)據(jù)再喂給 ECharts而不是像之前那樣在 Python 端寫死數(shù)據(jù)。async function loadTrend(patientId) { const res await fetch(/api/trend/${patientId}); const data await res.json(); const chart echarts.init(document.getElementById(trend-chart)); chart.setOption({ tooltip: { trigger: axis }, xAxis: { type: category, data: data.dates }, yAxis: { type: value, name: mmHg, min: 70, max: 200 }, series: [ { name: 收縮壓, type: line, data: data.systolic, smooth: true }, { name: 7日均值, type: line, data: data.sbp_ma7, smooth: true, lineStyle: { type: dashed } } ] }); }前端用fetch請(qǐng)求后端接口拿到 JSON 后setOption動(dòng)態(tài)渲染。這套前后端分離的寫法比單純?cè)?Python 端生成靜態(tài)圖表高一個(gè)層次——它意味著系統(tǒng)真的具有了「追數(shù)據(jù)」的能力新增一條記錄后刷新頁面就能看到最新追蹤結(jié)果。我后來給學(xué)生改課程設(shè)計(jì)時(shí)每次都會(huì)讓頁面篩選器加患者下拉框而不是一個(gè)患者一個(gè)頁面。一來代碼重復(fù)度低二來答辯時(shí)可以直接演示系統(tǒng)響應(yīng)。從那以后我每寫一個(gè)可視化項(xiàng)目都強(qiáng)制把數(shù)據(jù)層和展示層拆開——先定義接口再做頁面這套流程希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取