作為一個(gè)天天連服務(wù)器的人,我的痛點(diǎn)很具體:跨機(jī)器搬運(yùn)小數(shù)據(jù),成本高得離譜。

我連生產(chǎn)/測(cè)試機(jī)大多走向日葵或者遠(yuǎn)程桌面。干活沒問題,搬東西是真折磨。本地一個(gè)改好的配置、一段現(xiàn)場(chǎng)報(bào)錯(cuò)日志、一個(gè)臨時(shí)打的 jar,要送到那臺(tái)機(jī)器上——微信文件助手得兩頭各登一次;走網(wǎng)盤得先傳再下,還留記錄;rz/sz 在弱網(wǎng)下能卡你到懷疑人生。文字比文件更糟:遠(yuǎn)程桌面里的剪貼板時(shí)靈時(shí)不靈,一段 nginx 配置、一串臨時(shí) token,經(jīng)常只能對(duì)著屏幕一個(gè)字一個(gè)字手敲。

我要的東西其實(shí)極簡(jiǎn):一個(gè)網(wǎng)頁(yè),丟進(jìn)去,對(duì)面輸個(gè)碼就拿到,用完自動(dòng)銷毀,全程不注冊(cè)、不登錄、不留歷史。市面上的工具要么太重、要么強(qiáng)制登錄、要么把你每一次傳輸都記下來。沒有一個(gè)戳中我。

那就自己寫。后端 Java 我沒問題,前端是真不想碰——正好讓 WorkBuddy 陪我從頭走一遍,看看它到底能幫到哪一步。

第一步:選對(duì)賽道

進(jìn) WorkBuddy 首頁(yè),頂部擺著幾條主線:日常辦公、代碼開發(fā)、設(shè)計(jì)創(chuàng)意。我要寫工程,直接點(diǎn)代碼開發(fā)。

它沒急著寫代碼,先幫我把需求"解構(gòu)"了

我沒整需求文檔,就把上面那段抱怨原樣甩進(jìn)去。它最讓我意外的是:沒有立刻進(jìn)入寫代碼的興奮狀態(tài),而是先把我的痛點(diǎn)抽象成了一句話——“遠(yuǎn)程環(huán)境下文件與文本的臨時(shí)互傳”,然后直接給了我三條技術(shù)路線,還配了一張優(yōu)缺點(diǎn)對(duì)照表:

• 方案 A · 純 Web 文件中轉(zhuǎn):文件落服務(wù)器,瀏覽器直傳直取。零配置、開箱即用,代價(jià)是文件要在服務(wù)器落地。
• 方案 B · 實(shí)時(shí)剪貼板同步(WebSocket):雙端實(shí)時(shí),像一個(gè)在線剪貼板。文字體驗(yàn)極好,但只解決文字。
• 方案 C · 綜合雙通道:文字 + 文件兩條通道都要,前兩者的優(yōu)點(diǎn)合并。

它自己傾向 C,并說明了理由。

這一步的體驗(yàn)已經(jīng)贏了一半。我喂的是一句模糊抱怨,它回的是一個(gè)有取舍的技術(shù)選型——這才是一個(gè)工程師想要的對(duì)話方式,而不是上來就甩兩百行能跑但跑偏的代碼。

圍繞"安全"反復(fù)對(duì)線

我沒拍板,先拋了我最在意的約束:這玩意要掛公網(wǎng)給陌生人用,不能裸奔。它順著這條線把安全模型拆成"用戶側(cè)"和"服務(wù)端側(cè)"兩塊,顆粒度細(xì)到能直接抄進(jìn)設(shè)計(jì)文檔:

用戶/訪問側(cè)——身份認(rèn)證用一次性訪問碼(口令),不建注冊(cè)體系,每次訪問臨時(shí)生成、進(jìn)獨(dú)立空間;分享走帶 token 的邀請(qǐng)鏈接,鏈接自帶有效期、過期即失效。上傳側(cè)——強(qiáng)制 HTTPS,危險(xiǎn)后綴(exe/sh/php)走黑名單攔截,限單文件大小、限單用戶總份數(shù)。下載側(cè)——下載鏈接帶有效期、不可被猜測(cè)的 URL,支持閱后即焚(下完一次即刪)。

