最近整理了一个新的桌面小工具：PicDog。
项目地址：github.com/moxiaonai/picdog。如果你想看实现细节，可以从 README 里的产品说明、架构图和桌面端目录结构开始读。
它想解决的不是“怎么处理图片参数”，而是更具体的一件事：写博客、写文档、做官网素材时，图片在发布前应该先变小、再可控地上传，最后能直接拿到可用的 CDN 链接。
所以 PicDog 的工作流很克制：拖入图片或文件夹后，先在本机完成压缩；确认结果后，再勾选需要发布的图片手动上传；上传完成后，复制 URL、Markdown、HTML 或自定义格式链接。
为什么要把压缩和上传分开
很多图片工具会把导入、压缩、上传连成一条自动链路，省事，但也容易带来误传、错传和远端垃圾文件。
PicDog 刻意把这两步拆开：
- 压缩默认发生在本地，源图不会因为压缩流程自动离开设备。
- 上传需要手动触发，可以先检查体积、质量和文件选择。
- 只有上传成功并拿到 public URL 后，复制按钮才可用，避免复制到本地路径或失败链接。
这个设计更适合内容发布场景。比如写博客时，可以批量拖入截图，压缩后上传到 Cloudflare R2、OSS、COS、七牛、GitHub 仓库或本地目录，再直接复制 Markdown 链接粘进文章里。
技术上怎么拆
PicDog 用 Tauri v2 做桌面容器，前端是 React、TypeScript 和 Vite，负责主界面、批次状态、设置弹窗、历史记录这些交互；后端用 Rust 处理文件扫描、图片压缩、上传、SQLite 持久化和系统凭据。
敏感信息不会直接落进数据库。Access Key、Secret、Token 这类凭据会交给系统钥匙串保存，数据库里只记录 credentialRef。压缩和上传进度通过 Tauri 事件推回前端，让每张图片都有清楚的状态。
我希望它保持一个很小的产品重心：导入、压缩、选择、上传、复制。不堆满图像处理参数，也不把发布动作藏起来，而是把每天都会重复的图片发布链路做顺一点。