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