服務(wù)端側(cè)——文件按用戶隔離存儲(chǔ),互相不可見;文字內(nèi)容加密落盤(類 AES,服務(wù)端只存密文);統(tǒng)一 TTL 自動(dòng)清理;同 IP 限頻防刷;審計(jì)日志只記時(shí)間與元信息、不記內(nèi)容。

它對(duì)安全的敏感度是超出我預(yù)期的。 我只說了"別裸奔"三個(gè)字,它把密鑰模型、隔離存儲(chǔ)、限頻、審計(jì)邊界一次性鋪開了。這些點(diǎn)后面幾乎原封不動(dòng)落進(jìn)了最終實(shí)現(xiàn)。

把功能與流程釘死,順手砍掉一半需求

安全聊透,接著定功能。我把發(fā)送方、接收方的流程口述了一遍,它順手畫了張端到端的狀態(tài)流轉(zhuǎn):

發(fā)送方頁(yè)面 → 上傳文件/文字 → 生成唯一口令(URL)→ 設(shè)置有效期 / 下載次數(shù) / 口令 → 接收方頁(yè)面憑鏈接查看、下載。

然后它把多人房間單獨(dú)拆成一個(gè)模塊:臨時(shí)空間走 WebSocket,多人輸同一口令進(jìn)同一房間收發(fā)文字;房間有創(chuàng)建者、有有效期、有人數(shù)上限;創(chuàng)建者可踢人、可銷毀,到期消息全清。

真正值錢的是收尾那句建議——別一口吃成胖子,按交付價(jià)值拆兩期:

1. MVP:單文件/文字分享 + 鏈接 + 有效期/下載次數(shù);
2. 增強(qiáng)版:在 MVP 之上疊房間、二維碼、密碼保護(hù)。

“先做 MVP,跑通了再加功能,成本最低。”

我當(dāng)時(shí)正處在"功能我全都要"的上頭狀態(tài),它沒有順著我堆,反而幫我做減法。一個(gè) AI 助手能在你興奮的時(shí)候踩一腳剎車、把你拽回 MVP 節(jié)奏,這點(diǎn)比寫得快重要得多。后面證明這個(gè)拆法是對(duì)的。

一張參考圖,它讀出了一份"設(shè)計(jì)規(guī)范"

功能定了,長(zhǎng)相還沒譜。我懶得描述,直接截了張看著順眼的風(fēng)格圖丟過去。它沒瞎夸,而是把這張圖反解成了一份可執(zhí)行的視覺規(guī)范:淺灰底 + 白色卡片、綠色主色(用于按鈕高亮與選中態(tài))、大圓角、低信息密度、頂部三大入口(接收/發(fā)送/房間)、右側(cè)信息面板 + 二維碼、底部安全提示。

隨后它定了 MVP 形態(tài),還順嘴問要不要給項(xiàng)目建長(zhǎng)期檔案。我說行,起個(gè)名叫"一只牛博",照這方向開干。它回:“好,牛博,開始動(dòng)手。”

從一張隨手截的圖到一份結(jié)構(gòu)化設(shè)計(jì) token,這一步把"我說不清的審美"翻譯成了"它能落地的規(guī)則",溝通成本直接砍半。

第一版:原生 HTML/JS 先把骨架立起來

第一版來得很快,純?cè)?HTML/JS,跑在 localhost:3000。骨架已經(jīng)齊了:頂部三 tab、中間發(fā)送區(qū)、有效期選擇、右側(cè)信息卡。糙是糙，但參考圖那個(gè)味兒出來了。

我讓它直接跑,它把啟動(dòng)指令一并給全:npm install、npm start,幾行就起來了。它不只交代碼,連"怎么把它跑起來"都替你想好了。

第二版:換 Vue,順手要個(gè)毛玻璃

