“桌面版天气预报应用”这个名字听起来简单但真正动手做的时候你会发现它几乎能逼你把桌面开发、网络请求、数据解析、状态管理、异常处理、打包分发这条路完整走一遍。我最初想做个桌面天气应用纯粹是因为受够了手机天气推送的过度设计——我只想知道今天要不要带伞结果打开App全是资讯流和广告。桌面版的核心价值就一句话打开电脑就能看见天气不打扰、不啰嗦、常驻可见。这篇文章算是把整个项目从零到打包发布的完整过程做一个复盘包括技术选型、界面设计、API对接、踩坑记录和分发部署内容偏实战适合有一定Python基础、想做点真正能用的桌面小工具的读者。1. 为什么用PySide6而不是Electron技术选型的真实对比1.1 当我想做桌面天气应用时首先冒出来的方案大概半年前我产生了一个很朴素的需求我想在办公电脑的桌面上常驻一个天气窗口不用每天打开浏览器去搜索也不用掏出手机解锁看天气。最初我脑子的方案有三个用Electron套壳、用Python写Qt、或者用Tauri这种轻量方案。如果你去搜索引擎逛一圈你会发现关于“桌面天气应用”的教程大多集中在Electron和网页套壳上但仔细想想对一个天气应用来说Electron的方案明显过重了。Electron打包出来的基础体积动辄上百兆内存占用更是以几百MB起步做一个显示天气的小工具这性价比太低。我最开始也试着用Electron搭了一个雏形安装依赖、起本地开发服务、再通过BrowserWindow加载页面确实能做出来但当我打开系统任务管理器看到那个Node进程的物理内存占用之后我决定放弃这个方向。后来我试了Tauri它确实比Electron轻很多但Tauri要求Rust环境而且在Windows平台上的WebView2依赖是个不确定因素对于一个小工具来说折腾成本有点偏高。绕了一圈我回到了Python生态用PySide6即Qt for Python来写界面。PySide6是Qt官方支持的Python绑定用它写桌面应用有几个天然优势。首先是安装环境简单直接用pip install PySide6就能搞定不需要额外的运行时依赖。其次是界面表现力足够Qt自带的控件库和样式表可以做出相当精致的界面不会像很多人想象的那样“一眼望去全是上世纪风格”。最关键的一点是整个应用可以用纯Python写完不需要前后端分离、不需要打包Node_modules逻辑和UI都集中在同一个项目里维护起来非常轻松。1.2 各个方案的横向对比与选型结论为了把选择说得更清楚我这里用一张表对比一下几个主流方案的差异方便你在动手之前做一个判断。方案基础体积内存占用开发门槛界面可控性适合场景Electron150MB以上较高需要Node.js、HTML/CSS/JS基础高完全自由功能复杂、跨平台大型应用Tauri10MB左右较低需要Rust基础和系统WebView依赖高追求极致体积的轻量应用PySide6打包后约40-80MB较低需要Python基础、Qt基础中高Qt布局体系完善中小型工具、Desktop App快速开发原生WinForms/WPF小低需要Windows平台开发知识中仅Windows平台对我这个天气应用来说选PySide6的核心原因是“平衡”——体积不算大开发效率高后期如果我想把应用扩展成多标签的桌面助手Qt的框架也完全撑得住。PySide6还有一个非常实用的点是QML如果你熟悉前端思维可以尝试用QML写界面它跟QWidget相比更像是在写声明式UI动画和过渡效果也容易实现。不过考虑到大多数人更熟悉Python的面向对象写法我在这个项目的主界面上用的还是传统的QWidget QSSQt样式表方案理解起来直观排查布局问题也方便。提示如果你对JavaScript特别熟练天生反感Python那Electron完全可以做天气应用。但如果你想要的是“装了个小工具不想背个大包袱”的感觉PySide6会是更舒服的选择。1.3 项目结构的初步规划确定用PySide6之后我遵照“功能划分模块界面与数据分离”的原则把项目规划成了几个部分。天气数据的获取和解析放进services/目录界面代码放进ui/目录核心的运行入口放在根目录的main.py。这套结构看起来有点“过度设计”但我的真实感受是如果在项目一开始不把数据层和界面层分开后面一加API、一加缓存、一加定时刷新代码很容易变成一坨又一坨互相纠缠的面条。哪怕是像天气应用这样的小工具也值得在一开始就把代码组织明白。我列一下当时规划的目录结构weather-app/ ├── main.py # 程序入口负责创建QApplication启动主窗口 ├── config.py # 全局配置API Key、城市代码、刷新时间等 ├── ui/ │ ├── main_window.py # 主窗口类负责整体布局 │ ├── widgets.py # 自定义的天气卡片、状态标签等小组件 │ └── styles.qss # Qt样式表统一定制界面风格 ├── services/ │ ├── weather_api.py # 天气API的请求与解析逻辑 │ ├── location.py # 城市搜索、城市代码获取 │ └── cache.py # 本地缓存离线时使用 └── resources/ └── icons/ # 天气图标、应用图标等这样拆完整个项目的代码量虽不算大但逻辑边界很清楚界面只管展示服务只管取数和解析互不掺和。后面调试某个地方出问题时你几乎可以一眼定位到是UI的锅还是数据的锅。2. 天气数据从哪来开放API的选用与数据解析2.1 我为什么选择和风天气作为数据源桌面应用最核心的一块内容就是拿到可靠的天气数据。现在的天气数据提供方其实很多我前后对比了大概四五个服务和风天气、OpenWeatherMap、Open-Meteo、彩云天气等。OpenWeatherMap是很多英文教程的首选文档齐全标准版免费额度也够用但对中文城市的支持只能说“能用”部分城市名称的英文翻译和时区处理有点别扭。彩云天气的分钟级降水预报在南方城市很实用但它的免费额度比较紧API调用频率限制也很严格不太适合做一个需要频繁刷新的桌面应用。我在这个项目里最终选择了和风天气原因是它对国内的天气数据支持足够细尤其是“生活指数”这类信息穿衣指数、紫外线指数、洗车指数正好可以做进桌面应用里让用户不只是看到一个温度。和风天气的开发者平台会分配一个API Key免费版支持“实时天气”“逐小时预报”“每日预报”等常用接口个人开发完全够用。Open-Meteo则是一个完全免费、无需API Key的选择它的数据源来自官方气象部门覆盖全球适合作为备选数据源。我的建议是主数据源用和风天气备一个Open-Meteo用来做容灾防止某个接口临时抽风。2.2 城市代码的获取搜索接口与本地缓存用和风天气API时最容易让新手困惑的是发送天气请求时不是直接传城市名称而是要传一个“城市代码”LocationID。这个代码不是你一拍脑袋就能编出来的而是需要先调用城市搜索接口。比如我要拿“成都”的天气数据就需要先请求https://geoapi.qweather.com/v2/city/lookup?location成都key你的APIKey返回的JSON里会包含城市名称、经纬度、上级行政区划、LocationID等信息。这里有个很关键的细节搜索接口返回的往往不止一条结果因为“成都”作为关键词会命中很多相关地点。直接拿第一条结果是有风险的比如某些同名的县、市、区会被混淆。我当时的做法是把搜索结果展示在界面的下拉框里让用户自己点击确认要选哪个城市然后把选中的LocationID存到本地配置文件里下一次启动时就不需要再次搜索了。这就是为什么我在项目结构里专门建了一个location.py。它的逻辑并不复杂检查本地缓存文件里有没有对应城市名和LocationID的映射有就直接用没有就调用搜索接口解析出前五条候选让用户确认。这种“一次搜索长期使用”的策略能明显减少API调用量也避免每次打开应用都要等网络请求响应。2.3 JSON结构、时间戳和天气现象代码天气API的响应体结构虽然各家有差异但整体思路大同小异。以和风天气的实时天气接口为例核心数据在now字段下包括体感温度、相对湿度、风向风力、降水概率、能见度、气压等。这里要注意三点第一天气现象不是一串文字而是一个数字代码。比如100代表晴101代表多云300代表阵雨。这就需要你在程序里维护一张“天气码表”把这些代码映射成中文描述和对应的图标。我第一次对接时没有做映射结果界面上全是“104”“305”这样的数字看起来非常奇怪。第二时间字段的处理。和风的接口返回的时间字段是带时区的字符串比如2025-06-15T10:0008:00。如果你直接用字符串截取后面做日期的星期几计算时容易出错。我建议你在解析阶段就统一用datetime.fromisoformat()转成Python的datetime对象后续要显示“今天/明天/周几”就非常方便。第三单位问题。和风天气默认使用公制单位温度是摄氏度风速是公里/小时。但有些国际API默认返回英制单位所以如果你同时接多数据源一定在请求参数里显式指定单位。比如和风天气在请求URL里加入unitm代表公制OpenWeatherMap则在参数里用unitsmetric。单位不一致是天气应用最隐蔽的坑后面我会详细说。以下是一个简化版的天气数据解析函数展示了怎么从API响应中提取关键字段from datetime import datetime def parse_current_weather(data: dict) - dict: now data.get(now, {}) obs_time datetime.fromisoformat(now.get(obsTime)) return { obs_time: obs_time, temperature: int(now.get(temp, 0)), feels_like: int(now.get(feelsLike, 0)), humidity: int(now.get(humidity, 0)), weather_code: now.get(icon, 999), weather_text: WEATHER_CODE_MAP.get(now.get(icon, 999), 未知), wind_dir: now.get(windDir, ), wind_scale: now.get(windScale, ), pressure: int(now.get(pressure, 0)), visibility: int(now.get(vis, 0)), }2.4 多数据源容灾主备切换策略写到这里我想强调一个容易被忽略的点桌面应用不能假设网络永远通畅也不能假设第三方API永不故障。我在第一版里只接了和风天气结果某天下午接口突然返回401Key无效或账户异常整个应用的天气区域直接空白。从那时起我硬性规定所有外部API调用都必须有备选方案。我当时的实现方式是先尝试请求和风天气如果超时或者返回错误码就自动切换到Open-Meteo。Open-Meteo不需要Key请求参数是经纬度坐标所以在获取了城市LocationID之后我还需要把经纬度也存储下来。虽然这是“双保险”的做法但实际上同一个城市在两家数据源之间的温度也许有细微差异界面会标注“数据来源”这样用户看到温度有变化也不会困惑。这里的核心经验是拿到数据的稳定性比数据本身的精准度更重要。一个偶尔偏差半度的天气预报用户能接受一个动不动就加载失败的天气应用用户会直接卸载。3. 界面搭建从占位草图到精致卡片的完整流程3.1 主窗口的布局结构设计桌面应用的界面设计我把它理解为三个层次整体布局、组件设计、细节美化。天气应用的主窗口通常不需要太复杂的交互我的布局方案是最顶部是一个搜索框和刷新按钮下面是一个“当前天气大卡片”再往下是未来几天7天的横向滚动预报卡片最底部放一个极简的状态栏显示“最近更新于xx:xx”和错误信息。这个布局符合“从上到下、从概要到细节”的视觉习惯用户一眼就能获取最关键的信息。在Qt中实现这种布局最简单的方案是外层用QVBoxLayout内层再嵌套QHBoxLayout。当前天气大卡片我是用一个自定义的QFrame加样式表实现的上面显示城市名称、当前温度、天气现象对应的图标和文字描述下面用两个横向小组件展示湿度和风力。未来7天预报的部分我用QScrollArea横向滚动里面放7个DailyCard小卡片。每个小卡片显示星期几、白天气温、夜间气温和天气图标。这里有一个经验教训编写Qt布局时千万不要把每个控件的minimumHeight和maximumHeight定死。因为不同系统的DPI缩放策略不一样在Windows上可能一切正常到了macOS上字体渲染一变界面就变形了。正确的做法是让布局系统自动计算控件尺寸你只要设置合理的sizePolicy和间距即可。3.2 用QSS样式的美学实践很多从网页前端转过来的人初次遇到Qt样式表QSS时会产生一种错觉这就是CSS。确实QSS的语法和CSS非常相似支持的属性也覆盖了背景色、边框、圆角、字体等常用项但它跟CSS有两个关键区别一是选择器能力弱不少二是不支持flex、grid这种现代布局。因此用它做出来的界面风格更加“传统桌面应用”一些但这不代表不能做得精致。我当时的做法是用QSS统一管理所有颜色和圆角把主色调设为偏蓝的冷色调让整个界面看起来有“天气”的感觉。温度用大号字体居中突出显示天气图标用60x60的尺寸底下用淡淡的渐变背景区分当前天气和逐日预报。QSS里支持qlineargradient你可以很方便地做一个从浅蓝到深蓝的渐变背景效果比纯色好很多。写QSS时有一个我见过非常多新手踩坑的点当你给QFrame设置border-radius后发现背景色没有变成圆角反而出现了“四个白角”。这个问题的根源在于QSS的圆角裁剪只对控件的“背景”生效如果你同时设置了边框而边框宽度不是0那么圆角边缘会渲染出一些异常。解决办法很简单在设置圆角时同时设置border: none或者调整border-radius为min(width, height) / 2。3.3 定时刷新和状态管理天气应用是一个“需要自动更新”的桌面工具但你绝不能让它每秒钟都去请求API否则不仅浪费流量还可能触发提供方的频率限制。我的做法是使用QTimer将自动刷新间隔设置为30分钟。用户也可以点击刷新按钮强制刷新但在点击后我会加一个3秒的冷却时间防止用户在几秒内连续点击导致无限请求。状态管理是这个项目里最容易搞乱的部分。天气应用的状态至少包括以下几种正在加载、加载成功、加载失败、离线状态、城市切换中。我定义了一个简单的枚举来表示这些状态并在状态变化时更新界面上的占位控件和状态栏文字。比如当加载失败时不直接清空界面上的旧数据而是保留上次成功获取的数据在状态栏显示“更新失败展示缓存数据”当无网络时读取本地缓存文件中的天气数据并且在界面顶部用一个浅黄色横幅提示“当前处于离线模式数据非实时”。下面是我实现的一个简化版本演示了如何通过状态来控制UI的更新from enum import Enum from PySide6.QtCore import QTimer, Signal, QObject class WeatherState(Enum): LOADING loading OK ok FAILED failed OFFLINE offline class WeatherController(QObject): state_changed Signal(str) def __init__(self): super().__init__() self.timer QTimer(self) self.timer.setInterval(30 * 60 * 1000) # 30分钟 self.timer.timeout.connect(self.refresh) def refresh(self): self.state_changed.emit(WeatherState.LOADING.value) try: data weather_api.fetch_current_weather() cache.save(data) self.state_changed.emit(WeatherState.OK.value) except NetworkError: cached cache.load() if cached: self.ui.update_weather(cached) self.state_changed.emit(WeatherState.OFFLINE.value) else: self.state_changed.emit(WeatherState.FAILED.value)3.4 系统托盘把天气应用变成“常驻后台”的一部分比“常驻桌面上”更高效的是“常驻系统托盘”。我第一版的时候天气窗口就老老实实地待在桌面上后来发现时间一长就不想看到它占着屏幕空间。于是我就加了系统托盘功能右键系统托盘图标可以显示当前温度左键单击托盘图标可以唤起或者隐藏主窗口如果用户关闭主窗口默认不是退出程序而是最小化到托盘。这个交互逻辑几乎是所有桌面小工具的标配了Qt里实现起来也很简单主要通过QSystemTrayIcon类。你只需要在创建托盘图标时设置一个ContextMenu把“显示主窗口”“切换城市”“退出”这几个动作加进去。系统托盘还有个容易被忽略的细节托盘图标的tooltip。我把当前城市、温度和天气现象拼成一个字符串设成tooltip这样用户鼠标悬停时就能看到天气信息都不需要打开主窗口。这个看似简单的设计实际上让“查看天气”的操作成本降到了零。4. 项目实战中踩过的坑从数据错位到打包失败的完整记录4.1 城市搜索接口返回多条结果取错第一条的坑这个坑发生在我开发第一版的时候。当时我写了一个很“天真”的逻辑用户输入城市名我调用搜索接口直接取返回列表的第一条然后就把天气显示出来。结果测试时输入某个中等城市名称界面显示的却是几百公里外另一个同名乡镇的天气温度差了好几度。排查过程很让人抓狂因为我一度认为是API Key有问题或者网络请求参数写错了。后面我用Postman手动请求搜索接口拉出返回的JSON才发现搜索接口会返回一长串候选地点包括同名行政区、区县、乡镇。第一次的记录可能是“城市”第二次可能是“区县”顺序完全不可控。修复方案就是前面说的把搜索结果做成一个下拉列表让用户确认。虽然多了一步交互但这才是正确的产品逻辑——程序不能替用户做那种容易出错的选择。另外我还把用户最终选择的LocationID和经纬度写进了一个config.json。下次启动直接读配置不再调用搜索接口。这样既是数据容错也是接口调用节流。4.2 单位制不一致华氏度与摄氏度的迷之混乱有一次我在测试备用数据源Open-Meteo时发现界面显示的温度数值突然变成了正常值的1.8倍再加上32这不是开玩笑这是典型的华氏度没换算回摄氏度。Open-Meteo默认返回的数据单位比较多虽然它的文档里表示API默认使用公制但在请求参数里temperature_unit这个字段的默认值其实是celsius而我当时忘了显式声明又在切换数据源时用了一套自己的解析逻辑结果就踩坑了。排查这个问题的思路说起来也简单我当时在界面上显示“今天气温 86°”而天气现象却显示“晴”我感觉这个数值明显不对后来拿这个数值套了一下换算公式发现86°F恰好等于30°C一下子就明白了。修复方式就是请求Open-Meteo时显式携带temperature_unitcelsius和windspeed_unitkmh参数同时在解析函数里加一个断言如果温度范围超出-50到60摄氏度就抛一个异常提醒开发者检查单位配置。这个断言虽然简单但在多数据源切换的场景里非常有用。4.3 高分屏缩放模糊Windows DPI下的字体渲染问题这个坑在Windows系统上尤其明显。我最初在Windows 10的150%缩放比例下开发界面看起来正常但拿到一台100%缩放的电脑上界面却显得特别小再拿到一台125%缩放的笔记本上又发现有些文字被截断了。Qt6本身支持高DPI缩放默认情况下会在启动时自动感知系统的缩放比例但它有一个前提你的程序必须设置在main.py一开始就启用缩放感知并且尽量使用布局和控件自身的sizeHint机制而不是把所有控件尺寸用像素写死。我当时的解决办法主要有两条第一在程序入口处添加以下代码from PySide6.QtCore import Qt, QCoreApplication QCoreApplication.setAttribute(Qt.AA_EnableHighDpiScaling) QCoreApplication.setAttribute(Qt.AA_UseHighDpiPixmaps) app QApplication(sys.argv)第二放弃在QSS里用固定像素的字体大小改为使用点大小pt。像素大小在不同DPI下物理尺寸不同而点大小会随着系统缩放自动调整这对跨DPI场景更加友好。比如你在QSS里写font-size: 14pt比font-size: 18px看起来更安全。4.4 打包后图标丢失和文件路径异常的坑开发阶段一切正常但用PyInstaller打包成exe之后程序跑起来却找不到图标文件报错信息提示找不到某个路径。这个问题几乎每个用PyInstaller打包Qt应用的人都会遇到。原因很简单PyInstaller打包时Python的当前工作目录cwd不一定是exe所在的目录如果你用相对路径去读资源文件很容易失败。正确的做法是在代码里动态判断自己是在源码环境还是在打包后的环境中运行然后拼接出正确的资源路径。最经典的做法是使用sys._MEIPASS这个PyInstaller注入的临时解压目录。我的代码里会有类似这样的逻辑import sys from pathlib import Path def resource_path(relative_path: str) - Path: base_path getattr(sys, _MEIPASS, Path(__file__).resolve().parent) return Path(base_path) / relative_path同时在用PyInstaller打包时我需要通过--add-data参数把resources目录完整加入打进去否则图标文件不会进入最终的exe包。如果你是在命令行下执行打包命令可以这样写pyinstaller --windowed --onefile --nameWeatherApp \ --add-data resources;resources \ --iconresources/app.ico \ main.py注意--add-data在不同平台上的路径分隔符不一样Windows用分号Linux和macOS用冒号。这个细节如果你没注意打包出的程序在换平台之后会犯迷糊。4.5 网络请求阻塞UI界面卡死的排查过程还有一个让我印象极深的坑第一次用requests.get()在界面主线程里直接请求天气API时只要网络稍有波动整个窗口就会卡住按钮点了没反应还显示“程序无响应”。排查过程其实不算复杂因为我知道Qt的UI事件循环和网络请求天然是矛盾的——你在主线程里执行耗时的同步操作Qt的事件循环就被卡住了所有用户交互自然全部阻塞。解决方案是用Qt的QThread把网络请求放到后台线程运行。很多教程会推荐直接用threading.Thread但在Qt世界里更优雅的方案是使用QThreadPool QRunnable或者使用QThread里暴露的started信号和finished信号来管理生命周期。我最后采用的是QThreadPool方案因为它不需要手动管理线程生命周期而且可以方便地限制并发数。请求完成之后通过信号把数据传回主线程再触发UI更新。这里有一个关键的准则在Qt中一切UI操作必须在主线程完成子线程只负责数据获取和解析取完数据之后通过信号投递回主线程。我在这上面栽过跟头为了图省事直接在子线程里调用label.setText()结果Qt直接抛出一个“Cannot create children for a parent that is in a different thread”的异常。绕过这个坑的唯一正确方式就是严格遵守“信号-槽”的线程边界。5. 打包发布与后续扩展从本地运行到真正能拿来用5.1 PyInstaller打包的完整步骤与体积优化当你终于把天气应用跑顺了下一步就是要把它发给朋友或者部署到自己的另一台电脑上。我选择了PyInstaller来打包原因是资料多、对Qt支持成熟。打包的命令前面已经展示过了这里我再补充两个细节第一如果你使用了QSS文件或图片资源--add-data必须带上第二如果你使用了QtWebEngine之类的大型模块需要额外关心其依赖的插件目录。打包完成后一个很直接的困惑是为什么一个天气应用打包出来竟然有80MB这个体积主要来自Qt运行库。PyInstaller默认会把用到的动态链接库全部拷贝进dist目录而Qt本身就带着一堆dll和platform插件。如果你觉得体积不可接受可以考虑使用UPX压缩可执行文件但要注意压缩后的程序可能被杀毒软件误报另一个思路是不使用--onefile改用--onedir模式虽然会生成一个文件目录但启动速度更快配合压缩工具也能明显减小体积。对于分发场景onedir方式其实更推荐——onefile虽然只有一个exe但每次启动都要自解压到临时目录启动速度明显偏慢而且清理临时文件时还容易出问题。5.2 离线缓存与增量更新让应用更耐用的两个设计在把应用交给真实用户之前我强烈建议你做好离线缓存。桌面应用和手机App不太一样很多用户的电脑可能同时连接着不稳定的网络环境。我的做法是把最近一次成功的天气数据、时间戳和城市信息保存为~/.weather_app_cache.json。每次启动时先展示缓存数据再在后台发起网络请求拿到新数据后自动刷新界面。这样即便没有网络用户也能看到一个不算过时的天气数据只是需要给他一个明显的“离线”标识。增量更新则是指刷新天气数据时不是傻傻地重新请求所有接口而是根据接口的能力只请求必要的数据。比如和风天气的逐小时预报接口会返回未来24小时的数据如果我只是想在界面上显示当前温度和未来3天我只需要调用每日预报接口即可。这样既节省API配额也加快刷新速度。这个判断听起来很自然但真到写代码时人很容易陷入“把所有接口数据都拉回来再说”的思维惯性。5.3 扩展方向从天气应用升级成桌面助手这个项目完全可以当作一个基础脚手架的练手项目。我做完天气应用之后顺手给它加了几个扩展功能这里一并分享给你。第一个扩展是“天气变化提醒”。原理非常简单后台定时器每隔30分钟拉一次数据计算当前时间到下一次降水之间的间隔如果发现未来两小时内有降雨概率超过50%就通过系统托盘弹出一条通知。Qt里发通知可以用QSystemTrayIcon.showMessage()这个方法在Windows和macOS上都能调用系统原生通知体验很好。第二个扩展是“穿衣建议”。你可以利用和风天气生活指数接口返回的穿衣指数和紫外线指数用简单的规则引擎生成一句建议比如“温度较低建议穿厚外套”或“紫外线较强出门注意防晒”。虽然这看起来只是一句文本但用户会觉得很贴心。第三个扩展是“多城市管理”。通过在界面上加一个城市Tab栏让用户同时关注几个城市的天气比如自己所在的城市和老家所在的城市。实现的难点只在于城市列表的存储和切换逻辑界面层面并不复杂。我还计划过把天气应用做成透明背景的桌面小组件悬浮在桌面角落就像Windows的小组件一样不占据任务栏空间但这需要更精细的窗口透明和鼠标穿透处理算是下一步的进阶课题了。5.4 关于这个项目我最后的真实感受这个桌面天气应用从动手到主力功能完成其实只花了一个周末的时间但后面维护和打磨细节的时间远远超过写第一版的时间。写这种小工具最有趣的地方在于你每次遇到一个坑并解决它就能体会到一次从“烦恼”到“豁然开朗”的过程。就拿数据单位来说如果你不去接第二数据源你可能永远都不会意识到单位不一致是多隐蔽的坑。说白了桌面天气应用是一个“麻雀虽小五脏俱全”的项目网络、界面、线程、缓存、打包、分发全都要涉及。把它做好你收获的不只是一个能看天气的小工具而是一整套桌面应用开发的实战经验。哪怕你以后不再写天气应用这套经验放到任何桌面工具项目里都是通用的。如果你也想做一个类似的项目我的建议是先别纠结选Qt还是Electron先选一个你最有把握的技术栈把“能显示当前天气”这一条核心路径走通然后把上面的坑一一踩过再慢慢加上自己想要的功能。比如我就是先把“当前温度”跑通再逐步加了逐日预报、托盘、缓存和打包。这样循序渐进每实现一个功能都有正反馈不会在一开始就被复杂的架构劝退。最后再说一句最实战的体会接口永远可能挂网络永远可能断用户永远可能乱点你在写代码时把这些“反常情况”都当正常逻辑处理这个应用才算真正能用。