这个工具使用Rust开发，仅实现了上传文章功能，使用 GUI 桌面开发。 该工具使用的库为 nwg，即 native-windows-gui 库，该库支持老的 Windows GUI。 这应该算是一个半成品，这是 Rust 实现的一个桌面上传文章工具。它只有上传功能，之所以会这样，是因为后续的开发重心都放在go版本实现上。 不过这也有一定的价值，首先就是它实现了图形桌面，这个可以学会如何实现一个窗口，显示输入框和按钮，如何布局。然后呢，可以在Rust中使用HTTP上传文件，这也是一个非常棒的技能点。 以后有精力了，可以扩展完善一下。 项目地址 https://gitee.com/littletow/upart-rs
一、 项目愿景：让设备上云，像接线一样简单 新的一年，新的计划，我们致力于为工程师、创客及小团队，打造一套开箱即用、稳定可靠的工业物联网数据采集方案。你无需深究复杂的协议栈，只需聚焦业务，即可让传统设备轻松上云。 本项目的核心价值在于： 协议翻译官：打造一个高性能的“中间件”，将底层的Modbus协议（支持RS485/TTL）无缝转换为上层的MQTT协议，打通设备与云端的“最后一公里”。 软硬解耦：不绑定特定硬件。无论是WiFi环境（ESP32）还是4G环境（Cat.1模组），只要具备基本通信能力，软件就能赋予其“智能”，提供极大的硬件选型自由度。 解决技术断层：解决有业务需求但没有研发实力的小团队（如硬件工程师、创客、小厂），本项目提供了一种低成本解决方案。它只需通用开发板，就能实现数据采集和上云，花小钱办大事。 二、 技术架构：三位一体的全栈实现 为确保方案的极致稳定与高度可扩展，我们采用“固件 + 配置工具 + 演示端”的三位一体架构，确保方案的完整性与专业性。 核心固件（“翻译官” - 逻辑版） 固件架构：采用分层架构设计，硬件抽象层隔离具体芯片与通信接口（如RS485/TTL），实现核心逻辑与硬件的解耦；协议栈层实现完整的Modbus协议栈（主/从站，RTU/TCP），并进行高效、健壮的JSON封装；服务层内置MQTT客户端，负责可靠的数据上传、断线重连与本地缓存；配置管理层，通过Rust编写的PC工具下发设备配置，实现软件定义功能。 技术栈：采用C语言开发，优先实现裸机（No OS）逻辑版本，确保在资源受限的MCU上也能稳定运行，降低用户使用门槛。 功能：负责实时采集Modbus寄存器数据（如电压、电流），并根据配置的倍率进行数据转换，最后通过MQTT协议将数据打包上传。 PC配置工具（“指挥官” - Rust版） 技术栈：使用Rust语言开发，利用其内存安全特性，确保配置过程绝对可靠，工具长期运行不崩溃。 功能：提供图形化界面，用户可轻松配置通信模式、寄存器地址、倍率等参数。支持通过串口（USB转TTL） 进行固件刷新与参数下发，解决现场实施难题，无需复杂的网络配置。 数据演示端（“仪表盘”） 技术栈：微信小程序。 功能：扫码即可查看实时数据曲线与数值面板，直观验证数据上云效果，方便现场调试与演示。 三、 当前状态：诚邀你，成为“共创者” 项目正处于核心研发阶段，当前全力攻克裸机版本，实现通信方式支持WiFi和4G的Modbus RTU（串口）协议的稳定性与性能。它适合简单应用，保证运行稳定。我们相信，最好的产品源于真实场景的千锤百炼。 未来会研发通信方式支持LoRa、以太网的Modbus TCP，以及FreeRTOS多任务版，用于解决需要同时处理多路数据采集，复杂业务逻辑的高端场景。 因此，我们发起此次共创计划： 你的支持，将直接转化为测试硬件（ESP32、各类Modbus传感器），用于极限环境下的兼容性验证。 你的设备，可以寄来成为我们的“适配样本”，共同完善设备库。 你的反馈，将直接塑造产品的下一个版本。 四、未来承诺 当固件通过大量真实场景验证，达到工业级稳定标准后，我们将正式申请软著，并启动授权售卖。所有共创阶段的支持者，都将依据历史贡献，获得丰厚的升级折扣与永久优先支持权。 我入驻了爱发电，更多详情内容请查看：https://afdian.com/a/modujson
在沉浸于 Wails 3 开发 Mole 客户端的过程中，我不禁想起了我在 2023 年 11 月完成的一个小项目——mp-qrcode-gen。 虽然现在微信小程序后台已经集成了生成小程序码的功能，但在 2023 年，开发者想要快速、批量或者自定义参数生成小程序码，往往需要自己写脚本。于是，我用 Rust 编写了这款极致轻量的桌面工具。 一、 为什么在 2023 年做这个工具？ 当时，很多运营人员和开发者在准备线下物料（如海报）时，面临一个痛点： 接口调用门槛：微信官方提供的是 API 接口，非技术人员无法直接使用。 参数复杂：小程序码分为“受限”和“不受限”两种，参数限制各异，手动拼凑 URL 极易出错。 批量需求：线下场景往往需要针对不同页面、不同场景值生成大量图片，网页端操作效率低下。 为了解决这些问题，我选择了当时还算冷门的 Rust 语言进行开发，追求极致的性能与体积。 二、 技术选型：Rust + native-windows-gui 在那个时期，我并没有选择 Electron 这种庞然大物，而是选择了： Rust: 保证了极高的运行效率和内存安全。 native-windows-gui (NWG): 这是一个非常纯粹的 Windows 原生 GUI 库。它不包含浏览器内核，直接调用 Windows API，生成的 .exe 文件体积非常小。 三、 核心功能拆解 工具界面直观，配置完 AppID 和 AppSecret 后，主要提供两种模式： 1. 数量受限模式 (API A/B) 特点：支持输入完整的、带有超长 URL 参数的页面路径。 场景：适用于对码量要求不高（总计 10 万个以内），但需要精准携带复杂参数的场景。 2. 数量不受限模式 (API C) 特点：页面路径较短，但支持独立的 Scene（场景值）字段。 场景：这是线下物料最常用的模式，可以无限次生成，通过场景值来区分不同的线下投放点。 3. 本地化保存 点击生成后，工具会直接调用微信接口并处理返回的二进制流，将其保存为本地图片文件。无需打开浏览器，所见即所得。 ...
在自学 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 文件时。通过肉眼观察文件名来区分应用，是极其不可靠的。 ...