字節二面："你說skill之間傳數據，直接在skill裡指定就行——那兩個任務併發跑，數據串了怎麼辦？"

近日，字節跳動的一場技術面試中，一道關於多技能（skill）系統數據傳遞的問題引發開發社群熱議。面試官直指核心：「你說skill之間傳數據，直接在skill裡指定就行——那兩個任務併發跑，數據串了怎麼辦？」這個提問看似簡單，卻精準點出了分散式系統設計中一個極易被忽視的陷阱：當多個任務同時執行時，依賴直接指定路徑傳遞數據，可能導致資料相互覆寫、讀取髒數據，甚至引發系統崩潰。據了解，這道題目來自字節跳動二面現場，面試官意在考察候選人對於併發環境下數據隔離與一致性的理解。

許多開發者在搭建多skill系統初期，常因追求快速實現而選擇直接在skill內部硬編碼數據傳輸對象，認為只要把來源與目標寫清楚就能運作。然而，一旦面臨真實的併發場景——例如兩個任務同時讀寫同一份共享變數，或透過直接引用傳遞複雜物件——數據就可能「串」得一塌糊塗。業界實務中，為了應對此類痛點，已歸納出多種在skill之間安全傳遞數據的方案。雖然每種方案各有取捨，但共通目標都是確保併發任務間的資料隔離與原子性。

常見的做法包括利用共享記憶體搭配鎖機制，但需要仔細設計鎖粒度，避免死鎖或效能瓶頸；採用訊息佇列（如 Kafka、RabbitMQ）則能透過非同步通訊自然隔離任務，但需處理訊息順序與重複消費問題；分散式儲存（如 Redis、資料庫）可提供集中式的讀寫控制，但網路延遲與序列化開銷不可忽視。此外，還有以無鎖資料結構或原子操作（如 CAS）實現輕量同步，以及透過事件匯流排或 actor 模型進行任務隔離。以共享記憶體為例，若兩個任務併發存取同一塊記憶體區域，而沒有適當的互斥鎖保護，後寫入的資料可能直接覆蓋前一個任務的結果，導致最終狀態不一致。面試問題中的「直接指定」方式，正是這種風險的典型呈現。

面試官期待候選人不僅能說出「用鎖」或「用隊列」等關鍵字，更要能分析不同場景下應該選擇哪種機制——例如讀多寫少的情境適合讀寫鎖，而高寫入吞吐則可能需要分段鎖或樂觀鎖。另一種常見的改進方案是引入分散式追蹤與版本控制，讓每筆資料攜帶時間戳或序號，任務在寫入前先確認當前版本，避免覆蓋更新。這種做法適合需要最終一致性的場景，但若任務對時序敏感，則仍需強同步。面試官進一步追問時，往往會帶出實際業務案例：比方說，一個推薦系統中，多個特徵處理skill同時計算用戶畫像，若其中一個skill直接修改了另一個skill正在使用的快取鍵值，就會造成模型輸入錯亂。

字節跳動內部對這類問題格外重視，因為其產品場景經常面對高併發、低延遲的嚴格要求，任何數據串擾都可能影響用戶體驗。總體而言，這道面試題反映出字節跳動技術考核的實戰導向——不只看候選人是否知道常見做法，更看能否辨識潛在的併發陷阱，並給出可落地的解決策略。對正在設計或維護多skill系統的團隊來說，理解每種傳輸方案的原理與取捨，遠比在skill裡直接指定傳輸對象來得重要。當兩個任務同時跑起來，你的數據會不會「串」，往往決定了系統能否穩定撐住真實流量。