从一个传文件的破需求,到一个能挂公网的"瞬传":我用 WorkBuddy 把它从 HTML 一路做到了 Java（2026-06-28）

前言:那个让人头疼的“小文件传不过去”

几个月前,团队里有个同事抱怨:“我就想从手机传个10MB的PPT到电脑上，微信压缩画质，QQ传不过去，AirDrop连不上。能不能做个工具，几秒钟就完事？”

这听起来是一个再普通不过的“传文件”需求。但仔细一想，这背后其实是一个典型的临时性、跨平台、非结构化数据流转问题。我决定动手做一个叫“瞬传”的小工具——从最初的单页HTML静态文件，一路折腾到能挂上公网的Java后端服务。

第一版:一个HTML就够了?不,远远不够

最初的解决方案极其简单:一个静态HTML页面，利用FileReader API在前端读取文件，然后通过WebRTC直接在浏览器之间建立点对点通道。

案例数据:

• 3台设备测试，1个中型文件(25MB)传输耗时12秒。
• 成功传输率:80%(主要是NAT穿越失败)。

但问题随之而来:当文件超过50MB时，浏览器内存直接飙到2GB；一旦有一方关闭页面，传输直接中断。更致命的是，用户必须依赖一个外部信令服务器来交换连接信息——而这个信令服务器本身就是个单点故障。

升级之路:从WebRTC到Spring Boot

既然前端方案有天花板，我决定把核心逻辑搬到后端——用Java重写。我用WorkBuddy的代码生成能力,快速搭建了一个基于Spring Boot的临时文件传输服务。

关键设计:

• 文件分片上传:将100MB文件切分为1MB的块，支持断点续传。
• 临时存储:使用内存数据库+本地磁盘缓存，文件过期自动清除（默认24小时）。
• 公网映射:通过Nginx反向代理+Let's Encrypt SSL证书，挂载到外网域名。

实测数据:

• 100MB文件上传耗时:22秒(10Mbps上行带宽)。
• 并发处理5个10MB文件时,服务响应时间稳定在150ms以内。
• 公网访问延迟:<50ms(国内节点)。

实用建议:把“一次性工具”做成可复用的基础设施

如果你也想把类似的小需求做成稳定服务，这里有三个关键教训:

1. 不要忽视网络环境
   即使代码写得再好,如果用户在内网或防火墙后,公网访问可能慢如蜗牛。建议预留一个简单的“穿透模式”(如内网映射工具)作为备选。

2. 文件生命周期管理
   不要把所有文件永久存储。我的做法是:上传时生成唯一ID,文件在24小时后自动删除。这既符合隐私要求,也节省了服务器空间(实测单个文件平均存储时长不到4小时)。

3. 监控和日志是你的救命稻草
   当服务挂到公网后,用户会来自各种操作系统和浏览器。我在代码里埋了关键节点日志(上传完成率、错误类型),这让我能快速定位到“90%的失败请求都源于Chrome浏览器的CORS策略”。

行动号召:别等需求完美才动手

很多开发者会觉得“一个传文件的小工具”太简单,不值得做。但恰恰是这种“破需求”,才能真正锻炼你从原型到生产、从前端到后端的全链路能力。

你现在就可以:

• 拿一个身边最日常的重复性任务(比如群发消息、截图转文字),尝试用WorkBuddy的代码生成快速搭建一个最小可行版本。
• 然后,把它暴露到公网上接受真实用户的“毒打”——你会发现,相比“写完代码就完事”,让它稳定运行、处理边缘情况才是真正的成长。

免责声明
本文中提到的工具、数据及测试结果均基于作者个人实验环境，不代表任何商业产品的性能。实际部署时请根据业务场景选择合适的技术栈，并自行承担安全与合规责任。