深度复盘Rust上传工具崩溃问题,优化报错提示

最近,更新了上传文章工具 rust 版本,这个版本使用的库为 nwg,即 native-windows-gui 库,该库支持老的 Windows GUI。 昨天,当我准备在另一台电脑上录制视频时,发现运行不起来,GUI 界面闪现一下,就退出了。以为版本太老,我先升级了 Rust 版本到最新版本(😭,不应该的原因,固定版本反而更可靠稳定一些)。 rustup update 升级完成后,cargo clean ,再 cargo run 重新运行。 郁闷,还是报错。 将 main.rs 文件中该行注释,#![windows_subsystem = "windows"],可以在命令行中查看报错信息,提示是找不到文件。我想了下,只有图片是文件,然后我将图片的路径修改,发现修改之后,编辑器还提示错误,找不到文件。重新改回去后,编辑器提示错误消失。说明不是这里的错误。 我真的晕了。从网上查找问题原因,没有找到此类问题的解决方法,郁闷。在查找时,发现了另一个 Windows 官方支持的 rust 库,就叫 windows,打算有时间了用这个库重写一下。 今天,我又查看了下另一台电脑上的这个项目,发现可以正常运行,将 rust 升级到最新版本后,还是可以运行。在看到配置文件后,我才恍然大悟,原来是查找的是这个配置文件。我赶紧扒拉代码确认,发现确实是这个问题。 let conf = Ini::load_from_file("conf.ini").unwrap(); 上面是使用文件的地方,找不到文件 panic。我这里优化了一下,让错误提醒的更明显一些。这样我就瞬间能知道问题原因了。 优化后的代码如下: let conf = Ini::load_from_file("conf.ini").expect("please config conf.ini file"); 有些问题其实很简单,但由于时间长了,还是会一头懵,如果报错信息提示完善一点,会很快定位到问题。

2025-01-01 · 1 min · Eagle

使用Rust基于 Native-Windows-GUI 构建的轻量小程序码生成工具

在沉浸于 Wails 3 开发 Mole 客户端的过程中,我不禁想起了我在 2023 年 11 月完成的一个小项目——mp-qrcode-gen。 虽然现在微信小程序后台已经集成了生成小程序码的功能,但在 2023 年,开发者想要快速、批量或者自定义参数生成小程序码,往往需要自己写脚本。于是,我用 Rust 编写了这款极致轻量的桌面工具。 为什么在 2023 年做这个工具? 当时,自己需要根据页面去生成一些小程序码,线下张贴使用。每次使用服务端修改代码感觉非常不便利。于是做了一个这样的生成小程序码的工具。 当完成后,我还发了视频号进行了推广,发现很多人还下载使用了。其实运营人员和开发者在准备线下物料(如海报)时,通常会面临一个痛点: 接口调用门槛:微信官方提供的是 API 接口,非技术人员无法直接使用。 参数复杂:小程序码分为“受限”和“不受限”两种,参数限制各异,手动拼凑 URL 极易出错。 批量需求:线下场景往往需要针对不同页面、不同场景值生成大量图片,网页端操作效率低下。 技术选型:Rust + native-windows-gui 在那个时期,我并没有选择 Electron 这种庞然大物,而是选择了Rust,保证了极高的运行效率和内存安全。和native-windows-gui (NWG),这是一个非常纯粹的 Windows 原生 GUI 库。它不包含浏览器内核,直接调用 Windows API,生成的 .exe 文件体积非常小。选择Rust还有一个原因就是我在学习它,需要一个项目练手。 核心功能拆解 做的工具界面非常简单直观,配置完 AppID 和 AppSecret 后,就可以使用它生成小程序码了。点击生成按钮后,工具会直接调用微信接口并处理返回的二进制流,将其保存为本地图片文件。无需打开浏览器,所见即所得。 根据微信官方的接口,我实现了两种模式,分别为受限模式和不受限模式。 1. 数量受限模式 (API A/B) 特点:支持输入完整的、带有超长 URL 参数的页面路径。 场景:适用于对码量要求不高(总计 10 万个以内),但需要精准携带复杂参数的场景。 2. 数量不受限模式 (API C) 特点:页面路径较短,但支持独立的 Scene(场景值)字段。 场景:这是线下物料最常用的模式,可以无限次生成,通过场景值来区分不同的线下投放点。 开源和思考 虽然几个月后,微信官方后台也逐步完善了类似的功能,但 mp-qrcode-gen 的意义在于:在需求未被完全满足的真空期,个人开发者可以用技术手段快速提供解决方案。 ...

2021-11-02 · 1 min · Eagle

构建高可靠 APK 上传工具,彻底终结网络超时与手误引发的生产事故

在自学 Rust 的那段日子里,我除了开发开源项目,还为日常工作量身定制了一些不公开的内部工具。其中最令我印象深刻的,是一个看似简单的 APK 文件上传小工具。 虽然它只是一个 Rust + native-windows-gui (NWG) 编写的单一界面应用,但它解决的两个核心生产问题,至今仍对我有着深远的影响。 工具画像:极简与高效 这个工具的界面极其克制: 交互区:一个醒目的文件拖拽控件,文案提示“请把 APK 文件拖拽到这里”。 表单区:版本号、Version Code、更新描述、是否强制升级(开关)。 执行区:一个大大的“上传”按钮。 它的核心逻辑非常纯粹:校验必填项 -> 调用内部上传 API -> 上传文件 -> 返回成功或失败的对话框。 故事一:消失的 60 秒与隐藏的超时限制 工具上线初期,一切运行平稳。由于办公室带宽充足,APK 的上传时间通常维持在 40 秒左右。 事故发生: APK 在集成广告后,经常会发生失败的情况,客户端弹出“超时”的报错。 排查过程: 我首先检查了后端服务,发现后端接口完全没有超时限制,服务器日志显示连接是被客户端主动断开的。 多次重复上传文件使用有线和无线对比,经排查是文件变大,由于公司无线网络波动,上传速度时好时坏,就会偶尔出现失败的情况。对比排查,发现失败的情况上传时间都超过了 60 秒。 回到 Rust 代码中,我发现当时为了追求简洁,直接使用了 HTTP 客户端的默认配置。而这个默认配置的 Timeout 为 60 秒。 解决方案: 在那个瞬间我意识到,工具不能只考虑“理想状态”。我手动将本地超时时间放宽至 5 分钟,并增加了状态提示。上传时不会再出现超时的情况了。 教训:永远不要依赖默认的超时设置,尤其是在处理文件上传这类长耗时操作时,本地的容错范围必须根据业务场景精细化配置。 故事二:包名校验——把人为失误挡在门外 这是这个工具最有价值的一次功能进化。 事故发生: 有一次,同事不小心将应用 A 的打包产物当作应用 B 上传到了官网,导致用户下载后发现软件张冠李戴。这属于严重的生产事故。 排查过程: 这个客户端软件调用内部API后,会自动将上传的文件名修改为固定的软件下载文件名,显示在网站上。经测试,如果将应用A的打包产物使用应用B上传,在官网就会出现相同的情况。解决这个方法也非常简单,就是上传的时候小心细致一点,应用A使用A客户端软件,应用B使用B客户端软件。但是人总会犯错,尤其是在面对多个长相相似的 .apk 文件时。通过肉眼观察文件名来区分应用,是极其不可靠的。 解决方案: 所以,我在想是否有能够唯一识别软件而不依赖文件名呢?经沟通可以确定包名是唯一的,所以可以通过包名比对限制上传错误的情况。要获取包名,必须解析APK文件中的XML。所以我在工具中引入了 APK 自动解析功能: ...

2020-01-02 · 1 min · Eagle