簡介基于Python Flask與Echarts插件構(gòu)建的豆瓣電影TOP250數(shù)據(jù)分析可視化網(wǎng)站完整源碼適合有一定Python基礎、希望系統(tǒng)學習Flask Web開發(fā)與數(shù)據(jù)可視化應用的開發(fā)者。項目綜合運用爬蟲采集豆瓣電影數(shù)據(jù)并通過Echarts生成交互式圖表輔以WordCloud詞云、地圖文件等增強展示效果可作為課程設計或畢業(yè)設計的參考藍本。整個壓縮包共92個文件主要包含4個Python腳本、5個HTML模板、16個CSS樣式、16個JavaScript腳本及11個地圖文件另有圖片、字體、數(shù)據(jù)庫與配置文件等整體大小9.98MB目錄結(jié)構(gòu)清晰前端靜態(tài)資源與后端邏輯劃分明確。目前已有462人學習下載。通過學習這份源碼可掌握基于Flask搭建動態(tài)網(wǎng)站、使用Echarts繪制評分與評論分布圖表、利用WordCloud分析文本關鍵詞以及爬蟲數(shù)據(jù)入庫的完整實現(xiàn)思路便于后續(xù)遷移到其他數(shù)據(jù)分析場景。1. 基于Python Flask與Echarts插件的豆瓣電影TOP250數(shù)據(jù)分析可視化網(wǎng)站從小工具到完整項目你是不是也有過這種經(jīng)歷想研究豆瓣TOP250到底被哪些年份、哪些地區(qū)的電影霸榜手動一頁頁翻網(wǎng)頁、復制表格到Excel折騰一晚上只得到一份亂七八糟的數(shù)據(jù)。這正是我做這個項目的起點——與其人工扒數(shù)據(jù)不如寫一個把抓取、存儲、分析和可視化串起來的小網(wǎng)站。基于Python Flask與Echarts插件的豆瓣電影TOP250數(shù)據(jù)分析可視化網(wǎng)站本質(zhì)上就是一條完整的數(shù)據(jù)流水線requests抓頁面BeautifulSoup解析SQLite存數(shù)據(jù)Flask提供后端接口和頁面渲染Echarts在瀏覽器里畫出柱狀圖、餅圖和排行表。這套方案不挑機器、不挑系統(tǒng)Windows和Mac都能跑適合剛學完Python基礎想做一個能拿得出手的“數(shù)據(jù)類項目”的人也適合已經(jīng)在做爬蟲但想補上可視化這一環(huán)的開發(fā)者。2. 先把數(shù)據(jù)抓到本地豆瓣TOP250的頁面解析與字段清洗2.1 目標數(shù)據(jù)長什么樣列表頁結(jié)構(gòu)、翻頁規(guī)律與字段清單豆瓣TOP250的列表頁是出了名的簡單規(guī)整每頁固定25條電影一共10頁。它的翻頁參數(shù)就是URL里的start從0開始步長25也就是說第1頁是start0第2頁是start25一直到最后start225。每個電影條目被包裹在ol.grid_view列表的li.item節(jié)點里你要的信息基本都在這個節(jié)點內(nèi)部。我一般會先打開頁面源碼確認字段節(jié)點而不是憑經(jīng)驗寫死選擇器。每個li.item里能拿到的字段包括排名em標簽、片名span.title、導演和主演p里的第一行文本以換行分隔、年份和地區(qū)同一段p里的第二行、評分span.rating_num、評價人數(shù)span.pl、一句話短評span.inq。這些字段的結(jié)構(gòu)經(jīng)年累月基本穩(wěn)定但文字排版偶爾會變化所以清洗邏輯一定要寫得抗造。字段解析節(jié)點清洗后格式備注排名li.item div.pic em整數(shù)全局唯一可作主鍵片名span.title第一個字符串中文名別名不要導演/主演p第一行文本按/拆分字符串取第一位可得到導演年份p第二行文本正則提取四位整數(shù)如“1994”地區(qū)p第二行文本按/拆分字符串可能多地區(qū)取第一個評分span.rating_num浮點數(shù)保留一位小數(shù)評價人數(shù)span.pl去括號整數(shù)常見寫法“1513423人評價”短評span.inq字符串有的片子沒有需判空2.2 抓取腳本requests加BeautifulSoup的最小實現(xiàn)爬蟲這部分我習慣用requests做HTTP請求BeautifulSoup做頁面解析而不是直接用Scrapy。原因很簡單總共只有10個頁面不需要調(diào)度器、中間件那一套重武器單文件腳本足夠清爽出了問題也好定位。下面這個腳本就是整個項目的“數(shù)據(jù)入口”。import requests import time from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 } def fetch_page(start): 抓取單個列表頁返回解析后的電影字典列表 url fhttps://movie.douban.com/top250?start{start}filter resp requests.get(url, headersHEADERS, timeout10) resp.raise_for_status() soup BeautifulSoup(resp.text, html.parser) movies [] for item in soup.select(ol.grid_view li.item): # 節(jié)點缺失時用 try 兜底避免整頁解析中斷 rank int(item.select_one(div.pic em).get_text()) title item.select_one(span.title).get_text() rating float(item.select_one(span.rating_num).get_text()) quote_node item.select_one(span.inq) quote quote_node.get_text() if quote_node else info_lines item.select_one(div.bd p).get_text(\n, stripTrue).split(\n) # info_lines[0] 是導演/主演info_lines[1] 是年份/地區(qū)/類型 year_line info_lines[1] if len(info_lines) 1 else movies.append({ rank: rank, title: title, rating: rating, quote: quote, year_raw: year_line, }) return movies def main(): all_movies [] for start in range(0, 250, 25): all_movies.extend(fetch_page(start)) time.sleep(1) # 控制請求頻率降低被封概率 # 后續(xù)把 all_movies 寫入數(shù)據(jù)文件見下一節(jié) print(f共抓到 {len(all_movies)} 條)我特意用select_one而不是find因為select_one配合CSS選擇器寫起來更像寫選擇器而且天然返回單個節(jié)點或None適合判空。resp.raise_for_status()的作用是狀態(tài)碼非200時直接拋異常避免拿到錯誤頁面還繼續(xù)解析造成假數(shù)據(jù)。time.sleep(1)在本地抓250條時不算慢但對豆瓣這種有反爬機制的站點來說這個間隔是保命的。2.3 數(shù)據(jù)清洗與落地年份、地區(qū)、評分區(qū)間怎么處理抓下來的year_raw是類似“1994 / 美國 / 犯罪 劇情”這種混合文本不能直接用。我通常用正則提取年份再按分隔符拆分地區(qū)和類型最后把結(jié)果規(guī)整成一行一條的結(jié)構(gòu)化數(shù)據(jù)。清洗邏輯放在解析函數(shù)之后、入庫之前單獨寫一個函數(shù)方便后續(xù)換了數(shù)據(jù)源還能復用。import re def clean_movie(movie): 從原始字段里提取年份和地區(qū)補全結(jié)構(gòu)化字段 raw movie.pop(year_raw, ) parts [p.strip() for p in raw.split(/) if p.strip()] year None region 未知 for part in parts: # 年份優(yōu)先匹配四位數(shù)字 m re.search(r(\d{4}), part) if m: year int(m.group(1)) continue # 非年份且非類型詞視為地區(qū) if part not in (劇情, 喜劇, 動作, 愛情, 科幻, 動畫, 懸疑, 犯罪, 冒險, 奇幻, 驚悚, 恐怖, 紀錄片, 音樂, 歌舞, 戰(zhàn)爭, 歷史, 傳記, 運動): region part movie[year] year movie[region] region return movie注意這里的類型詞表是我按TOP250常出現(xiàn)的類型整理出來的實際拿到的頁面數(shù)據(jù)如果有新的類型詞就會誤判成地區(qū)。這是小型爬蟲項目里典型的“硬編碼字典風險”代碼夠用但不完美遇到漏網(wǎng)之魚時只需要往集合里補詞。清洗后的數(shù)據(jù)我一般存成兩路一是movies.json方便調(diào)試時直接看二是SQLite數(shù)據(jù)庫供Flask后端查詢下一章會用到。寫入JSON時別忘了一個關鍵參數(shù)with open(movies.json, w, encodingutf-8) as f: json.dump(all_movies, f, ensure_asciiFalse, indent2)ensure_asciiFalse必須加否則中文片名和地區(qū)全部會變成\u4f60這種轉(zhuǎn)義序列打開文件根本沒法看。這一步我在早期項目里翻過車當時還以為是爬蟲解析出了問題排查了半天才發(fā)現(xiàn)是序列化參數(shù)沒設對。3. Flask后端與API設計動態(tài)頁面渲染和數(shù)據(jù)接口兩條路線3.1 為什么選Flask而不選FastAPI輕量、模板生態(tài)和上手成本做這種規(guī)模的個人項目Flask和FastAPI其實都能勝任但它們的氣質(zhì)完全不同。FastAPI的異步支持、自動OpenAPI文檔和Pydantic校驗都很現(xiàn)代適合前后端分離、接口文檔需求明確的生產(chǎn)級應用。但我的場景是單機自用、帶頁面模板、需要快速跑起來Flask的render_template配合Jinja2模板直接一個函數(shù)出頁面省掉了“前端單獨部署”這一步。更重要的一點是Flask的資料和踩坑記錄遍地都是新手遇到問題很容易搜到同款報錯。如果有朝一日項目要加實時推送、要做高并發(fā)接口那時候再遷移到FastAPI也不遲那是“數(shù)據(jù)量真大了”的問題不是“還沒跑起來”的問題。做這個TOP250項目我不建議在框架選型上過度糾結(jié)先跑通再優(yōu)化比什么都強。3.2 源碼工程的目錄結(jié)構(gòu)一個Flask應用的標準打開方式拿到這類“設計源碼”時最常見的目錄組織方式是這樣的不管源碼作者怎么命名核心就這幾個部分project_root/ ├── app.py # Flask主程序路由和API都在這 ├── spider.py # 爬蟲腳本獨立運行 ├── data/ │ ├── movies.json # 爬蟲輸出的原始數(shù)據(jù) │ └── movies.db # SQLite數(shù)據(jù)庫 ├── templates/ │ └── index.html # Echarts圖表容器頁面 └── static/ ├── echarts.min.js # Echarts庫文件本地引入 └── style.css # 頁面樣式app.py和spider.py分開寫是因為爬蟲部分和網(wǎng)站服務部分是兩條生命周期爬蟲是“偶爾跑一次”的采集任務而Flask應用是“持續(xù)掛著”的服務。如果把兩者寫進同一個文件每次啟動網(wǎng)站都會執(zhí)行一遍爬蟲邏輯既慢又容易觸發(fā)反爬。templates和static是Flask約定的目錄名不要改動否則框架找不到文件。3.3 兩條渲染路線render_template服務端渲染與/api接口前端取數(shù)Flask寫頁面有兩條路。一條是服務端渲染在app.py里讀數(shù)據(jù)庫把數(shù)據(jù)整理成列表或字典直接傳給模板模板里的Jinja2語法把它嵌入頁面。另一條是API取數(shù)后端只提供JSON接口前端頁面加載后用JavaScript的fetch去拿數(shù)據(jù)再由Echarts把數(shù)據(jù)畫成圖表。我在這類項目里的經(jīng)驗是靜態(tài)頁面上做模板渲染沒問題但圖表數(shù)據(jù)一定要走API接口。原因是Echarts的setOption需要接收一個JavaScript對象服務端渲染出來的數(shù)據(jù)要先塞進tojson過濾器再交給前端形態(tài)別扭而API天然返回JSON前端拿過來直接用代碼心智負擔小得多。from flask import Flask, render_template, jsonify, g import sqlite3 app Flask(__name__) DB_PATH data/movies.db def query_db(sql, args()): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row cur conn.execute(sql, args) rows cur.fetchall() conn.close() return rows app.route(/) def index(): # 頁面首次訪問時渲染空殼圖表由前端JS拉取數(shù)據(jù)后繪制 return render_template(index.html) app.route(/api/year-distribution) def year_distribution(): 按年份統(tǒng)計電影數(shù)量返回柱狀圖數(shù)據(jù) rows query_db( SELECT year, COUNT(*) AS cnt FROM movies WHERE year IS NOT NULL GROUP BY year ORDER BY year ) return jsonify([{year: r[year], count: r[cnt]} for r in rows]) app.route(/api/rating-distribution) def rating_distribution(): 按評分區(qū)間統(tǒng)計電影數(shù)量返回餅圖數(shù)據(jù) rows query_db(SELECT rating FROM movies) buckets {9分以上: 0, 8.5-9分: 0, 8-8.5分: 0, 8分以下: 0} for r in rows: rating r[rating] if rating 9: buckets[9分以上] 1 elif rating 8.5: buckets[8.5-9分] 1 elif rating 8: buckets[8-8.5分] 1 else: buckets[8分以下] 1 return jsonify([{name: k, value: v} for k, v in buckets.items()])要注意jsonify在Flask里會自動把響應Content-Type設成application/json前端fetch拿到的res.json()可以直接解析不需要額外處理編碼。sqlite3.Row的作用是讓查出來的每一行能通過r[year]這種字典式訪問拿值比默認的元組形式可讀性強很多。我在query_db里每次查詢都新建連接項目規(guī)模小所以無所謂如果數(shù)據(jù)量大到上百MB你再考慮連接池也不遲。3.4 中文編碼、JSON序列化與排序的邊界問題Flask的jsonify在返回中文時不需要擔心亂碼框架默認會處理UTF-8編碼。真正會翻車的點是如果你不用jsonify而是手動json.dumps一定要帶上ensure_asciiFalse否則你辛辛苦苦抓來的“肖申克的救贖”就變成了\u8096瀏覽器里展示出來的就是一串亂碼。另外還有一個排序問題。jsonify默認按字典的Key排序輸出也就是count會跑到y(tǒng)ear前面。這也就算了關鍵是某些Echarts配置對數(shù)據(jù)順序敏感比如年份柱狀圖橫軸期望按年份升序排如果后端沒加ORDER BY year圖表上的柱子順序就會是亂的。我一般會在SQL層就把排序做掉別指望前端再去排序——減少一個出錯環(huán)節(jié)就少一次排查。4. Echarts圖表怎么接從后端JSON到柱狀圖、餅圖與排行的完整配置4.1 引入方式本地靜態(tài)文件優(yōu)先CDN不是不可以但要有備選Echarts的引入方式直接決定項目在無外網(wǎng)環(huán)境還能不能跑。用bootcdn或jsdelivr的CDN地址確實省事但這類個人項目經(jīng)常要拿到別人的電腦上演示對方一旦沒聯(lián)網(wǎng)或者CDN被解析異常頁面就是一片空白。我的慣例是把echarts.min.js下載后放進static/目錄用本地路徑引用。代價是工程目錄里多一個約1MB的靜態(tài)文件換來的卻是絕對的可移植性。4.2 頁面骨架與基礎配置容器高度、寬度與初始化時序Echarts圖表不渲染十次有九次是容器高度為0。div默認高度由內(nèi)容撐開而Echarts的init方法要求容器必須有明確的寬高。所以頁面里每個圖表容器都要顯式指定高度哪怕是一行styleheight:400px也比不給強。!doctype html html langzh-cn head meta charsetutf-8 title豆瓣電影TOP250數(shù)據(jù)分析/title script src{{ url_for(static, filenameecharts.min.js) }}/script style .chart { width: 90%; height: 420px; margin: 20px auto; } .chart-row { display: flex; gap: 16px; } .chart-row .chart { flex: 1; } /style /head body h2豆瓣電影TOP250 · 可視化看板/h2 div idyearChart classchart/div div classchart-row div idratingChart classchart/div div idregionChart classchart/div /div script src{{ url_for(static, filenamemain.js) }}/script /body /html這里有個值得注意的細節(jié)main.js必須放在/body之前而不是head里。因為圖表初始化需要DOM節(jié)點已經(jīng)存在腳本放前面會找不到y(tǒng)earChart這個id。如果你非要放頭部那就得包一層window.onload或DOMContentLoaded沒必要。模板里的url_for(static, filename...)是Flask的標準靜態(tài)資源路徑生成方式換成寫死的/static/...也能用但前者在項目換目錄部署時不用改代碼。4.3 年份分布柱狀圖坐標軸、標簽旋轉(zhuǎn)與漸變色柱狀圖是這個項目里信息量最大的圖表橫軸是年份1980到2024縱軸是該年份入圍的電影數(shù)量。年份跨度大橫軸標簽如果不做處理每根柱子下面擠滿數(shù)字根本看不清。我一般會把axisLabel的rotate設為45并開啟interval自動抽稀讓Echarts自己決定每幾個年份顯示一個標簽。另外可以做一個隱藏的細節(jié)優(yōu)化用itemStyle.color配合linearGradient做漸變色柱體視覺上會更有“數(shù)據(jù)看板”的氣質(zhì)。// 這個文件是 static/main.js fetch(/api/year-distribution) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(yearChart)); chart.setOption({ title: { text: 豆瓣TOP250電影年份分布, left: center }, tooltip: { trigger: axis }, grid: { left: 50, right: 20, bottom: 60 }, xAxis: { type: category, data: data.map(item item.year), axisLabel: { rotate: 45, interval: auto } }, yAxis: { type: value, name: 影片數(shù)量 }, series: [{ type: bar, data: data.map(item item.count), itemStyle: { color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [ { offset: 0, color: #ff6b35 }, { offset: 1, color: #ffd166 } ]) }, barMaxWidth: 30 }] }); }) .catch(err console.error(年份數(shù)據(jù)加載失敗, err));這段配置里grid的bottom留了60像素不是隨手寫的——因為rotate:45后的年份標簽會向下探出40到50像素底部空間不夠的話標簽會被裁掉。barMaxWidth:30是為了防止某個年份數(shù)量特別大時單根柱子過寬把其他年份擠得顯示不下。這些都是實踐里一點一點試出來的參數(shù)先抄下來用后面再按自己的審美微調(diào)。4.4 評分分布環(huán)形圖餅圖中間的文字和顏色列表評分分布的餅圖適合用環(huán)形圖展示視覺上比實心餅圖輕巧。Echarts里只需要在series里加一個radius: [40%, 70%]內(nèi)徑外徑一設餅圖就變成了環(huán)。環(huán)中間默認是空的很多人想在那里放一個總數(shù)這就涉及一個常見問題——餅圖中間的字怎么加。做法是在series平級的位置添一個graphic組件用text元素定位到畫布中心。fetch(/api/rating-distribution) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(ratingChart)); const total data.reduce((sum, item) sum item.value, 0); chart.setOption({ title: { text: 評分區(qū)間分布, left: center }, tooltip: { trigger: item }, legend: { orient: vertical, right: 10, top: middle }, series: [{ type: pie, radius: [40%, 70%], data: data, label: { show: false }, color: [#5470c6, #fac858, #ee6666, #73c0de] }], graphic: [{ type: text, left: center, top: 45%, style: { text: 總計\n${total} 部, textAlign: center, fontSize: 18, fontWeight: bold } }] }); });graphic組件是Echarts里容易被忽略但很好用的能力它能在canvas上疊加任意圖形或文字而且不參與圖表的數(shù)據(jù)體系。設置left:center和top:45%時Echarts會自動換算成百分比坐標效果大致是文字垂直居中于環(huán)形區(qū)域。color數(shù)組的順序?qū)猟ata數(shù)組的順序注意餅圖扇區(qū)的默認排序會把數(shù)據(jù)從大到小排顏色可能和你預期的分組順序?qū)Σ簧先绻Ｍ伾珖栏駥梢栽趕eries里加sort: (a, b) a.value - b.value控制。4.5 地區(qū)分布橫向條形圖解決國家名過長的問題地區(qū)分布我習慣用橫向條形圖而不是縱向柱狀圖。原因是有些地區(qū)名稱很長“中國大陸 / 中國香港”這種組合在縱向柱狀圖的橫軸下面會被壓縮成斜著的省略號根本讀不出來。橫向條形圖的Y軸天然適合放長文本。實現(xiàn)上只需要把xAxis和yAxis對調(diào)series類型仍然是bar。這個圖表的接口/api/region-distribution在上一章沒寫你可以照著year-distribution的寫法自己補一個核心就是GROUP BY region ORDER BY cnt DESC LIMIT 10重點在前十名地區(qū)后面的地區(qū)數(shù)量少畫出來沒意義。圖的渲染順序也值得注意頁面上一共有三個圖表三個fetch是并行發(fā)出的互不等待。如果某個接口偶發(fā)超時對應圖表會保持空白而其他圖表正常渲染。這不是框架問題是異步加載的正常表現(xiàn)。如果你希望“要么全出要么給個錯誤提示”可以用Promise.all統(tǒng)一加載但那通常不是必要優(yōu)化。5. 常見坑與排查編碼、反爬、圖表白屏的四個血淚現(xiàn)場5.1 豆瓣返回418或403不是代碼寫錯了是請求太像爬蟲現(xiàn)象爬蟲第一次運行能抓到幾十條多跑幾次后resp.status_code變成403或者418頁面內(nèi)容變成了“請求過于頻繁”的驗證頁面。原因豆瓣的反爬機制識別到了高頻請求特征封禁了當前IP的訪問權(quán)限。你做了UA偽裝但沒做頻率控制或者前幾次請求間隔太短被封是必然的。解決把請求間隔從time.sleep(0.5)拉長到time.sleep(2)到time.sleep(3)并給請求頭里的Accept-Language和Referer都補上。如果你想穩(wěn)妥一點可以加一個簡單的重試邏輯狀態(tài)碼非200時等5秒重試一次最多重試3次。爬蟲這東西不是越快越好慢就是快。5.2 JSON文件里全是\uXXXX轉(zhuǎn)義看著像亂碼其實是沒設ensure_ascii現(xiàn)象打開movies.json中文電影名全是\u8096\u514b\u7684\u6551\u8d4e但程序能正常讀取頁面也能輸出正常中文。原因json.dump沒有指定ensure_asciiFalse默認把所有非ASCII字符轉(zhuǎn)義成了Unicode編碼。這個現(xiàn)象只在json.dump和json.dumps里出現(xiàn)寫到SQLite里的數(shù)據(jù)不受影響。解決寫入時統(tǒng)一加ensure_asciiFalse, encodingutf-8再檢查一遍打開文件是否正常。這個坑我在不止一個項目里見過包括有些網(wǎng)上的源碼包本身就沒處理你拿到手覺得“怎么全是亂碼”其實不是數(shù)據(jù)壞了。5.3 圖表白屏但接口正常容器高度為0或初始化時序不對現(xiàn)象瀏覽器控制臺沒有任何報錯fetch能拿到數(shù)據(jù)console.log(data)也能打印出數(shù)組但頁面上圖表區(qū)域就是一片空白。原因兩種可能一是容器的CSS高度沒有設置div的默認高度是0二是echarts.init執(zhí)行時DOM節(jié)點還沒渲染完成。前者最常見后者發(fā)生在你把main.js放在了head里。解決給每個圖表容器加styleheight:420px這種顯式高度把main.js的script標簽移到body底部。如果改完還白屏打開開發(fā)者工具在Elements面板里看容器元素的計算樣式height是不是有值——這一步能定位90%的白屏問題。5.4 分析數(shù)據(jù)比豆瓣頁面少了十幾條頁面結(jié)構(gòu)微調(diào)導致解析漏掉節(jié)點現(xiàn)象網(wǎng)頁上明明250條程序抓完只有235條少的主要集中在某些特定年份。原因個別列表項里的span.inq不存在沒有一句話短評或者p文本里的換行符數(shù)量不一致導致info_lines[1]索引越界整條被continue跳過了。這是典型的“解析邏輯容錯性差”。解決把每個字段的解析都獨立判空解析失敗時該字段置為None而不是跳過整條記錄。另外可以在清洗前打印一下len(movies)對比頁面總數(shù)抓少了就檢查是不是某類節(jié)點結(jié)構(gòu)變了。這種問題沒有什么一勞永逸的解法因為豆瓣前端偶爾改版你的解析代碼需要具備“一個字段拿不到不影響其他字段”的彈性。5.5 Flask應用啟動后頁面能開但樣式全亂靜態(tài)文件路徑被硬編碼現(xiàn)象本地開發(fā)時一切正常把整個目錄放到服務器或者別人的電腦上頁面HTML出來了但圖表和CSS都加載不出來。原因模板里寫了絕對路徑/static/echarts.min.js而不是用url_for(static, filename...)生成。Flask的static路徑在開發(fā)服務器、gunicorn、nginx反代三種場景下前綴可能會有差異硬編碼路徑是最脆弱的寫法。解決模板里統(tǒng)一用{{ url_for(static, filenameecharts.min.js) }}。這個函數(shù)會根據(jù)Flask的配置自動生成正確路徑項目挪位置、加前綴都不需要改頁面代碼。同理API請求地址也盡量用相對路徑/api/year-distribution不要在JavaScript里寫死http://localhost:5000。6. 再往前走一步從單頁圖表到部署上線與自動更新項目跑通只是起點到這個階段你應該已經(jīng)有一份完整可運行的代碼但我建議你再往前走三步把項目從“能跑”變成“有用”。第一步是部署。Flask自帶的開發(fā)服務器只適合調(diào)試真正對外提供服務時我習慣用gunicorn做WSGI容器一條命令搞定gunicorn -w 4 -b 0.0.0.0:8000 app:app。注意-w的進程數(shù)和服務器CPU核數(shù)相關不是越多越好4核機器開4個worker是常見起步配置。部署后如果遇到靜態(tài)文件404優(yōu)先檢查app.secret_key和static_folder這些配置項多數(shù)問題都出在這。第二步是數(shù)據(jù)更新自動化。TOP250榜單不是一成不變的新片入圍、老片退出都是常態(tài)。我給爬蟲加了一個“冪等更新”邏輯按rank字段作為唯一鍵重復抓取時先刪后插保證數(shù)據(jù)庫里永遠是當前最新榜單。配合系統(tǒng)的cron或Windows的任務計劃程序每月自動跑一次spider.py數(shù)據(jù)就永遠是新鮮的。第三步是圖表交互深度?，F(xiàn)在的三個圖表是彼此孤立的進階一點的做法是加一個click事件——點擊年份柱狀圖里的某根柱子右側(cè)的排行榜表格就只顯示該年份的電影。Echarts的chart.on(click, params ...)可以拿到柱子對應的params.name然后帶著這個參數(shù)重新請求一個/api/movies?year1994接口就能實現(xiàn)真正的聯(lián)動。這一步做完這個項目就不再是一個“展示頁”而是一個可交互的分析工具。我在自己折騰這類項目的過程中最大的教訓是別急著寫代碼。先把數(shù)據(jù)字段確認清楚、把目錄結(jié)構(gòu)想明白、把接口路徑定下來后面每一步都會很順。反過來一上來就寫頁面、寫圖表最后經(jīng)常因為數(shù)據(jù)格式對不上反復重構(gòu)那種返工才是最費時間的。這套方案我前后整理過好幾個版本從最早的純表格展示到后來的多圖表聯(lián)動再到現(xiàn)在的自動更新部署每一步都是被真實需求推著走的。希望這套基于Python Flask與Echarts插件的豆瓣電影TOP250數(shù)據(jù)分析可視化網(wǎng)站設計能幫你少走幾步彎路早點把自己想看的數(shù)畫出來。本文還有配套的精品資源點擊獲取