我花了一个周末把这个小工具做了出来输入城市名就能看到未来一周的温度曲线、降雨趋势、风力变化还能把几个城市拉到同一个图表里对比。底层用的就是 Flask前端图表用 ECharts 渲染。最初只是为了自己出门前不用翻来翻去对比天气 App后来发现同事也在用就顺手把代码梳理干净写成了这种可以直接跑起来的工程结构。如果你也想做一个天气数据可视化的小项目或者想把 Flask 和可视化打通却不知道怎么落地下手这篇内容应该能帮你省掉不少弯路。我先把核心思路放前面整个项目不复杂关键就是把“数据获取”“逻辑聚合”和“前端展示”三层拆干净然后让每一层都独立可替换。这个设计决定了后面所有开发体验——数据源换了不需要动页面页面改版不需要碰接口部署也只是把 Flask 服务和静态文件交出去而已。1. 项目整体设计与技术选型背后的取舍1.1 这个项目到底在解决什么问题城市天气可视化核心不是拿到天气数据而是把多城市、多指标、多时间粒度的数据变成一眼能看懂的图形。每天打开天气 App 只能看到一个城市的实时状态想看未来一周温差的极端情况、比较几个城市哪个适合周末出游、判断某天降水概率高不高都需要来回切换界面去拼信息。这个项目做的就是聚合和对比后端统一请求多个城市的数据按日期对齐前端用折线图、柱状图、极坐标图把趋势和分布呈现出来。遇到“北京未来七天最高气温走势如何”“上海和杭州谁更适合下雨天出行”“这周哪天风力最小适合洗车”这类问题打开页面扫一眼就有答案不需要自己拿 Excel 重新整理一轮。这个需求约束了技术选型数据要动态获取并频繁更新所以必须走后端接口而非静态文件分析是多维度的所以图表库要足够灵活用户大概率是个人或小团队部署环境不复杂所以框架要轻。Flask 几乎是为这个场景量身定做的——它不像 Django 那样自带全套脚手架可以把所有力气花在业务逻辑上。1.2 为什么选 Flask 而不是其他框架很多人纠结 Flask 和 FastAPI 的关系。老实说如果今天重新选型FastAPI 的异步性能和自动接口文档很有吸引力但 Flask 在这类中小型数据展示项目中仍然有不可替代的优势生态成熟、资料多、部署简单公司服务器上随手就能跑起来出了问题随手一搜都有答案。更重要的是Flask 的扩展机制让项目保持简洁。这个项目里我只用了 Flask 本体的路由和模板渲染加一个 requests 做数据请求再加一个缓存字典做数据复用没有引入重量级依赖。对比如果用 Django光是配置 DRF、CORS、模板引擎这些就要折腾半天对一个天气展示工具来说明显过重。用一句话概括选型逻辑数据可视化项目最怕的不是框架性能不够而是你被框架繁琐的配置拖着走最后连核心的图表逻辑都没时间打磨。Flask 的“微”恰恰让开发者聚焦在数据怎么处理、图表怎么呈现这两件正事上。1.3 整体架构设计数据层、服务层、表现层分离代码目录我是这样组织的weather_project/ ├── app.py # Flask 入口路由注册 ├── weather_service.py # 数据获取与缓存逻辑 ├── data_cleaner.py # 数据清洗与结构化 ├── templates/ │ └── index.html # 主页面 ├── static/ │ ├── css/ │ └── js/ │ ├── charts.js # 图表渲染逻辑 │ └── api.js # 前端请求封装 └── requirements.txt三层分离的思路weather_service.py只负责向第三方数据源要数据、统一数据格式、做缓存data_cleaner.py负责把原始 JSON 中的脏字段清洗成前端可用的结构化数据app.py只做路由映射和数据透传前端charts.js专注把接口返回的数据变成 ECharts 配置项。这样分层带来一个直接好处上线后更换数据源时只需要重写weather_service.py中的获取方法接口返回结构不变前端完全不受影响。有一次我因为数据源限流临时切换备用接口前端一行代码都没改切换只需要改一个配置项。2. 数据源选型与天气数据的获取处理2.1 三种天气数据获取方式实测对比我先后测过三种主流方案高德开放平台的天气接口、和风天气 API、以及直接爬中国天气网。用表格对比更直观方案免费额度数据完整度反爬难度稳定性我的评价高德天气 API个人认证相对宽松实时未来4天预报无正规接口很稳最适合入门和风天气 API有免费试用QPS受限实时未来7天逐小时无正规接口有配额限制数据丰富但免费额度紧张爬取中国天气网无限制但合规有风险实时未来7天较高需要处理动态加密参数容易被封不推荐生产用我最终选了高德原因是“免费、够用、稳定”。个人开发者做学习项目不需要追求预报天数无限长和逐小时颗粒度实时加未来 4 天足以支撑一周趋势分析。而且高德的接入方式极其简单一个 HTTP GET 请求带 key、城市编码和 extensions 参数就返回完整 JSON不用处理签名、加密这些额外麻烦。注意一点使用任何第三方天气接口前先去对应开放平台看最新的使用条款和配额说明。高德的个人开发者 key 有每日调用量的限制这个项目里我做了缓存来降低请求频率后面会专门讲到。2.2 用 requests 拉取天气数据并做好异常兜底高德天气接口的调用方式很简单核心参数是城编码adcode例如北京是 110000上海是 310000。请求代码如下import requests import json API_URL https://restapi.amap.com/v3/weather/weatherInfo def fetch_weather_from_amap(city_code: str, api_key: str) - dict: params { key: api_key, city: city_code, extensions: all } try: resp requests.get(API_URL, paramsparams, timeout5) resp.raise_for_status() data resp.json() except requests.exceptions.Timeout: print(f[WARN] 请求超时: {city_code}) return {} except requests.exceptions.RequestException as e: print(f[ERROR] 请求失败: {city_code}, {e}) return {} if data.get(status) ! 1: print(f[ERROR] 接口返回异常: {data.get(info)}) return {} forecasts data.get(forecasts, []) if not forecasts: return {} return forecasts[0]这里有几个容易被忽视的关键点。timeout5必加否则某一个城市请求卡住会拖慢整个应用。返回状态判断必须用data.get(status) ! 1而不是直接信任status_code——HTTP 200 只代表请求到达了服务器业务逻辑上可能依然返回错误码。每次请求打印日志并返回空字典兜底防止前端拿到 None 直接崩溃。2.3 数据清洗把嵌套 JSON 变成结构化表格高德返回的数据是嵌套的直接丢给前端会让 ECharts 的配置变得很痛苦。我需要做一次扁平化处理把“每天的最高温度、最低温度、白天天气、夜间天气、风力等级、降水概率”提取成前端友好的列表结构。清洗逻辑如下def clean_forecast(raw_forecast: dict) - dict: city raw_forecast.get(city, 未知城市) adcode raw_forecast.get(adcode, ) casts raw_forecast.get(casts, []) daily_list [] for cast in casts: daily_list.append({ date: cast.get(date), day_weather: cast.get(dayweather), night_weather: cast.get(nightweather), day_temp: cast.get(daytemp), night_temp: cast.get(nighttemp), day_wind_direction: cast.get(daywind), day_wind_power: cast.get(daypower), }) return { city: city, adcode: adcode, daily: daily_list }为什么必须写这一步因为 ECharts 的折线图要求 x 轴是日期数组、y 轴是温度数组而原始 JSON 把每天的数据打散成字典列表。前端如果直接处理嵌套结构需要在 JavaScript 里做二次数据变换既增加代码量也容易出 bug。后端把脏活干了前端只负责 map 一下指定字段就能渲染。2.4 缓存策略避免频繁请求数据源被限流免费天气接口的 QPS 配额通常不高而可视化页面一旦被多人访问每次刷新都会触发多个城市的数据请求极容易触发限流。我加了一个简单的 TTL 缓存来解决import time class WeatherCache: def __init__(self, ttl_seconds600): self.cache {} self.ttl ttl_seconds def get(self, city_code: str): item self.cache.get(city_code) if item and time.time() - item[timestamp] self.ttl: return item[data] return None def set(self, city_code: str, data: dict): self.cache[city_code] { data: data, timestamp: time.time() }缓存时间设为 600 秒也就是 10 分钟刷新一次。这个值可以按需求调整追求数据新鲜度就缩短到 300 秒担心被限流就调到 1800 秒。实测下来高德对个人 key 的容忍度还算高10 分钟窗口内即使有 5 个城市的数据也不会触发限流。3. Flask 后端核心接口设计与实现3.1 应用入口与路由规划Flask 应用在app.py中定义路由只有三个根路径返回页面接口路径返回指定城市 JSON外加一个示例页测试用。from flask import Flask, jsonify, render_template from weather_service import WeatherService app Flask(__name__) weather_service WeatherService() app.route(/) def index(): return render_template(index.html) app.route(/api/weather) def api_weather(): city_code request.args.get(city_code, 110000) data weather_service.get_city_weather(city_code) if not data: return jsonify({code: 1, msg: 暂无数据, data: None}) return jsonify({code: 0, msg: success, data: data}) app.route(/api/weather/batch) def api_weather_batch(): city_codes request.args.get(city_codes, ) codes [c.strip() for c in city_codes.split(,) if c.strip()] result {} for code in codes[:10]: result[code] weather_service.get_city_weather(code) return jsonify({code: 0, data: result}) if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)/api/weather/batch这个接口是给“多城市对比”功能用的一次性传入多个城市编码用逗号分隔。注意我限制了最多 10 个城市避免单人请求把数据源配额瞬间打爆。这里有一个设计决策我特意保持了简单所有接口都返回统一的 JSON 结构code0是成功code1是业务异常前端只需要判断这一个字段。没有用 REST 的 404 语义去承载业务错误因为前端判断逻辑越简单越不容易出问题。3.2 服务层封装缓存与数据源解耦WeatherService是连接路由层和数据源的中间层它只做三件事查缓存、缓存未命中时取新数据、写入缓存。class WeatherService: def __init__(self): self.cache WeatherCache(ttl_seconds600) self.api_key os.environ.get(AMAP_API_KEY, ) def get_city_weather(self, city_code: str) - dict: # 优先返回缓存 cached self.cache.get(city_code) if cached: return cached # 缓存未命中请求数据源 raw fetch_weather_from_amap(city_code, self.api_key) if not raw: return {} cleaned clean_forecast(raw) self.cache.set(city_code, cleaned) return cleanedAPI key 用环境变量AMAP_API_KEY传入而不是硬编码在代码里。这是非常重要的一步如果项目推到公开仓库key 会跟着代码一起泄露之后任何人的请求都计入你的配额。用环境变量即使代码公开key 依旧安全。3.3 跨域问题开发时的常见大坑如果你用 Flask 提供 JSON 接口、前端用静态服务器单独打开页面一定会在浏览器控制台看到 CORS 错误。这个项目最简单的方式是 Flask 直接渲染模板让前后端同源完全绕过跨域问题。但如果你的场景必须前后端分离就需要引入 Flask-CORS 扩展pip install flask-corsfrom flask_cors import CORS CORS(app)我的建议是个人项目和学习项目能用同源尽量同源少一个依赖就少一个变量。生产环境如果确实要前后端分离再用 CORS 也不迟。3.4 开发模式和生产模式的切换Flask 自带的开发服务器有调试模式但绝对不能直接在生产环境对外暴露。app.run(debugTrue)在开发阶段很方便能自动重载和显示错误详情但这些功能在生产环境是安全隐患。我的做法是在环境变量里区分配置import os if os.environ.get(FLASK_ENV) production: app.run(host0.0.0.0, port8000, debugFalse) else: app.run(host0.0.0.0, port5000, debugTrue)生产环境用 Gunicorn 启动服务不需要 Flask 的开发服务器。启动命令很简单gunicorn -w 4 -b 127.0.0.1:8000 app:app四个 worker 对这个项目来说够用了。如果天气数据接口本身耗时较长平均 300-500msworker 太少会导致并发请求排队明显。4. 前端可视化ECharts 图表的实现细节4.1 为什么从前端渲染而不是后端生成图片项目最初我考虑过用 Python 的 matplotlib 直接把图片画好传给前端但很快否掉了这个方案。原因有三个后端每次要跑完绘图再输出图片响应变慢matplotlib 生成的中文标签在服务器上经常乱码交互效果差用户没法悬停看数据点、拖拽缩放。ECharts 是纯前端 JS 方案同样的数据交给浏览器渲染动画流畅且支持完善的交互。而且 ECharts 的 API 非常直观配置项就是普通的 JavaScript 对象通过 Ajax 拿到后端数据之后直接 setOption十分钟就能上手。4.2 页面布局与核心图表类型选择主页面我设计为两行网格第一行是当前天气概况卡片和 7 天温度趋势折线图第二行是多城市温度对比柱状图和风况极坐标图。下方还有一张降水概率分布表通过表格展示而不是图表因为表格在精确值查看上更友好。各图表的选择逻辑温度趋势用折线图因为要强调“连续变化”和“波动趋势”折线图最能直观反映升温降温节奏。多城市对比用柱状图因为城市之间是离散类别柱状图高度差能在瞬间传达对比信息。风向和风力用极坐标玫瑰图这是展示各方向出现频率最经典的方案。4.3 核心图表代码示例温度趋势折线图是最核心的一个我从接口获取数据后需要组织成dates和temps两个数组async function renderTempTrend(cityCode) { const resp await fetch(/api/weather?city_code${cityCode}); const result await resp.json(); if (result.code ! 0 || !result.data) { showError(数据加载失败); return; } const daily result.data.daily; const dates daily.map(item item.date); const highTemps daily.map(item parseInt(item.day_temp, 10)); const lowTemps daily.map(item parseInt(item.night_temp, 10)); const chart echarts.init(document.getElementById(tempChart)); chart.setOption({ tooltip: { trigger: axis }, legend: { data: [最高温, 最低温] }, xAxis: { type: category, data: dates }, yAxis: { type: value, name: 温度(°C) }, series: [ { name: 最高温, type: line, smooth: true, data: highTemps, lineStyle: { width: 3 }, areaStyle: { opacity: 0.15 } }, { name: 最低温, type: line, smooth: true, data: lowTemps, lineStyle: { width: 3 }, areaStyle: { opacity: 0.15 } } ] }); }这里有个小细节parseInt必须指定进制参数10。后端返回的day_temp是字符串如果不加进制参数在个别场景下会出现字符串拼接而不是数值相加图表数据就会莫名其妙地错乱。4.4 多城市对比与风况玫瑰图实现多城市对比用的是 horizontal 柱状图城市显示在 y 轴温度值显示在 x 轴。为了让对比更直观我取的是每个城市未来 7 天的平均最高温async function renderCityCompare(cityCodes) { const resp await fetch(/api/weather/batch?city_codes${cityCodes.join(,)}); const result await resp.json(); if (result.code ! 0) return; const cities []; const avgTemps []; Object.values(result.data).forEach(item { if (!item) return; const avg item.daily.reduce((acc, cur) { return acc parseInt(cur.day_temp, 10); }, 0) / item.daily.length; cities.push(item.city); avgTemps.push(avg.toFixed(1)); }); const chart echarts.init(document.getElementById(cityChart)); chart.setOption({ tooltip: { trigger: axis }, xAxis: { type: value, name: 平均最高温(°C) }, yAxis: { type: category, data: cities, inverse: true }, series: [{ type: bar, data: avgTemps, barWidth: 20, label: { show: true, position: right } }] }); }风况玫瑰图需要把后端返回的“东风3级、南风4级”这种字符串拆分成“方向”和“风力”两个维度。我干脆在清洗层加了一段简易解析代码把风向转成角度范围风力转成数字这样前端就不用再做字符串切割了。4.5 交互细节点击城市切换、自动轮播、响应式页面顶部放了下拉选择框用户切换城市后所有图表统一重新渲染。为了让切换体验更流畅我把“获取数据渲染图表”封装成一个refreshAll(cityCode)函数在一个函数内完成所有图表的数据获取和更新避免多次点击导致图表数据不同步。另外一个很实用的小技巧是窗口缩放自适应ECharts 容器在窗口 resize 时不会自动调整大小必须手动触发chart.resize()。监听 window 的 resize 事件节流后统一调用所有图表的 resize 方法就能保持布局整齐。window.addEventListener(resize, throttle(() { tempChart.resize(); cityChart.resize(); windChart.resize(); }, 200));5. 部署上线从本地跑到云服务器的完整路径5.1 环境准备与依赖打包部署的第一步是固定依赖版本。我先把本地所有依赖导出到 requirements.txtpip freeze requirements.txt重点确认Flask、requests、gunicorn三个包的版本。服务器上使用虚拟环境安装避免污染系统 Pythonpython3 -m venv venv source venv/bin/activate pip install -r requirements.txt5.2 Gunicorn 启动 Flask 应用生产环境不建议用 Flask 自带的开发服务器我用 Gunicorn 接管应用gunicorn -w 4 -b 127.0.0.1:8000 app:app --daemon --pid gunicorn.pid参数说明-w 4启动 4 个 worker 进程-b 127.0.0.1:8000绑定本机端口--daemon后台运行。这里的app:app意思是导入app.py文件中的app实例。绑定 127.0.0.1 而不是 0.0.0.0 是刻意的外层由 Nginx 接收公网请求内层只需要把服务绑定在回环地址上避免外部直接访问 8000 端口多一层安全保护。5.3 Nginx 反向代理配置Nginx 在这里做反向代理和静态文件服务。静态资源JS、CSS直接由 Nginx 托管动态接口才转发给 Gunicornserver { listen 80; server_name weather.example.com; location /static/ { alias /opt/weather_project/static/; expires 7d; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }location /static/加上expires 7d很关键静态资源 7 天内不会重新请求大幅降低服务器带宽压力。但如果你改动了 JS 文件浏览器可能还是加载旧版本这时候需要在 Nginx 配置里调整 expires或者给静态资源路径加版本号。5.4 部署过程中的经典大坑我部署时踩过最大的坑是端口被占用。Gunicorn 用--daemon后台运行后如果你直接改代码再启动一次会发现 bind 失败Address already in use。原因是上一次的 Gunicorn 进程还占着端口。排查命令lsof -i:8000然后 kill 对应进程再重新启动。最好写成脚本pkill -f gunicorn || true sleep 1 gunicorn -w 4 -b 127.0.0.1:8000 app:app --daemon还有一个隐蔽问题代码修改后 Gunicorn 不会自动加载新代码必须重启进程。我调试时经常改完代码忘记重启一直以为代码有 bug查了半天发现进程里跑的还是旧版本浪费时间。建议每次修改代码后有意识地执行一遍重启命令。5.5 域名访问与 HTTPS 的后续扩展如果项目部署在云服务器上且绑定域名强烈建议配置 HTTPS尤其当页面会被多人访问时。用 certbot 签发证书并修改 Nginx 配置只需要十几分钟却能避免浏览器显示“不安全”警告也保护了交互数据。不过这是另一个话题了如果你只想在内网或者开发环境展示HTTP 加 IP 访问也完全够用。6. 常见问题与排查技巧实录这一节把我实际运行中遇到的典型问题整理成速查表发现问题可以直接对照解决。现象可能原因解决方法图表空白接口返回 code1高德 API key 未设置或失效检查环境变量AMAP_API_KEY是否正确部分城市请求超时数据源响应慢或被限流增加缓存 TTL检查日志中的 timeout 记录中文标签乱码ECharts 默认字体在服务器环境缺失确保静态资源路径正确不涉及浏览器字体问题页面加载慢首次请求多个城市的数据源耗时过长前端增加 loading 动画后端预写缓存Gunicorn 启动报 Address already in use旧进程残留占端口pkill -f gunicorn后重启修改代码后页面无变化Gunicorn 未重启加载新代码每次修改后执行重启脚本6.1 数据源返回异常的处理套路我遇到过最头疼的一次是天气接口突然开始返回status: 0排查了半天发现不是我代码的问题而是高德那边调整了接口策略需要重新在控制台申请配额。从那以后我养成了一个习惯在WeatherService里加一个降级逻辑当缓存未命中且数据源请求失败时至少返回上一次成功获取的旧数据而不是直接返回空。这个“弱化实时性、强化可用性”的思路非常适合展示类应用。用户能够看到昨天的天气数据比看到一片错误提示要友好得多。6.2 前端图表偶发加载不出数据的排查顺序遇到图表加载不出来我习惯按照这个顺序排查先看浏览器 Network 面板里接口是否返回 200返回体是否有数据。再在 Console 里打印result.code确定是不是业务层面报错。检查后端日志确认是请求超时、限流还是 key 失效。在renderTempTrend函数里打断点确认数据是否成功赋值给daily。大多数时候问题出在第二步和第三步之间Flask 接口正常返回但result.data为空接着前端就跳过渲染逻辑。所以我后来在接口层做了兼容即使没有数据也返回{ code: 0, data: null }让前端有明确的 null 判断分支而不是在代码里到处抛异常。6.3 缓存命中率优化的小技巧项目上线后我发现每天缓存命中率并不理想因为大部分用户集中在上午 8-10 点访问这期间每个城市的缓存都已经失效导致所有请求同时打向数据源。解决方案很简单在WeatherService初始化时预拉取热门城市的数据把缓存提前填充好。DEFAULT_CITY_CODES [110000, 310000, 440100, 320100] class WeatherService: def __init__(self): self.cache WeatherCache(ttl_seconds600) self.api_key os.environ.get(AMAP_API_KEY, ) self.preheat() def preheat(self): for code in DEFAULT_CITY_CODES: self.get_city_weather(code)这样在服务启动后的第一波用户请求到来时数据已经在缓存里响应时间可以从 300ms 降到 10ms 以内。注意preheat是在构造函数里同步执行如果担心启动时间太长可以放在后台线程中跑。6.4 前端报安全错误排查如果你的页面不是同源部署比如本地用 Vite 的 5173 端口开发、后端跑在 5000 端口浏览器一定会拦截跨域请求。报错信息里如果出现Access-Control-Allow-Origin基本就是 CORS 没配好。解决方式很简单两种选一个后端引入flask-cors并启用 CORS。前端配置开发服务器代理把/api转发到后端。推荐第二种方案它不会污染生产环境的网络策略。开发环境中 Nginx 代理和生产环境的 Nginx 配置用同一套思路跨域问题在源头上就避开了。最后分享一点个人体会做完这个项目我最大的感受是可视化分析项目的难点往往不在图表生成而在于把数据链路打通。数据源的稳定性、缓存策略、异常兜底、部署时的进程管理这些环节每个都会直接决定页面能不能顺畅展示。ECharts 画图只是最后一步前面的数据工作才是大头。如果你也想动手做一个类似项目建议不要一开始就追求功能齐全先把“单个城市、7天温度、一个折线图”这条最小链路跑通再逐步加多城市对比、风况图和数据缓存。这样每加一个功能调试范围都是可控的不会出现满屏报错无从下手的焦虑。另外部署到云服务器后建议打开 Gunicorn 的访问日志观察接口响应时间和请求量。天气可视化这类项目数据感知性强用户一旦发现数据很久不更新就会不再使用而日志能帮你第一时间发现缓存失效或数据源限流的苗头。祝你也做出一个顺手好用的天气可视化小工具玩得开心。