原生寫著寫著,命令式的 DOM 操作堆起來結(jié)構(gòu)開始發(fā)散。我讓它用 Vue 重構(gòu)一版,順便提了個(gè)我一直想要的效果——毛玻璃磨砂。它上了 backdrop-filter: blur() 那一套半透明,整體質(zhì)感立刻不一樣了。

第三版:純摳細(xì)節(jié),把磨砂透明度調(diào)到位

毛玻璃第一版太糊,背景插畫全被磨沒了,白瞎。我讓它把透明度往回收,這步?jīng)]技術(shù)含量、純審美來回磨——從很高的透明度一點(diǎn)點(diǎn)壓,大概落在 45% 上下,背景插畫能隱約透出來又不搶前景內(nèi)容。截圖里我標(biāo)了句"有點(diǎn)效果",就是這版終于看順眼了。

值得一提的是,這種"差一點(diǎn)"的體感調(diào)優(yōu),它接得很穩(wěn):我不給具體數(shù)值,只說"太透了/再實(shí)一點(diǎn)",它能順著語(yǔ)義往對(duì)的方向收斂,而不是要我報(bào)參數(shù)。

最后落到 Java:技術(shù)棧是被"部署"推著走的

聊到上線,方向變了——而且是合理地變。

這東西要長(zhǎng)期掛公網(wǎng)給人用,Node 那套部署還得裝運(yùn)行時(shí)、起進(jìn)程、配守護(hù)、掛了得拉起。我后端本就是 Java,干脆整體落到 Spring Boot 3.3.5 + Java 17:打成單個(gè)可執(zhí)行 jar,配多階段 Dockerfile(maven 先構(gòu)建、產(chǎn)物塞進(jìn) jre 運(yùn)行鏡像),docker-compose 一拉即起,前置 Nginx 反代 + Let’s Encrypt 自動(dòng)簽證書。

前端反而收了回來:不再背 Vue 的構(gòu)建鏈,而是回到模塊化原生 JS——features / ui / utils / api 分目錄拆清。后端 Java 接管所有重活:存儲(chǔ)、限流、定時(shí)清理、口令生成、二維碼(ZXing 直出)。一個(gè) jar 梭哈,部署這件事一下就干凈了。它把上線命令也逐條列了出來。

HTML → Vue → Java 這條看似跳躍的路線,其實(shí)有一條暗線:原生用來驗(yàn)形態(tài),Vue 用來試交互與質(zhì)感,Java 用來扛部署與安全。 技術(shù)棧不是它拍腦袋換的,是跟著"這東西到底怎么用、怎么上線"自然長(zhǎng)出來的。這種"為約束選型"的判斷力,正是它專業(yè)的地方。

到這里,最終落地的工程能力已經(jīng)不是一個(gè)玩具了。隨手貼幾個(gè)我最后定稿里的真實(shí)參數(shù),佐證它給的不是花架子:

• 端到端加密:前端用 AES-GCM 256bit 加解密,密鑰編碼進(jìn) URL 的 #k= 片段、絕不上傳服務(wù)端,服務(wù)端從頭到尾只摸得到密文。這正是首頁(yè)"服務(wù)器只保存密文"那句話的底氣。
• 滑動(dòng)窗口限流:同 IP 上傳 3 次/分、30 次/時(shí),口令查詢 30 次/分,連續(xù) 20 次口令試錯(cuò)觸發(fā) 10 分鐘冷卻——直接掐死了暴力猜碼。
• 并發(fā)閘:全局并發(fā)上傳 10、單 IP 2,防止有人拿上傳打滿磁盤。
• 分級(jí)下載配額:按體積分檔,≤10MB 給 20 次、≤100MB 給 10 次、更大給 5 次。
• 定時(shí)清理:60 秒一輪掃過期內(nèi)容,**最長(zhǎng)保留 120 分鐘(2 小時(shí))**封頂。

翻開代碼:它寫得到底怎么樣

參數(shù)好看不代表代碼好。我專門挑了幾段它生成的關(guān)鍵實(shí)現(xiàn)貼出來——這幾段恰恰是最容易寫爛、最能看出功底的地方。

