一直有人問(wèn)我Python學(xué)到什么程度才算能做項(xiàng)目我通常不回答“學(xué)完語(yǔ)法”“看過(guò)框架文檔”而是說(shuō)“你能獨(dú)立跑通一個(gè)完整鏈路的小系統(tǒng)就是一次及格?！被赑ython Flask的天氣可視化分析系統(tǒng)恰好就是這樣一條再典型不過(guò)的完整鏈路從天氣數(shù)據(jù)采集到數(shù)據(jù)庫(kù)存儲(chǔ)再到統(tǒng)計(jì)分析最后用圖表展現(xiàn)在瀏覽器頁(yè)面上。很多人第一眼看到“天氣可視化”會(huì)覺(jué)得不過(guò)是個(gè)查天氣的網(wǎng)站但真正動(dòng)手把采集、入庫(kù)、聚合查詢(xún)和前端渲染串起來(lái)以后你會(huì)發(fā)現(xiàn)里面的門(mén)道遠(yuǎn)比想象中多。我這篇文章就把這套系統(tǒng)的設(shè)計(jì)思路、數(shù)據(jù)庫(kù)結(jié)構(gòu)、核心代碼、部署跑通步驟以及我實(shí)際踩過(guò)的坑一次講清楚給準(zhǔn)備做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)或自學(xué)練手的朋友一條能直接“抄作業(yè)”的路線。1. 項(xiàng)目整體認(rèn)知與方案選型1.1 這套系統(tǒng)到底在解決什么問(wèn)題表面上看它做的是“天氣數(shù)據(jù)展示”但換個(gè)角度理解它其實(shí)是一個(gè)小型的數(shù)據(jù)采集—存儲(chǔ)—分析—展示閉環(huán)。以天氣為題材是因?yàn)閿?shù)據(jù)容易獲取、字段通俗易懂、可視化效果直觀而且天然適合拿來(lái)做統(tǒng)計(jì)分析。比如你想知道某個(gè)城市最近30天的最高溫走勢(shì)、哪一天最熱、晴天占比多少、各風(fēng)力等級(jí)的出現(xiàn)頻率——這些在氣象網(wǎng)站上不會(huì)直接給你答案但把歷史天氣數(shù)據(jù)存到自己的數(shù)據(jù)庫(kù)里寫(xiě)幾條統(tǒng)計(jì)SQL結(jié)果就出來(lái)了。這套系統(tǒng)的核心價(jià)值不在于“展示天氣”而在于把一份結(jié)構(gòu)化數(shù)據(jù)變成一組可交互的信息。對(duì)于學(xué)習(xí)者來(lái)說(shuō)它覆蓋了Python后端開(kāi)發(fā)中最常被面試官問(wèn)到的幾件事如何設(shè)計(jì)表結(jié)構(gòu)、如何通過(guò)ORM操作數(shù)據(jù)庫(kù)、如何用Flask暴露HTTP接口、如何讓前端通過(guò)AJAX拿到數(shù)據(jù)并繪制圖表。對(duì)想進(jìn)一步擴(kuò)展的人來(lái)說(shuō)它又是一個(gè)很好的底座后續(xù)可以加用戶(hù)登錄、定時(shí)爬取、城市對(duì)比、導(dǎo)入導(dǎo)出Excel等模塊。1.2 為什么選Flask而不是Django或FastAPI很多初學(xué)者一上來(lái)就糾結(jié)框架選型。我的建議是先看項(xiàng)目的體量。如果只是一個(gè)“數(shù)據(jù)采集可視化展示”的單體應(yīng)用Flask是成本最低的選擇。它本身只負(fù)責(zé)路由和視圖剩下的東西你愿意用什么就插什么學(xué)習(xí)曲線很平緩。Django自帶ORM、Admin后臺(tái)、認(rèn)證系統(tǒng)功能確實(shí)全面但對(duì)這樣一個(gè)偏展示類(lèi)的項(xiàng)目來(lái)說(shuō)太重了新手往往會(huì)被“應(yīng)用目錄結(jié)構(gòu)”“中間件”“Django自帶ORM的遷移機(jī)制”這些概念分散注意力反而不容易聚焦在數(shù)據(jù)可視化這條主線上。FastAPI這幾年確實(shí)火型提示、自動(dòng)生成接口文檔都很香。但它對(duì)異步編程的要求偏高很多剛接觸Web開(kāi)發(fā)的讀者對(duì)async/await還不夠熟一旦在數(shù)據(jù)庫(kù)查詢(xún)或requests請(qǐng)求里用錯(cuò)方式排查起來(lái)會(huì)很吃力。相比之下Flask的普通函數(shù)寫(xiě)法最符合“同步思維”進(jìn)來(lái)一個(gè)請(qǐng)求查一次庫(kù)返回一份JSON邏輯一覽無(wú)余。而且Flask的教程數(shù)量、社區(qū)問(wèn)答覆蓋度都是三者中最高的遇到問(wèn)題搜索很容易找到答案。1.3 技術(shù)棧與整體數(shù)據(jù)流這套項(xiàng)目用到的核心組件如下層級(jí)技術(shù)選型主要職責(zé)采集層requests 解析模塊獲取天氣數(shù)據(jù)清洗成結(jié)構(gòu)化記錄存儲(chǔ)層SQLite SQLAlchemy ORM持久化天氣數(shù)據(jù)提供增刪改查業(yè)務(wù)層Flask提供頁(yè)面渲染和JSON數(shù)據(jù)接口展示層HTML ECharts fetch加載接口數(shù)據(jù)使用圖表進(jìn)行可視化分析整體數(shù)據(jù)流是這樣的采集腳本先從數(shù)據(jù)源拿到原始天氣信息解析后寫(xiě)入SQLite數(shù)據(jù)庫(kù)Flask應(yīng)用啟動(dòng)后前端頁(yè)面通過(guò)fetch請(qǐng)求訪問(wèn)/api/weather/trend這類(lèi)接口Flask路由內(nèi)部調(diào)用SQLAlchemy做聚合查詢(xún)把結(jié)果封裝成JSON返回瀏覽器拿到數(shù)據(jù)后交給ECharts繪制折線圖、餅圖等圖表同時(shí)頁(yè)面頂部用卡片組件展示統(tǒng)計(jì)指標(biāo)。這個(gè)閉環(huán)的好處在于每一層都是獨(dú)立的。接口返回的數(shù)據(jù)結(jié)構(gòu)變了不影響數(shù)據(jù)庫(kù)前端想換圖表庫(kù)也不需要?jiǎng)雍蠖诉壿嬌踔涟裇QLite換成MySQL只要ORM模型和連接串改一下其他地方幾乎不用動(dòng)。這種解耦思路本身就是項(xiàng)目里值得學(xué)習(xí)的一點(diǎn)。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與數(shù)據(jù)準(zhǔn)備2.1 天氣數(shù)據(jù)表結(jié)構(gòu)設(shè)計(jì)數(shù)據(jù)庫(kù)設(shè)計(jì)是這類(lèi)系統(tǒng)最容易馬虎、但又最關(guān)鍵的一步。我見(jiàn)過(guò)不少同學(xué)一上來(lái)就建一張寬表所有字段一股腦塞進(jìn)去結(jié)果后面統(tǒng)計(jì)查詢(xún)又慢又亂。合理的做法是先想清楚“我最終要在頁(yè)面上展示哪些指標(biāo)”再反推需要哪些字段。這套系統(tǒng)的核心展示需求有三個(gè)溫度趨勢(shì)、天氣現(xiàn)象分布、常用統(tǒng)計(jì)指標(biāo)。對(duì)應(yīng)的表結(jié)構(gòu)我建議這樣設(shè)計(jì)from datetime import datetime from flask_sqlalchemy import SQLAlchemy db SQLAlchemy() class Weather(db.Model): __tablename__ weather id db.Column(db.Integer, primary_keyTrue, autoincrementTrue) city db.Column(db.String(50), nullableFalse, comment城市名) date db.Column(db.Date, nullableFalse, comment日期) weather db.Column(db.String(50), comment天氣現(xiàn)象如晴/多云/小雨) temp_high db.Column(db.Integer, comment最高氣溫?cái)z氏度) temp_low db.Column(db.Integer, comment最低氣溫?cái)z氏度) wind_direction db.Column(db.String(50), comment風(fēng)向) wind_power db.Column(db.String(20), comment風(fēng)力等級(jí)) humidity db.Column(db.Integer, comment相對(duì)濕度百分比) __table_args__ ( db.UniqueConstraint(city, date, nameuk_city_date), )字段說(shuō)明幾點(diǎn)。date為什么不直接存字符串因?yàn)橛肙RM的Date字段做范圍查詢(xún)和排序非常方便前端展示時(shí)也可以通過(guò)strftime格式化。temp_high和temp_low用整型就夠不需要浮點(diǎn)精度。humidity存百分比整型。city和date加上唯一約束保證同一個(gè)城市同一天只保留一條數(shù)據(jù)這是防止重復(fù)入庫(kù)的關(guān)鍵。2.2 數(shù)據(jù)來(lái)源API、爬蟲(chóng)與離線造數(shù)天氣數(shù)據(jù)有三種常見(jiàn)來(lái)源適用范圍完全不同我分別說(shuō)一下。第一種是開(kāi)放天氣預(yù)報(bào)API通常需要注冊(cè)賬號(hào)申請(qǐng)key然后通過(guò)HTTP請(qǐng)求獲取JSON數(shù)據(jù)。這種方式最正規(guī)、數(shù)據(jù)質(zhì)量最高缺點(diǎn)是大多數(shù)免費(fèi)接口有每日調(diào)用次數(shù)限制而且返回字段各家不一需要仔細(xì)看文檔。第二種是爬蟲(chóng)采集氣象網(wǎng)站的歷史天氣頁(yè)面用requests抓HTML再用解析庫(kù)提取表格。這種方式優(yōu)點(diǎn)是數(shù)據(jù)量大、能拿到跨年數(shù)據(jù)但風(fēng)險(xiǎn)也明顯目標(biāo)站點(diǎn)可能更新結(jié)構(gòu)、有反爬策略、甚至不允許爬取。我的建議是如果只做學(xué)習(xí)演示不要對(duì)單站高頻請(qǐng)求控制采集頻率尊重目標(biāo)網(wǎng)站的聲明。第三種是離線造數(shù)也就是寫(xiě)腳本生成符合真實(shí)分布規(guī)律的模擬天氣數(shù)據(jù)。別覺(jué)得它“不夠硬核”在項(xiàng)目開(kāi)發(fā)初期先用模擬數(shù)據(jù)把頁(yè)面、接口、圖表全部調(diào)試通再切換成真實(shí)數(shù)據(jù)源是效率最高的推進(jìn)方式。造數(shù)也不是純隨機(jī)我一般會(huì)讓溫度呈現(xiàn)季節(jié)性變化比如冬天在-10度到5度之間夏天在22度到35度之間這樣折線圖看起來(lái)才可信。從實(shí)戰(zhàn)角度看我會(huì)建議你先用離線造數(shù)跑通全部頁(yè)面再根據(jù)動(dòng)手能力替換成API或爬蟲(chóng)。這樣既避免了一開(kāi)始被數(shù)據(jù)源卡住后面升級(jí)數(shù)據(jù)源時(shí)也正好練習(xí)接口對(duì)接和數(shù)據(jù)處理能力。2.3 為什么把數(shù)據(jù)放在SQLite而不是MySQL很多人會(huì)問(wèn)生產(chǎn)環(huán)境不都用MySQL嗎確實(shí)但這里要分清場(chǎng)景。SQLite是嵌入式關(guān)系型數(shù)據(jù)庫(kù)整個(gè)數(shù)據(jù)庫(kù)就是一個(gè)文件不需要單獨(dú)啟動(dòng)服務(wù)。對(duì)這套系統(tǒng)來(lái)說(shuō)數(shù)據(jù)量撐死也就是“幾個(gè)城市乘以幾百天”幾千行而已SQLite在查詢(xún)性能上完全無(wú)壓力。它的用戶(hù)權(quán)限模型相對(duì)簡(jiǎn)單對(duì)學(xué)習(xí)者來(lái)說(shuō)調(diào)試起來(lái)負(fù)擔(dān)更小換了電腦只要把這個(gè).db文件帶上數(shù)據(jù)就跟著走。如果硬上MySQL你得先安裝數(shù)據(jù)庫(kù)服務(wù)、配置賬號(hào)密碼、處理客戶(hù)端連接問(wèn)題還要擔(dān)心引擎選擇、字符集設(shè)置……這些對(duì)“把一個(gè)可視化系統(tǒng)跑起來(lái)”這件事本身沒(méi)有一點(diǎn)直接幫助。而且項(xiàng)目里用的是SQLAlchemy ORM它屏蔽了底層數(shù)據(jù)庫(kù)差異。等你以后需要上MySQL只需要改一行配置app.config[SQLALCHEMY_DATABASE_URI] sqlite:///weather.db # 改成 app.config[SQLALCHEMY_DATABASE_URI] mysqlpymysql://root:passwordlocalhost/weather_db模型和查詢(xún)代碼基本不用動(dòng)。這也是我堅(jiān)持用ORM而不是裸SQL的原因ORM讓這套系統(tǒng)具備了平滑遷移的能力。3. 核心功能模塊實(shí)現(xiàn)3.1 數(shù)據(jù)采集層requests加解析采集模塊的目標(biāo)是“把一個(gè)城市的天氣數(shù)據(jù)變成結(jié)構(gòu)化記錄并寫(xiě)入數(shù)據(jù)庫(kù)”。下面這段代碼演示了從HTTP接口獲取數(shù)據(jù)并解析的核心骨架接口地址按你實(shí)際申請(qǐng)到的服務(wù)來(lái)替換import requests def fetch_weather_from_api(city_name, api_key): # 這里用示例地址真實(shí)項(xiàng)目替換為對(duì)應(yīng)服務(wù)商接口 url https://api.example.com/v1/weather/history params { city: city_name, key: api_key, duration: 30d } resp requests.get(url, paramsparams, timeout10) resp.raise_for_status() payload resp.json() results [] for item in payload.get(data, []): results.append({ city: city_name, date: item[date], weather: item[text], temp_high: item[high], temp_low: item[low], wind_direction: item.get(wind_dir, ), wind_power: item.get(wind_level, ), humidity: item.get(humidity, 0) }) return results這里有幾個(gè)容易踩的細(xì)節(jié)。timeout10必須寫(xiě)否則請(qǐng)求掛起會(huì)讓采集腳本徹底卡住resp.raise_for_status()能在接口返回4xx/5xx時(shí)快速報(bào)錯(cuò)解析時(shí)盡量為可能缺失的字段設(shè)置默認(rèn)值比如濕度字段可能不是每個(gè)接口都有。拿到結(jié)構(gòu)化列表之后再循環(huán)調(diào)用數(shù)據(jù)庫(kù)插入即可。插入時(shí)建議先判斷城市和日期是否已存在已存在就跳過(guò)避免重復(fù)。3.2 Flask業(yè)務(wù)層路由、藍(lán)圖與接口Flask應(yīng)用的職責(zé)很清晰渲染首頁(yè)和提供數(shù)據(jù)接口。首頁(yè)路由很簡(jiǎn)單就是用render_template返回index.html。數(shù)據(jù)接口則需要做幾件事讀取請(qǐng)求參數(shù)、查詢(xún)數(shù)據(jù)庫(kù)、組織返回結(jié)構(gòu)。我習(xí)慣把返回結(jié)構(gòu)統(tǒng)一成下面這種格式def api_response(dataNone, msgsuccess, code0): return jsonify({code: code, msg: msg, data: data})這樣前后端約定明確后端接口不管返回的是列表還是字典前端都先判斷code 0再處理data后面擴(kuò)展登錄態(tài)、錯(cuò)誤提示都方便。以一個(gè)溫度趨勢(shì)接口為例from flask import Flask, render_template, request, jsonify from datetime import datetime, timedelta app.route(/api/weather/trend) def weather_trend(): city request.args.get(city, 北京) days int(request.args.get(days, 30)) start_date datetime.now().date() - timedelta(daysdays) rows (Weather.query .filter(Weather.city city, Weather.date start_date) .order_by(Weather.date.asc()) .all()) return api_response({ dates: [r.date.strftime(%m-%d) for r in rows], highs: [r.temp_high for r in rows], lows: [r.temp_low for r in rows], weather: [r.weather for r in rows] })city和days都是URL上的查詢(xún)參數(shù)默認(rèn)值保證了前端不傳參時(shí)接口不會(huì)報(bào)錯(cuò)。注意查詢(xún)時(shí)用date start_date限定范圍配合唯一索引查詢(xún)效率不會(huì)差。strftime(%m-%d)在前端展示時(shí)直接就是很干凈的標(biāo)簽。3.3 可視化展示層ECharts與前端頁(yè)面前端頁(yè)面我推薦用最簡(jiǎn)單的單頁(yè)布局頂部是標(biāo)題和城市切換下拉框中間是若干統(tǒng)計(jì)卡片下方是溫度趨勢(shì)折線圖、天氣分布餅圖和風(fēng)力柱狀圖。圖表庫(kù)用ECharts既可以通過(guò)CDN引入也可以下載到static/js目錄本地引入。考慮到有些環(huán)境無(wú)外網(wǎng)我更建議把echarts.min.js下載到本地。初始化核心圖表的邏輯大致如下async function loadTrendChart(city, days) { const resp await fetch(/api/weather/trend?city${city}days${days}); const result await resp.json(); if (result.code ! 0) { console.error(result.msg); return; } const data result.data; const chart echarts.init(document.getElementById(trendChart)); chart.setOption({ tooltip: { trigger: axis }, legend: { data: [最高氣溫, 最低氣溫] }, xAxis: { type: category, data: data.dates }, yAxis: { type: value, name: 溫度/℃ }, series: [ { name: 最高氣溫, type: line, data: data.highs, smooth: true }, { name: 最低氣溫, type: line, data: data.lows, smooth: true } ] }); }為什么溫度趨勢(shì)用折線圖因?yàn)檫B續(xù)時(shí)間序列數(shù)據(jù)最適合用折線展示變化趨勢(shì)和波動(dòng)范圍。為什么天氣分布用餅圖因?yàn)樘鞖忸?lèi)別是離散的分類(lèi)數(shù)據(jù)餅圖能直觀反映組成占比。選圖表類(lèi)型其實(shí)本身就是數(shù)據(jù)分析能力的一部分別不管什么數(shù)據(jù)都往折線圖上堆。3.4 統(tǒng)計(jì)分析模塊極值、均值與比例統(tǒng)計(jì)指標(biāo)是讓這套系統(tǒng)顯得“有分析能力”的關(guān)鍵。頁(yè)面頂部那幾張卡片建議放四個(gè)指標(biāo)近30天最高溫、近30天最低溫、平均最高溫、晴天比例。前三個(gè)用聚合查詢(xún)實(shí)現(xiàn)from sqlalchemy import func def get_city_stats(city, days): start_date datetime.now().date() - timedelta(daysdays) stats {} stats[max_high] (Weather.query .filter(Weather.city city, Weather.date start_date) .with_entities(func.max(Weather.temp_high)) .scalar()) stats[min_low] (Weather.query .filter(Weather.city city, Weather.date start_date) .with_entities(func.min(Weather.temp_low)) .scalar()) stats[avg_high] round((Weather.query .filter(Weather.city city, Weather.date start_date) .with_entities(func.avg(Weather.temp_high)) .scalar()) or 0, 1) return stats注意.scalar()返回的是單個(gè)值如果查詢(xún)結(jié)果為空會(huì)返回None所以對(duì)avg_high做了一層or 0兜底避免前端拿到null導(dǎo)致顯示異常。晴天比例左思右想還是拿出來(lái)說(shuō)一說(shuō)因?yàn)樗梅诸?lèi)統(tǒng)計(jì)本質(zhì)上是group by weather再計(jì)算占比rows (db.session.query(Weather.weather, func.count(Weather.id)) .filter(Weather.city city, Weather.date start_date) .group_by(Weather.weather) .all())拿到[(天氣現(xiàn)象, 天數(shù)), ...]之后在前端或者接口里算百分比都可以。我的習(xí)慣是在接口里就算好前端只負(fù)責(zé)展示數(shù)字這樣前端邏輯更薄、也方便以后做接口復(fù)用。4. 關(guān)鍵代碼與目錄拆解4.1 項(xiàng)目目錄與文件職責(zé)一個(gè)清晰的目錄結(jié)構(gòu)對(duì)后續(xù)維護(hù)和給他人講解都很有幫助。我推薦的布局是weather_analysis/ ├── app.py # Flask 應(yīng)用入口與路由 ├── models.py # SQLAlchemy ORM 模型 ├── spider.py # 天氣數(shù)據(jù)采集腳本 ├── init_db.py # 初始化數(shù)據(jù)庫(kù)與造數(shù)腳本 ├── requirements.txt # 依賴(lài)清單 ├── templates/ │ └── index.html # 頁(yè)面模板 └── static/ ├── css/ │ └── style.css # 頁(yè)面樣式可選 └── js/ ├── echarts.min.js # 本地圖表庫(kù) └── charts.js # 圖表渲染邏輯這樣拆分的核心原因只有一個(gè)每個(gè)文件只干一件事。models.py一旦變動(dòng)影響面可以被限制在數(shù)據(jù)層spider.py想換數(shù)據(jù)源不影響路由和頁(yè)面前端圖表改樣式后端代碼一個(gè)字都不用動(dòng)。課程答辯時(shí)你也能很清楚地講出“這個(gè)項(xiàng)目是分層架構(gòu)”的結(jié)論。4.2 數(shù)據(jù)庫(kù)初始化與造數(shù)腳本init_db.py做兩件事建表和填充數(shù)據(jù)。建表只需要一行from app import app from models import db with app.app_context(): db.create_all()為什么要在app.app_context()里面執(zhí)行因?yàn)镾QLAlchemy的create_all需要讀取應(yīng)用配置也就是要知道連接哪個(gè)數(shù)據(jù)庫(kù)而配置掛在Flask應(yīng)用上。離開(kāi)上下文直接調(diào)用會(huì)報(bào)“Working outside of application context”的錯(cuò)誤這是新手高頻踩坑點(diǎn)。造數(shù)腳本里我建議用基于季節(jié)的隨機(jī)生成策略import random from datetime import date, timedelta def generate_weather(city, start_date, days): rows [] for i in range(days): current start_date timedelta(daysi) month current.month if month in (12, 1, 2): high_base, low_base 3, -8 elif month in (6, 7, 8): high_base, low_base 32, 23 else: high_base, low_base 20, 10 temp_high high_base random.randint(-5, 5) temp_low low_base random.randint(-5, 5) temp_low min(temp_low, temp_high - 5) rows.append({ city: city, date: current, weather: random.choice([晴, 多云, 陰, 小雨, 中雨, 晴, 多云]), temp_high: temp_high, temp_low: temp_low, wind_direction: random.choice([東風(fēng), 南風(fēng), 西風(fēng), 北風(fēng), 東南風(fēng)]), wind_power: random.choice([1級(jí), 2級(jí), 3級(jí), 4級(jí)]), humidity: random.randint(30, 90) }) return rows注意我做了temp_low min(temp_low, temp_high - 5)保證最低溫不會(huì)出現(xiàn)高于最高溫的笑話(huà)數(shù)據(jù)。這個(gè)細(xì)節(jié)放在答辯時(shí)講能明顯體現(xiàn)你對(duì)數(shù)據(jù)質(zhì)量的意識(shí)。4.3 Flask應(yīng)用入口與頁(yè)面渲染下面是一份可以直接跑通的最簡(jiǎn)app.py骨架from flask import Flask, render_template, jsonify, request from models import db, Weather from datetime import datetime, timedelta app Flask(__name__) app.config[SQLALCHEMY_DATABASE_URI] sqlite:///weather.db app.config[SQLALCHEMY_TRACK_MODIFICATIONS] False db.init_app(app) app.route(/) def index(): cities [r[0] for r in db.session.query(Weather.city).distinct().all()] return render_template(index.html, citiescities) # 這里省略 /api/weather/trend 等接口實(shí)現(xiàn) # ... if __name__ __main__: app.run(debugTrue, port5000)首頁(yè)路由里我查了一次城市的去重列表用來(lái)渲染下拉框選項(xiàng)。查詢(xún)寫(xiě)法db.session.query(Weather.city).distinct().all()返回的是元組列表所以取r[0]。debugTrue在開(kāi)發(fā)階段很有用能自動(dòng)熱重載和顯示報(bào)錯(cuò)頁(yè)面但部署到公網(wǎng)環(huán)境時(shí)一定要關(guān)掉改成debugFalse并換一個(gè)待生產(chǎn)能力的服務(wù)器。4.4 前端圖表渲染關(guān)鍵邏輯在charts.js里我習(xí)慣把公共邏輯抽成函數(shù)避免三次加載圖表時(shí)重復(fù)代碼。比如統(tǒng)一處理接口請(qǐng)求和異常async function getJSON(url) { const resp await fetch(url); if (!resp.ok) { throw new Error(HTTP ${resp.status}); } const result await resp.json(); if (result.code ! 0) { throw new Error(result.msg); } return result.data; }接下來(lái)每個(gè)圖表的加載就變得非常清爽。以餅圖為例async function loadWeatherPie(city, days) { const data await getJSON(/api/weather/pie?city${city}days${days}); const chart echarts.init(document.getElementById(weatherPie)); chart.setOption({ tooltip: { trigger: item, formatter: : {c}天 (drlblxrh1%) }, series: [{ type: pie, radius: [40%, 70%], itemStyle: { borderRadius: 6, borderColor: #fff, borderWidth: 2 }, data: data.items }] }); }餅圖的環(huán)形樣式只是視覺(jué)優(yōu)化可加可不加。但你只要在里面展示出“晴多少天、雨多少天、占比多少”的信息這個(gè)圖就比只畫(huà)一個(gè)默認(rèn)餅圖有說(shuō)服力得多。圖表加載完成后還要記得在窗口尺寸變化時(shí)調(diào)chart.resize()不然瀏覽器縮放后圖表會(huì)失真。5. 從零跑通與真實(shí)避坑記錄5.1 環(huán)境安裝與項(xiàng)目啟動(dòng)步驟如果讓別人拿到這份項(xiàng)目源碼需要能快速跑起來(lái)。我會(huì)把啟動(dòng)步驟寫(xiě)進(jìn)README并按照下面的順序執(zhí)行cd weather_analysis python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt python init_db.py python app.py然后瀏覽器打開(kāi)http://127.0.0.1:5000。這里每一步都有講究。創(chuàng)建虛擬環(huán)境venv是為了隔離依賴(lài)防止污染系統(tǒng)Python環(huán)境requirements.txt內(nèi)容至少要有Flask、Flask-SQLAlchemy、requests我一般在項(xiàng)目寫(xiě)完后用pip freeze requirements.txt導(dǎo)出一份完整清單不過(guò)自由導(dǎo)出時(shí)里面會(huì)帶一堆間接依賴(lài)反而建議只寫(xiě)頂層依賴(lài)讀者裝起來(lái)更快。初始化數(shù)據(jù)庫(kù)時(shí)如果重復(fù)運(yùn)行init_db.pydb.create_all()不會(huì)重建已存在的表所以造數(shù)腳本要注意去重邏輯。如果一次運(yùn)行插入了半年的數(shù)據(jù)再跑一次又插了一次唯一約束會(huì)幫忙攔截重復(fù)數(shù)據(jù)但最好還是在插入前主動(dòng)判斷。5.2 常見(jiàn)問(wèn)題排查速查表實(shí)操過(guò)程中下面這張表里的問(wèn)題出現(xiàn)頻率最高我遇到過(guò)的概率排序大概也是這個(gè)順序現(xiàn)象常見(jiàn)原因排查與解決訪問(wèn)5000端口提示被占用上一次運(yùn)行的Flask進(jìn)程還在換端口app.run(port5001)或者找系統(tǒng)進(jìn)程結(jié)束掉打開(kāi)頁(yè)面只有骨架沒(méi)有圖表接口返回JSON中的字段名和前端對(duì)不上瀏覽器F12打開(kāi)Network看API實(shí)際返回內(nèi)容與charts.js里讀取的字段名提示W(wǎng)orking outside of application context數(shù)據(jù)庫(kù)操作沒(méi)放在應(yīng)用上下文中在with app.app_context():塊內(nèi)執(zhí)行初始化或查詢(xún)中文亂碼頁(yè)面或接口沒(méi)有聲明UTF-8確認(rèn)HTML頭部有meta charsetUTF-8爬蟲(chóng)解析時(shí)設(shè)置響應(yīng)編碼SQLite報(bào)database is locked多線程并發(fā)寫(xiě)入沖突開(kāi)發(fā)演示通常不會(huì)遇到如果遇到降低并發(fā)或改為串行寫(xiě)入下拉框里沒(méi)有城市選項(xiàng)數(shù)據(jù)庫(kù)還沒(méi)寫(xiě)入數(shù)據(jù)先運(yùn)行init_db.py確認(rèn)weather表有數(shù)據(jù)圖表數(shù)據(jù)看起來(lái)像折線斷電JSON返回了null對(duì)查詢(xún)結(jié)果做空值兜底前端過(guò)濾后再渲染5.3 我實(shí)操中的幾點(diǎn)體會(huì)第一點(diǎn)代碼跑通只算完成了40%。真正有價(jià)值的是你把每一個(gè)接口為什么這么設(shè)計(jì)、每一個(gè)字段為什么這樣存儲(chǔ)講清楚。比如唯一約束是為了避免重復(fù)比如接口統(tǒng)一返回結(jié)構(gòu)是為了讓前端少寫(xiě)判斷。這些設(shè)計(jì)理由在項(xiàng)目答辯里比“我用了Flask”這種話(huà)值錢(qián)得多。第二點(diǎn)想清楚數(shù)據(jù)從哪來(lái)再動(dòng)手寫(xiě)頁(yè)面。我見(jiàn)過(guò)有人先把前端頁(yè)面畫(huà)得漂漂亮亮結(jié)果發(fā)現(xiàn)拿不到數(shù)據(jù)源最后只能反復(fù)造數(shù)。正確順序是先確認(rèn)數(shù)據(jù)源、再建表、再寫(xiě)接口、最后做可視化。數(shù)據(jù)形態(tài)決定接口字段接口字段決定圖表類(lèi)型這個(gè)鏈條倒著走會(huì)非常痛苦。第三點(diǎn)造數(shù)時(shí)一定要搞出一點(diǎn)“臟數(shù)據(jù)”來(lái)練手。比如插入一條temp_low比temp_high還高的記錄再用查詢(xún)模塊把它查出來(lái)看看前端會(huì)不會(huì)顯示異常。真的處理過(guò)一次臟數(shù)據(jù)你對(duì)數(shù)據(jù)質(zhì)量的理解會(huì)比讀一百篇教程都深。最后說(shuō)點(diǎn)實(shí)在的如果你打算拿這套天氣可視化分析系統(tǒng)作為課程設(shè)計(jì)或面試展示項(xiàng)目我的建議是不要只停留在“能跑”?？梢宰约杭觾扇齻€(gè)小功能比如增加城市對(duì)比、支持日期范圍篩選、把統(tǒng)計(jì)結(jié)果導(dǎo)出成CSV。功能在精不在多每加一個(gè)功能就多一次完整的數(shù)據(jù)流動(dòng)你也就更熟悉這套鏈路里的每一個(gè)環(huán)節(jié)。我個(gè)人還有一個(gè)小習(xí)慣接口調(diào)試時(shí)用瀏覽器直接在地址欄輸入帶參數(shù)的URL比如/api/weather/trend?city上海days7比寫(xiě)測(cè)試腳本更快因?yàn)闉g覽器會(huì)把JSON原樣展示出來(lái)前端字段對(duì)不上時(shí)這一招特別管用。做完了這套系統(tǒng)最大的收獲應(yīng)該不是那幾個(gè)ECharts圖表而是你清楚了一條數(shù)據(jù)從產(chǎn)生到展示要經(jīng)歷哪些環(huán)節(jié)、每個(gè)環(huán)節(jié)容易在哪里翻車(chē)。能把這條鏈路講明白比背多少框架API都管用。