简介：基于Python的天气预报系统设计与数据可视化分析项目，面向需要完成课程设计或入门爬虫及桌面应用的Python学习者。资源包含一个可通过Python或Jupyter直接运行的天气查询程序，支持选择多个城市、查看15天预报，并对获取到的天气数据进行绘图处理和本地保存。压缩包共5个文件，含2个Python脚本、1个界面图标、1张运行效果图和1份说明文档，整体约754KB，结构简洁，便于对照查看。目前已有21310人学习下载，适合作为综合练习参考；读者可拿到可直接运行的主程序与数据获取模块，并结合说明文档快速理解爬虫采集、Tkinter界面搭建以及数据可视化输出的实现思路，便于在此基础上扩展城市列表、调整展示样式或接入更多天气数据源。整个项目文件结构紧凑，适合初学者拆解练习，也可直接作为课程设计提交。
1. 基于 Python 的天气预报系统：从数据获取到可视化分析，一次讲透
手机上的天气 App 能告诉你明天几度，但回答不了「这个冬天是不是比往年更冷」「今年 7 月到底下了多少雨」这类问题。要做这种回答，你需要的是历史气象数据、一套清洗逻辑和一张能说服自己的图——这正是「基于 Python 的天气预报系统设计和可视化数据分析」这个方向的真正价值。它不是做一个 App 的壳子，而是把 Python 爬虫/API 请求、pandas 数据处理、SQLite 存储和 matplotlib 可视化串成一条完整链路，最终交付「能查过去、能看趋势、能预测未来」的轻量系统。适合正在学 pandas 和 matplotlib、想找一个完整练手项目的 Python 学习者，也想给简历贴一块「数据分析实战」标签的从业者。这篇文章全是可直接复制运行的代码，配合我踩过的坑一起讲。
2. 天气数据从哪来：公开 API 与爬虫两条路的选择与落地
2.1 先决定数据源：免费 API 优先，爬虫只做补盲
做天气系统，第一步不是写代码，是决定数据从哪来。我一般分两种场景取舍。
如果你的目标是「能跑、能分析、不被封」，优先走免费天气 API。常见的有和风天气的免费开发者版、OpenWeatherMap 的 free tier，还有聚合数据这类第三方接口。它们的共性是：注册后拿一个 key，用 HTTP GET 请求就能拿到 JSON，字段结构稳定，省去了解析 HTML 的时间。缺点是免费额度有限，历史数据往往只能拉到近几天，真正想要「过去三年逐日温度」，免费 API 基本给不了，这时候就得爬网页。
如果你要的是历史数据做趋势分析，爬虫是绕不开的。常见来源是天气后报（lishi.tianqi.com）这类提供历史天气查询的网站，或者中国天气网的历史归档页。爬虫的好处是能拿到 2011 年至今的逐日最高/最低温度、天气现象、风力风向；坏处是页面结构会改，你可能今天写的 selector 下个月就失效。我的个人偏好是：先用 API 搭骨架，验证整条分析链路能跑通，再针对历史缺口写爬虫——这样即使爬虫翻车，系统的核心功能也不会瘫。
下面这段代码是走 API 路线的获取模块，我用 requests 库请求城市天气并解析成本地 DataFrame，这是后面所有分析的地基。
import requests import pandas as pd from datetime import datetime def fetch_weather_from_api(city_key, api_key): """ 通过和风天气 API 获取实时天气数据 :param city_key: 城市ID，例如 101010100 代表北京 :param api_key: 你的开发者密钥 """ url = "https://devapi.qweather.com/v7/weather/now" params = { "location": city_key, "key": api_key, "unit": "metric" # 使用摄氏度，避免华氏单位换算 } resp = requests.get(url, params=params, timeout=10) resp.raise_for_status() data = resp.json() now = data["now"] df = pd.DataFrame([{ "city": data["fxLink"], # 实际城市名可根据 fxLink 解析 "temp": float(now["temp"]), "feels_like": float(now["feelsLike"]), "humidity": float(now["humidity"]), "wind_dir": now["windDir"], "time": datetime.now().strftime("%Y-%m-%d %H:%M:%S") }]) return df if __name__ == "__main__": # 北京为例，真实使用请替换为自己的 API key df = fetch_weather_from_api("101010100", "your_qweather_key_here") print(df.head())这段代码几个关键参数说明一下。unit=metric这个参数容易漏，漏了默认返回华氏，后面你会被 70 度的数据搞晕。timeout=10必须写，天气接口偶尔会慢，不写超时会让程序卡死。raise_for_status()是防御习惯，接口返回 401 或 403 时立即报错，而不是带着错误数据往下跑。第一次跑通后，把 DataFrame 打印出来看一眼，字段是否齐全、温度是否存在非数值，这一步比任何检查都重要。
如果 API 额度用完或者需要历史数据，就得写爬虫。我不建议用 selenium，太重了；requests + BeautifulSoup 足够。核心是找到存放历史天气数据的页面结构，用select定位表格行，逐行解析。下面这个脚本抓的是天气后报的历史天气页面：
import requests from bs4 import BeautifulSoup def crawl_lishi_tianqi(city_code, year_month): """ 抓取天气后报的历史天气数据 :param city_code: 6位城市代码，例如 101010100 :param year_month: 月份，格式 '202307' """ url = f"https://lishi.tianqi.com/{city_code}/{year_month}.html" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" } resp = requests.get(url, headers=headers, timeout=10) resp.encoding = "utf-8" soup = BeautifulSoup(resp.text, "html.parser") rows = soup.select("div.lishi_content ul li") records = [] for row in rows: parts = row.get_text().split(" ") if len(parts) >= 4: records.append({ "date": parts[0], "high": int(parts[1].replace("℃", "")), "low": int(parts[2].replace("℃", "")), "weather": parts[3], "wind": parts[4] if len(parts) > 4 else "" }) return pd.DataFrame(records)这里有个血泪经验：解析天气后报的页面时，直接从ul li里取文本然后 split 是按空格拆，但风力风向可能缺失，导致 parts 长度不稳定。我的习惯是先打印一条原始记录看看结构，再决定按索引取还是按正则取。另外resp.encoding = "utf-8"要主动设置，有些服务器返回的 header 里 charset 是错的，不手动指定会得到乱码。
2.2 多城市批量拉取：用并发还是循环？
做可视化分析时，单城市的数据往往不够看。比如你想对比上海、广州、北京三地夏季气温差异，就需要批量请求。最简单的做法是 for 循环，但慢；requests 库本身不支持异步，但可以用 concurrent.futures 的ThreadPoolExecutor并发请求。下面这段是并发拉取多城市实时天气的模板：
from concurrent.futures import ThreadPoolExecutor, as_completed city_map = { "北京": "101010100", "上海": "101020100", "广州": "101280101", "深圳": "101280601" } def fetch_batch(city_map, api_key, max_workers=4): """ 并发拉取多城市天气 max_workers 控制并发数，免费 API 建议 4~5 个，别开太多 """ results = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: future_to_city = { executor.submit(fetch_weather_from_api, city_id, api_key): city_name for city_name, city_id in city_map.items() } for future in as_completed(future_to_city): city_name = future_to_city[future] try: df = future.result() df["city"] = city_name results.append(df) except Exception as e: print(f"{city_name} 拉取失败: {e}") return pd.concat(results, ignore_index=True)max_workers=4是经验值。免费 API 对同一 key 有 QPS 限制，并发开到 10 容易被限流返回 403。如果发现请求频率高了报错，最简单的方式是降低 max_workers，或者在每次请求后加time.sleep(0.5)——土办法有时候最稳。拉完后的 DataFrame 会包含城市名、温度、湿度等字段，下一步要做的事情是清洗和落库。
3. 数据清洗与落库：把 JSON 转成一张能分析的表
3.1 常见脏数据：缺失值、异常值和单位混用
不管你从 API 拿还是爬虫拿，原始数据都称不上「可分析」。我在实际清洗中遇到最多的是这三类问题：
第一是缺失值。API 偶尔会返回某个字段为空，比如湿度字段在特殊天气下上报为 null；爬虫抓历史天气时，某些日期的风力风向可能没抓到。第二是异常值，比如温度超过 60 度、湿度超过 100，这类数据多半是解析错位导致的。第三是单位混用，华氏和摄氏混在一起，排序时单位不一致，后面画图全是错的。
处理思路分两种情况。如果你是在做历史趋势分析，数据量大，dropna()直接删掉缺失行通常影响不大；如果每一天都很宝贵（比如要做一年的逐日序列），就改用fillna(method='ffill')用前一天的值填补。异常值的处理就一句话：超过物理可能的值就是脏的，直接过滤掉。下面这段代码演示了怎么处理温度和湿度字段：
def clean_weather_data(df: pd.DataFrame) -> pd.DataFrame: """ 清洗天气数据：处理缺失值、过滤异常、统一温度范围 """ df = df.copy() # 1. 删除完全空白的行 df = df.dropna(how="all") # 2. 温度异常过滤：-40℃ ~ 50℃ 属于合理气象范围 df = df[(df["temp"] >= -40) & (df["temp"] <= 50)] # 3. 湿度范围 0~100，超出直接删 df = df[(df["humidity"] >= 0) & (df["humidity"] <= 100)] # 4. 将华氏度转换成摄氏度（如果你的源混用了单位） if df["temp"].max() > 80: df["temp"] = (df["temp"] - 32) * 5 / 9 # 5. 时间字段标准化 df["date"] = pd.to_datetime(df["date"]).dt.strftime("%Y-%m-%d") # 6. 排序，确保时间序列顺序正确 df = df.sort_values("date").reset_index(drop=True) return df这里的第 4 步值得展开说。判断依据是最大值是否超过 80，因为正常情况下没有哪个城市温度会高于 80 度，一旦出现基本可以断定源数据返回的是华氏。这个启发式判断偶尔也有失误（比如异常值本身就是 85），所以稳妥做法是拉取时直接指定单位，API 请求里加unit=metric，不要把清洗的活留给后端。
3.2 SQLite 存储：为什么不用 CSV
数据清洗完之后面临选择：存 CSV 还是存 SQLite？CSV 的好处是直观、Excel 能打开；坏处是当你积累了一两年的数据后，CSV 每次全量读取会越来越慢，而且多城市数据放在一个 CSV 里结构混乱。SQLite 是 Python 内置支持的关系型数据库，单文件、零配置、标准 SQL 查询，非常适合这个体量的项目。
建表时我会把天气数据分成「城市表」和「天气记录表」两张表。城市表存城市代码和城市名，天气记录表存温度和湿度等实测数据。主键用(city_code, date)，这样同一城市同一天的数据不会重复插入——这就是后悔药：如果哪天发现 API 返回了当天重复数据，直接INSERT OR REPLACE不会炸。
import sqlite3 def setup_database(db_path="weather.db"): """ 初始化 SQLite 数据库，创建城市表和天气记录表 """ conn = sqlite3.connect(db_path) cursor = conn.cursor() cursor.execute(""" CREATE TABLE IF NOT EXISTS city ( city_code TEXT PRIMARY KEY, city_name TEXT NOT NULL ) """) cursor.execute(""" CREATE TABLE IF NOT EXISTS weather_daily ( city_code TEXT NOT NULL, date TEXT NOT NULL, high_temp REAL, low_temp REAL, humidity REAL, weather_desc TEXT, wind_dir TEXT, PRIMARY KEY (city_code, date) ) """) conn.commit() conn.close() return db_path def save_weather_to_db(df, db_path="weather.db"): """ 将清洗后的天气数据写入 SQLite df 需要包含 city_code、date、high_temp 等字段 """ conn = sqlite3.connect(db_path) df.to_sql("weather_daily", conn, if_exists="append", index=False) conn.close()这里有个细节：to_sql中的if_exists="append"是追加模式，但如果你连续跑了两次，主键冲突会直接抛异常。我的做法是在写入前先按(city_code, date)去重，或者在建表时用INSERT OR REPLACE。更推荐后者，因为它的逻辑是「有则更新，无则插入」，完全是幂等操作。不过to_sql默认生成INSERT语句，想用OR REPLACE就得绕过to_sql改用executemany。
DB 文件的字段类型也提醒一下：date用 TEXT 存储，格式2024-07-15，这样支持字符串比较，也就是WHERE date > '2024-01-01'直接能用。很多人会纠结用不用时间戳存，我觉得没必要——除非你需要做毫秒级的计算，不然 TEXT 的可读性远比效率重要。
4. 可视化数据分析：用四张图把天气「讲」明白
4.1 中文字体与坐标轴密度：两个最先遇到的坑
数据进了 SQLite，接下来进入最有成就感的环节——可视化分析。用 matplotlib 画天气数据的图，第一个要处理的不是数据，是字体。matplotlib 默认字体不支持中文，你画出来的图全是方块。解决办法是设置plt.rcParams指定中文字体，Windows 用 SimHei，macOS 用 Arial Unicode MS，Linux 服务器得先确认系统装没装中文字体。
第二个高频坑是横坐标日期过密。比如画一年的温度曲线，365 个日期全摆上去，坐标轴就会挤成一坨黑线——这就是热搜里常说的「画图横坐标太密集」。解决思路是设置MaxNLocator控制显示几个刻度，再旋转 45 度让标签错开。下面这段代码是一张完整的 7 天温度趋势图，包含最高温度和最低温度两条曲线：
import matplotlib.pyplot as plt import matplotlib.dates as mdates from matplotlib.ticker import MaxNLocator def plot_temp_trend(df, city_name="北京"): """ 画一个城市近 N 天的最高/最低温度趋势线 """ plt.rcParams["font.family"] = ["SimHei"] # 微软雅黑也可以 plt.rcParams["axes.unicode_minus"] = False # 解决负号显示为方块的问题 fig, ax = plt.subplots(figsize=(12, 5)) # 确保日期列是 datetime 类型，这事不能偷懒 df["date"] = pd.to_datetime(df["date"]) ax.plot(df["date"], df["high_temp"], marker="o", markersize=3, linewidth=1.5, label="最高温度") ax.plot(df["date"], df["low_temp"], marker="s", markersize=3, linewidth=1.5, label="最低温度") ax.set_title(f"{city_name} 温度趋势", fontsize=16, pad=15) ax.set_ylabel("温度 (℃)") # 核心：控制横坐标刻度数，避免挤成一坨 ax.xaxis.set_major_locator(MaxNLocator(nbins=10)) plt.xticks(rotation=45, ha="right") ax.legend() ax.grid(alpha=0.3) plt.tight_layout() plt.show()MaxNLocator(nbins=10)表示最多显示 10 个刻度标签，matplotlib 会根据数据范围自动挑均匀散布的日期。rotation=45和ha="right"是配套的，前者旋转文字，后者对齐避免标签重叠。这个参数组合是我做过多次试验后确认最稳妥的，横坐标不管塞 30 天还是 365 天的数据都能正常显示。markersize=3是一个审美参数，数据点太多时把点缩小一点，图面更干净。
4.2 降雨量与湿度的可视化：时序柱状图和双轴图
温度趋势对应折线图是典型的，但天气分析远不止温度。降雨量和湿度是农业、户外活动决策的重要参考。画降雨量我建议用柱状图，因为它是离散事件——某天下了 10mm，某天没下，柱状图能直观看出「哪天是降雨日」。而当你需要把降雨量和温度两条序列放在同一张图里对比时，就得考虑双 y 轴。
双轴图是可视化里一个经典的坑：两张图共享 x 轴，但 y 轴量纲不同。温度在 -10 到 35 之间，降雨量在 0 到 50 之间，直接画在同一个 y 轴会导致其中一条被压扁。解决办法是twinx()创建第二个 y 轴。下面这段代码就是把降雨量和温度放在一起对比：
def plot_precip_and_temp(df): """ 双 y 轴图：柱状图表示降雨量，折线图表示温度 """ plt.rcParams["font.family"] = ["SimHei"] fig, ax1 = plt.subplots(figsize=(12, 5)) ax2 = ax1.twinx() # 创建共享 x 轴的第二个 y 轴 # 左轴：降雨量柱状图 bars = ax1.bar(df["date"], df["precipitation"], color="#4C72B0", alpha=0.6, label="降雨量 (mm)") ax1.set_ylabel("降雨量 (mm)", color="#4C72B0") ax1.tick_params(axis="y", labelcolor="#4C72B0") # 右轴：温度折线图 line = ax2.plot(df["date"], df["high_temp"], color="#C44E52", linewidth=2, label="最高温度") ax2.set_ylabel("最高温度 (℃)", color="#C44E52") ax2.tick_params(axis="y", labelcolor="#C44E52") # 图例合并处理，否则会漏掉一条 h1, l1 = ax1.get_legend_handles_labels() h2, l2 = ax2.get_legend_handles_labels() ax1.legend(h1 + h2, l1 + l2, loc="upper left") ax1.xaxis.set_major_locator(MaxNLocator(nbins=8)) plt.xticks(rotation=45, ha="right") plt.title("降雨量与最高温度对比", pad=15) plt.tight_layout() plt.show()这段代码里最容易被忽略的是最后图例合并的部分。ax1.plot和图例不会自动包含ax2的元素，不合并的话，要么温度线的图例消失，要么降雨量的图例消失，标准翻车现场。用get_legend_handles_labels()把两个轴的 handle 和 label 拿回来拼在一起，才能得到一张完整的图。
5. 更进一步：用线性回归做简单的温度预测
可视化只能回答「过去发生了什么」，但天气预报系统的核心势必要回答「明天几度」。完整做温度预测需要 LSTM 或 Prophet 这类模型，但对这个标题的体量来说，线性回归已经能给出一个可以接受的经验性参考值。它的逻辑是：明天的温度与今天、昨天的温度有强线性相关，用过去 N 天的温度作为特征，训练一个普通最小二乘回归，预测未来一天的数值。
from sklearn.linear_model import LinearRegression from sklearn.model_selection import train_test_split from sklearn.metrics import mean_absolute_error import numpy as np def build_prediction_model(df): """ 使用过去 7 天的最高温度预测明天的最高温度 """ df = df.sort_values("date").reset_index(drop=True) temps = df["high_temp"].values # 构造时序特征：X 是最近 7 天的温度，y 是第 8 天的温度 X, y = [], [] window_size = 7 for i in range(window_size, len(temps)): X.append(temps[i - window_size:i]) y.append(temps[i]) X = np.array(X) y = np.array(y) # 划分训练集和测试集，注意时序数据不能乱序 shuffle train_size = int(len(X) * 0.8) X_train, X_test = X[:train_size], X[train_size:] y_train, y_test = y[:train_size], y[train_size:] model = LinearRegression() model.fit(X_train, y_train) y_pred = model.predict(X_test) mae = mean_absolute_error(y_test, y_pred) print(f"平均绝对误差: {mae:.2f} ℃") # 返回模型和最后 7 天的数据，用于预测明天温度 return model, temps[-window_size:] def predict_tomorrow(model, last_window): """ 输入最近 7 天温度，输出明天预测温度 """ pred = model.predict(last_window.reshape(1, -1)) return pred[0]这里的训练测试划分与普通机器学习有本质区别：时序数据绝对不能随机 shuffle。如果你用train_test_split(shuffle=True)，测试集会包含比训练集更早的数据，等于用未来预测过去，误差低得毫无意义。我当时第一次跑就是这么干的，MAE 只有 0.3 度，高兴了没几分钟就意识到是数据泄漏，白高兴一场。正确的做法是train_size按位置切，前 80% 训练，后 20% 测试，保证测试集永远是训练集之后的时段。
MAE的值也有参考意义：若预测误差在 2 度以内，说明这套线性方法在这个城市还够用；如果超过 3 度，说明温度变化与历史 7 天的线性关系不强，就该考虑加特征了，常见的做法是把「日期对应的季节」「是否下雨」「湿度」加进特征矩阵，这些都可以从数据库里直接 join 出来。
6. 避坑与进阶：五条踩坑记录和把这个系统变可用的技巧
6.1 排查与避坑：现象、原因、解决
以下五条是我实际开发中反复踩过的坑，按「现象 → 原因 → 解决」记录，照着排查能省掉一下午的抓瞎时间。
坑一：JSON 解码报错Expecting value: line 1 column 1现象：调用天气 API 时报 JSON 解析失败。原因：请求被网关拦截，返回的不是 JSON 而是 HTML 错误页；或者接口 key 失效返回了纯文本。解决：打印resp.status_code和resp.text[:200]看真实返回，先确认是不是 200，再确认内容是 JSON 结构。不要用爬虫的 response 直接调.json()，永远先看文本再解析。
坑二：时间戳转出来比当地快 8 小时现象：API 返回的时间字段转成北京时间后不对，差了几个小时。原因：API 返回的 unix 时间戳是 UTC 时区的，没有指定tz直接datetime.fromtimestamp()用的是本地时间还是 UTC 取决于服务器设置。解决：统一用datetime.utcfromtimestamp(ts)然后手动加上timedelta(hours=8)，或者直接用pandas.to_datetime(ts, unit="s", utc=True).dt.tz_convert("Asia/Shanghai")。关键是一套代码里只认一个时区，别混用。
坑三：matplotlib 画出来全是方块现象：标题、坐标轴中文全部显示成空心方块。原因：matplotlib 默认字体是 DejaVu Sans，不含中文字符。解决：plt.rcParams["font.family"] = ["SimHei"]，Linux 环境下要先apt install fonts-wqy-microhei装文泉驿字体，再指定["WenQuanYi Micro Hei"]。注意axes.unicode_minus也要设成False，否则负号也会变成方块。
坑四：横坐标时间标签挤成一坨现象：日期刻度全部重叠，看不清任何标签。原因：x 轴刻度数是 matplotlib 自动生成的，数据点多时它会尝试全部显示。解决：MaxNLocator(nbins=8)限制显示 8 个刻度，配合rotation=45旋转文本。另外一个隐藏坑是ha="right"没写，旋转后的标签中心对齐会把相邻标签撞一起。
坑五：免费 API 拉两三天接口就 403现象：同一台服务器，前三天好好的，第四天开始请求全部返回 403。原因：免费 key 有每日请求次数限制，你写了个定时任务每小时拉一次，一天把一周的额度用完了。解决：拉取后缓存到 SQLite，同一城市同一天的数据命中缓存就不重复请求；或者拉取频率降到每 6 小时一次，写代码时加一层缓存检查逻辑，这也是为什么我强调数据分析前要先落库——数据库天然就是缓存层。
6.2 进阶：把脚本变成真正可用的天气分析系统
一个单次运行的脚本距离「系统」还差两步：自动化和接入。自动化最简单的方式是 APScheduler 定时任务，每天凌晨 6 点拉一次数据、追加进 SQLite：
from apscheduler.schedulers.blocking import BlockingScheduler def scheduled_job(): # 拉取数据、清洗、入库，这一流程就是前面所有代码的整合 print(f"{datetime.now()} 开始同步天气数据...") raw_df = fetch_weather_from_api("101010100", "your_key") clean_df = clean_weather_data(raw_df) save_weather_to_db(clean_df) scheduler = BlockingScheduler() scheduler.add_job(scheduled_job, "cron", hour=6, minute=0) scheduler.start()之后你想看趋势，只需要写一个查询脚本从 SQLite 里读近 30 天数据，直接调用已经写好的plot_temp_trend画图，不需要重新请求网络。这里有一个值得养成的习惯：网络请求和数据分析分层。请求层只管拿数据，不管画图；分析层只管读库和可视化，不管网络。分层后 API 挂了不影响已经入库的数据继续做分析，整个系统的容错性会好很多。
另外一个有价值的进阶是「多城市对比」。把爬虫或 API 的拉取目标从单个城市扩展到多个城市，清洗入库后在查询时加一个城市维度的 group by。你会看到很直观的结论：同一天里，广州湿度 90% 的时候北京可能只有 20%，这种横向对比是单城市数据完全展示不了的。
这些进阶手段都不需要改核心代码，关键在于你一开始设计数据结构时有没有为「城市」和「日期」留字段。我见过太多人把城市名直接写死在文件名里，后面想扩展时推倒重来。教训是：哪怕你只计划做一个城市，也请把city_code存进表里，这个习惯能给你留出无数的「后悔药」。
希望这篇从数据获取到预测到落库再到可视化的全流程拆解能帮到你，照着跑通一遍，再慢慢调参。
本文还有配套的精品资源，点击获取