第一段,端到端加密的密鑰處理。 整個(gè) E2E 的命門在于"密鑰到底放哪"。它的做法是:密鑰只編碼進(jìn) URL 的 #k= 片段——而 URL fragment 按瀏覽器規(guī)范根本不會(huì)隨請(qǐng)求發(fā)往服務(wù)端,于是服務(wù)端從物理上就拿不到密鑰,只能存密文。

// 加密后,密鑰拼進(jìn) URL 的 hash 片段,絕不進(jìn)入請(qǐng)求體
export function encryptedUrl(url, key) {
  return `${url}#k=${encodeURIComponent(key)}`;
}

// 接收端從 location.hash 里把密鑰取回來,在本地解密
export function keyFromLocation() {
  const params = new URLSearchParams(location.hash.replace(/^#/, ""));
  return params.get("k") || "";
}

async function encryptBytes(plainBytes, rawKey) {
  const iv = randomBytes(IV_BYTES);                       // 每次隨機(jī) 12 字節(jié) IV
  const key = await importKey(rawKey);
  const cipherBuffer = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, plainBytes);
  return concatBytes(iv, new Uint8Array(cipherBuffer));   // IV 前置拼進(jìn)密文,解密時(shí)再切出來
}

用 WebCrypto 的 AES-GCM、每次隨機(jī) IV、IV 前置拼接——這是教科書級(jí)的正確姿勢(shì),既沒有自己造輪子,也沒有把密鑰誤傳上服務(wù)端。一個(gè)非密碼學(xué)背景的開發(fā)者很容易在這里翻車,它沒有。

第二段,限流。 它用的是帶時(shí)間窗的滑動(dòng)計(jì)數(shù)器,而且對(duì)計(jì)數(shù)器對(duì)象做了 synchronized,在并發(fā)下不會(huì)把窗口算錯(cuò):

public void require(String key, int maxCount, Duration window, String message) {
    Instant now = Instant.now();
    WindowCounter counter = counters.computeIfAbsent(key, ignored -> new WindowCounter(now, 0));
    synchronized (counter) {
        if (Duration.between(counter.windowStart, now).compareTo(window) >= 0) {
            counter.windowStart = now;   // 窗口過期,重置
            counter.count = 0;
        }
        if (counter.count >= maxCount) {
            throw new ApiException(HttpStatus.TOO_MANY_REQUESTS, message);
        }
        counter.count++;
    }
}

一個(gè)方法靠傳入的 key + window + maxCount 同時(shí)服務(wù)"上傳按分鐘/按小時(shí)"“查詢按分鐘”"消息按分鐘"等所有場(chǎng)景,沒有為每種限流復(fù)制一份邏輯。鎖的粒度也壓在單個(gè)計(jì)數(shù)器對(duì)象上、而不是整張表,并發(fā)吞吐不會(huì)被一把大鎖拖死。

第三段,我最服的一處——上傳并發(fā)閘為什么放在 Filter 層。 它沒把這個(gè)保護(hù)寫進(jìn) Controller,而是單獨(dú)做了個(gè) OncePerRequestFilter,并且在注釋里寫清了原因:

/**
 * Acquires upload concurrency permits before Spring parses multipart bodies.
 *
 * <p>Controller-level guards run too late for large uploads because the request
 * body may already be parsed. Keeping this protection at the filter layer
 * limits concurrent body ingestion from the same IP as well as application
 * processing.</p>
 */
@Component
public class UploadConcurrencyFilter extends OncePerRequestFilter {
    // ...
    try (TransferGuardService.Guard ignored = transferGuardService.upload(ClientIpUtil.resolve(request))) {
        filterChain.doFilter(request, response);   // 拿到許可才放行,出了作用域自動(dòng)釋放
    } catch (ApiException exception) {
        writeApiError(response, exception);
    }
}

“Controller 層的限制對(duì)大文件來說太晚了,因?yàn)檎?qǐng)求體可能已經(jīng)被解析”——這是一個(gè)踩過坑、真懂 Spring 請(qǐng)求生命周期的人才會(huì)寫的注釋。配合 try-with-resources 讓許可自動(dòng)釋放,既擋住了惡意并發(fā)上傳打滿磁盤,又不會(huì)泄漏許可。這一段單拎出來,放進(jìn)任何一個(gè)生產(chǎn)項(xiàng)目的 Code Review 都挑不出毛病。

