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