just f***ing send it

你肯定遇到过这种时刻。对方在微信上发来一个1.2G的视频文件，你等了十分钟，进度条卡在87%，然后弹出一行字：“文件过大，请使用其他方式传输。”你翻出百度网盘，上传花了半小时，生成链接后对方下载又得半小时，中间还弹出“下载速度慢，开通会员加速”。你气得想砸电脑。或者更常见的场景：你在办公室，同事在隔壁工位，你俩需要交换一个几百兆的设计稿。你试了AirDrop，但一个用Windows一个用Mac，不行。你试了钉钉，提示“文件超过100M”。你试了邮件，附件大小限制25M。最后你掏出U盘，插上，复制，拔下，走过去，插上，粘贴。整个过程耗时三分钟，但那种“我居然还在用U盘传文件”的荒谬感，能让你郁闷一整天。

just f***ing send it 就是冲着这个痛点来的。它的名字已经把态度说清楚了——别废话，直接发。你打开它的网页，不需要注册，不需要登录，不需要下载任何软件。页面上就两个按钮：一个“发送”，一个“接收”。发送方点“发送”，浏览器会生成一个六位数的房间码，同时打开一个文件选择窗口。你选好文件，不管多大——1G、10G、100G，理论上没有上限——然后系统会通过WebRTC技术在你的浏览器和接收方的浏览器之间建立一条直连通道。接收方在另一个浏览器里输入同样的房间码，文件就开始传输了。整个过程数据不经过任何服务器中转，你的文件直接从你的电脑飞到对方的电脑。传输速度取决于你们俩的网速，而不是某个云盘服务器的带宽。传完之后，房间码失效，通道关闭，不留痕迹。

用一个比喻来理解：这就像你在咖啡馆里，把一张照片从你的手机直接递给对面的人，而不是先拍下来发到朋友圈，再让对方去朋友圈下载。中间没有“朋友圈服务器”这个环节，照片只在你们俩之间流动。just f***ing send it 就是那个“递”的动作——它不存你的东西，不看你传了什么，只是帮你把数据从A点搬到B点。

和它最像的竞品是WeTransfer。WeTransfer也允许你传大文件，但它的路径是：你上传到WeTransfer的服务器，服务器生成一个下载链接，你把链接发给对方，对方从服务器下载。这个路径有两个问题。第一，上传和下载都要经过WeTransfer的服务器，服务器带宽有限，高峰期慢得像蜗牛。第二，文件在服务器上会保留一段时间（通常是7天），这意味着你的数据在别人的硬盘上躺了一周。just f***ing send it 选择了一条完全不同的路：不走服务器，直接P2P。这带来的能力差异很明显——传输速度只受限于你们俩的网速，而不是中间服务器的瓶颈；隐私性更好，因为文件从未离开过你们的设备；而且没有文件大小限制，因为服务器不需要存储任何东西。这个差异在什么场景下重要？当你传的是机密合同、未发布的视频、或者超大体积的3D模型时，你不想让任何第三方碰你的文件，哪怕只是暂存。

当然，它也有边界和代价。P2P传输依赖WebRTC，而WebRTC在某些网络环境下会被防火墙或NAT阻挡。比如在公司内网、酒店WiFi、或者某些严格限制P2P的校园网里，连接可能建立失败。这时候你就得退回到传统方式。另外，因为文件不经过服务器，所以发送方和接收方必须同时在线——你不能像WeTransfer那样先上传，等对方有空再下载。如果对方关机了，或者浏览器关了，传输就中断了。还有一个现实问题：WebRTC在传输超大文件时，如果网络不稳定，断点续传能力有限，可能得从头再来。所以它最适合的场景是：你和对方都在线，网络环境相对开放，文件一次性传完。

想象一下这个画面。你正在赶一个项目，需要把一段4K视频素材发给剪辑师。你打开just f***ing send it，点“发送”，选好文件，生成房间码。你拿起手机给剪辑师发微信：“房间码是4821，快开网页。”他打开浏览器输入房间码，进度条开始跑。你俩各自干自己的事，两分钟后，他发来一条消息：“收到了，清晰度完美。”你关掉网页，继续工作。整个过程没有注册、没有等待、没有“文件过大”的提示。这就是just f***ing send it想给你的日常。