第四段,清理調(diào)度的克制。 所有過期數(shù)據(jù)(分享、僵尸上傳、房間、限流計(jì)數(shù))的回收,只用一個(gè) @Scheduled 方法串起來,周期還能從配置注入:

@Scheduled(fixedDelayString = "${app.cleanup-interval-seconds:60}000")
public void cleanup() {
    shareStorageService.cleanupExpired();
    shareStorageService.cleanupStaleUploads();
    roomStorageService.cleanupExpired();
    rateLimitService.cleanup();
}

沒有為每類數(shù)據(jù)各起一個(gè)定時(shí)器,也沒把清理邏輯散落到各個(gè) Service 里偷偷跑——收口到一處、依賴注入、周期可配,該簡(jiǎn)單的地方就讓它保持簡(jiǎn)單。

把這四段連起來看,它的代碼不是"能跑就行"的水平:關(guān)注點(diǎn)分離清楚、并發(fā)與邊界考慮到位、注釋寫在真正需要解釋的地方、不重復(fù)也不過度設(shè)計(jì)。說實(shí)話,這個(gè)質(zhì)量已經(jīng)接近一個(gè)還不錯(cuò)的中高級(jí)工程師的手筆了。

成品:那些被產(chǎn)品邏輯反推出來的設(shè)計(jì)

界面我就不挨個(gè)念了。我更想說的是,最終這套交互里有幾個(gè)決策,是被"臨時(shí)傳輸"這個(gè)內(nèi)核反過來逼出來的——它們看著是 UI,本質(zhì)是產(chǎn)品判斷。這些點(diǎn),WorkBuddy 在前面的對(duì)話里基本都替我想到了。

第一個(gè)決策:默認(rèn)落在"接收",而不是"發(fā)送"。 這個(gè)選擇我很認(rèn)同。發(fā)送的人是主動(dòng)的,他知道自己要干嘛;接收的人是被動(dòng)的,他多半是被一個(gè)口令或二維碼引過來的,越早讓他看到"在哪輸碼"越好。 所以首頁(yè)一進(jìn)來就是接收態(tài)、一個(gè)大口令框懟在中央,把最高頻、最沒耐心的那條路徑放在了零點(diǎn)擊的位置。右側(cè)那條信息欄(最長(zhǎng) 2 小時(shí)、單文件 200MB、無(wú)需登錄)則在不打擾主流程的前提下,一句話講清了"這是個(gè)臨時(shí)的東西"。

第二個(gè)決策:把"有效期"和"接收次數(shù)"做成一等公民。 普通網(wǎng)盤的分享,過期是個(gè)藏在二級(jí)菜單里的高級(jí)選項(xiàng);在這里,它倆是創(chuàng)建流程里跑不掉的兩個(gè)旋鈕——有效期(10 分鐘到 2 小時(shí))直接平鋪成按鈕,接收次數(shù)(默認(rèn) 1 次)擺在顯眼處。這不是堆功能,而是用交互把產(chǎn)品價(jià)值觀頂?shù)接脩裟樕?這東西生來就是要消失的,你必須為它的"短命"做一次決定。文本框右下實(shí)時(shí)跳的字節(jié)數(shù)和 256KB 上限,也在持續(xù)暗示邊界感。

第三個(gè)決策:口令、二維碼、鏈接,三個(gè)入口一次性全給。 這是被真實(shí)場(chǎng)景逼的——我的原始痛點(diǎn)就是"跨設(shè)備",而跨設(shè)備意味著沒有統(tǒng)一的復(fù)制粘貼通道。所以生成結(jié)果頁(yè)同時(shí)吐出 8 位口令(適合念給旁邊的人 / 手敲)、二維碼(適合電腦發(fā)手機(jī)掃)、帶密鑰的完整鏈接(適合 IM 里甩過去),三條路通向同一份內(nèi)容。值得單獨(dú)說的是鏈接尾巴上那截 #k=E6LWXY1i0Ptt...——它就是前文那段加密代碼里"只活在 fragment 里、永不上送服務(wù)端"的 AES 密鑰。底部「端到端加密 · 服務(wù)器只保存密文」這句話,到這里是有代碼兜底的,不是貼上去好看的。

第四個(gè)決策:讓安全"可被感知"。 加密這件事,做了但用戶看不見,等于沒做。接收頁(yè)每一條內(nèi)容前面都掛著 E2E 標(biāo)記,旁邊跟著剩余次數(shù)、字節(jié)數(shù)、創(chuàng)建時(shí)間,頂上是還在跳的銷毀倒計(jì)時(shí)。用戶不需要懂 AES-GCM,但他需要在那一眼里相信"這東西是加密的、是會(huì)過期的、是只給我看的"——這種把后端保證翻譯成前端可見信號(hào)的處理,是很多工具會(huì)省掉、但恰恰最影響信任的一環(huán)。

第五個(gè)決策:銷毀態(tài)是被當(dāng)成一個(gè)正經(jīng)狀態(tài)來設(shè)計(jì)的,不是甩一個(gè)報(bào)錯(cuò)。 大多數(shù)應(yīng)用對(duì)"內(nèi)容沒了"的處理就是一個(gè) 404 或一行紅字。但對(duì)一個(gè)主打"閱后即焚"的產(chǎn)品來說,"已銷毀"恰恰是它最該講好的故事。所以這里是一塊完整的狀態(tài)卡:明確告訴你"接收次數(shù)已用完或內(nèi)容已過期,服務(wù)端已刪除臨時(shí)內(nèi)容",并直接給出「重新創(chuàng)建」的下一步。關(guān)鍵是這塊文案背后是真的——服務(wù)端定時(shí)任務(wù)把數(shù)據(jù)物理刪了,不是前端藏起來騙你。 我最初要的那句"用完自動(dòng)沒、不留痕",在這一屏被兌現(xiàn)了。

第六個(gè)決策:增強(qiáng)版的多人房間,真的落地了,而且是移動(dòng)端優(yōu)先驗(yàn)證的。 前面設(shè)計(jì)階段被單獨(dú)拆出去、靠 WebSocket 撐起來的那個(gè)"臨時(shí)空間",沒有停在 PPT 上。手機(jī)進(jìn)房后,頂部直接是 30 人在線 + 01:58:13 銷毀倒計(jì)時(shí)——把"多人"和"臨時(shí)"兩個(gè)最核心的屬性擺在第一屏,下面才是帶時(shí)間戳和字節(jié)數(shù)的實(shí)時(shí)消息流、二維碼邀請(qǐng)和退出。一個(gè) AI 協(xié)助搭的項(xiàng)目,能把二期功能也照著一期的設(shè)計(jì)語(yǔ)言完整收尾、并在窄屏上保持同樣克制的排版,這個(gè)完成度是超出我預(yù)期的。

寫在最后

整個(gè)項(xiàng)目斷斷續(xù)續(xù)聊下來,代碼我?guī)缀鯖]自己敲,但說實(shí)話也沒省到"動(dòng)動(dòng)嘴就行"的程度。真正花時(shí)間的是前面那些來回——三套方案選哪條、安全到底要做到哪一層、功能砍到什么程度算 MVP、參考圖那個(gè)調(diào)調(diào)怎么落地。這些想清楚了,后面寫代碼反倒是最不費(fèi)勁的部分。

一個(gè)"傳文件傳文字好煩"的破念頭,就這么變成了一個(gè)能掛公網(wǎng)、掃碼就用、用完自動(dòng)沒的小站。

到此這篇關(guān)于臨時(shí)文件傳輸工具哪個(gè)好用？WorkBuddy一鍵分享用完自動(dòng)銷毀不留痕的文章就介紹到這了,更多相關(guān)免登錄的臨時(shí)傳輸工具內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論