ExplainThis 全端開發雙週報 #70 Web Worker 是什麼? 可以用在哪?
Web Worker 是什麼? 可以用在哪?
嗨～ 2026 新年快樂！
不知大家的新年都過得還好嗎? 2026 讓人充滿期待，先預祝大家在職涯上都能有豐碩的一年。
在去年底，ExplainThis 的 E+ 成長計畫突破了 900 位訂閱者，我們由衷地感謝讀者們的支持，在 2026 年我們也會持續寫經典且深入的內容，同時分享前瞻的趨勢，與讀者們在 2026 一起成長。
如同先前預告的，E+ 在 2026 年有新的價格方案 (連結)，由於 E+ 的內容已經足夠支撐單獨販售，我們將原本的訂閱制改成購買制，年方案維持 $3,650 (每天 $10 元)，但不會自動續訂；同時我們推出了終身方案，目前正在限時優惠中。
雖然改成購買制，我們仍會持續更新 E+ 的內容與社群 (購買終身方案的讀者，能越早開始利用未來會越來越豐富的內容)，在 2026 也預計至少會新增 50 篇深度主題文與 3 門線上課。如果你想在 2026 花時間建立前後端與軟體工程的軟硬實力，歡迎加入 E+ (連結)。
以上，接著讓我們一起進到這期雙週報的主題文，以及這期的推薦閱讀吧～
Web Worker 是什麼? 可以用在哪?
在早期的前端開發，會放在前端處理的東西不多，基本上不脫離簡單的事件操作、動畫特效；不過隨著前端發展越來越純熟，開發者在前端做的事情越來越多，當初 JavaScript 的設計就逐漸不足以支應新的需求。
這時前端社群逐漸有了不同的技術，來彌補 JavaScript 做不到的，藉此讓開發者們能在前端做更複雜的操作；在前端開發很常聽到的 Web Worker 與 Service Worker 都在這個範疇中。
Web Worker 是什麼?
Web Worker 的核心概念是開啟另一個執行緒做背景運算，讓複雜運算不會阻塞 JavaScript 的主要執行緒。
要理解這點，需要從歷史的脈絡來看 JavaScript 的發展。最開始 JavaScript 被設計時，那個年代的電腦與瀏覽器，都遠不如現代的強大，所以把 JavaScript 設計成單一執行緒 (single-threaded)，每次只能做一件事，基本上沒什麼問題。
但是現代瀏覽器能夠多工，前端開發者可以讓瀏覽器同時處理不同的事情，在這個脈絡下，JavaScript 的單一執行緒設計，就變成某種阻礙，無法有效發揮現代瀏覽器多核 CPU 的運算能力。
具體來說，假如今天有某個比較複雜的運算在跑，其他事情就沒辦法同時被處理；從前端的角度來看，這代表對使用者來說，畫面可能會卡住不動，使用體驗相當不理想。但明明瀏覽器能夠做更多事，所以如果能有一個機制讓複雜的、會卡住 JavaScript 執行緒的那些任務被分擔處理，就能解決這種不理想的使用者體驗。
Web Worker 的存在就是在解決這個問題。我們可以透過瀏覽器的 Web Worker API，去另一個執行緒 (在社群很多人稱之為 Worker Thread) 執行任務；這對 JavaScript 所在的執行緒來說，等同於在背景有另一個幫手幫忙執行任務，所以不會因為要處理運算，就被迫卡著不能做其他事。
可以在這張圖看到，透過 Web Worker，假如今天有某個需要花比較多時間的運算，就先透過 postMessage 放到 Worker 的執行緒做運算；運算完拿到結果後，再傳回主要執行緒，以平行的方式進行處理，這樣就能不阻塞主要執行緒。
Web Worker 的具體使用情境
在談具體的 Web Worker 使用情境時，推薦讀者不要硬背下這些使用情境，而是回到脈絡來思考。Web Worker 的出現是要解決前端複雜運算阻塞主要執行緒，導致畫面卡住的不良使用體驗。
進一步說，使用者做了某個操作，會希望立即得到 UI 的回饋，假如某件事情會導致這種立即回饋無法馬上發生，就可以思考使用 Web Worker，來把卡住的運算，搬到另一個執行緒來處理。
一個常見的使用情境，是在許多圖片管理網站 (例如 Flickr 或 Google Photos)，在載入圖片時，會同時去解析圖片拿到圖片的元資料 (meta-data)，在這個過程會需要把圖片轉成 ArrayBuffer 的格式，所以需要花時間做運算；這就是能用上 Web Worker 的情境，在 Worker 執行緒處理完後，再把拿到的元資料傳回主要執行緒，就能避免主執行緒阻塞。
特別注意，Web Worker 這種開另一個執行緒處理運算的做法，直觀看起來能讓效能變好，但並非所有情境都是如此。往下讀之前，推薦讀者可以稍微暫停，思考一下多開一個執行緒的取捨。
在使用 Web Worker 時，一個顯而易見的成本是傳遞訊息的成本，以上面提過的這張圖來說，把要處理的東西從主要執行緒，傳給 Worker 執行緒，處理完後再傳回主要執行緒，這每一個步驟雖然不需要花太多時間，但仍是額外的成本。所以假如某個運算，其實很快就能處理完，特別是那種對使用者體驗影響不大的運算，其實可以在主要執行緒處理即可，無需額外丟到 Worker 執行緒處理。
進一步說，加快主要執行緒處理，除了 Web Worker 這個思考角度外，還有其他可以做的方式。例如目前社群中熱門的做法之一，是透過 WebAssembly 把耗時的運算轉由其他語言處理 (例如 Rust)，在某些場景下，這會比用 Web Worker 來得更快。
閱讀更多
如果你想了解 Web Worker 如何具體使用，以及 Service Worker 與 Web Worker 的區別，我們在 E+ 的主題文中有更詳細的討論。感興趣的讀者，歡迎加入 E+ 後閱讀 (連結)。
本期推薦
由於過去兩期雙週報是年度回顧與精選，在這期雙週報我們主要會彙整去年 12 月搜集，還沒有在雙週報中列過的推薦連結
史丹佛大學的 CS146S: The Modern Software Developer 課程，把所有課上用的教材 (包含投影片、延伸閱讀)，以及課程作業全部開放。這堂課完整講解 AI 時代的軟體開發者，如何在軟體開發生命週期的每個階段運用 AI (連結)
提到 Google 的傳奇工程師，多數人第一時間應該會想到 Jeff Dean 與 Sanjay Ghemawat 這兩位 Google 唯二 L11 級別的工程師。先前 Jeff Dean 分享，他跟 Sanjay Ghemawat 過去幾年寫了一系列效能優化原則指南，本來只分享在 Google 內部；但 Jeff Dean 發文說他們把這份指南公開了(連結)。
我們曾分享過 Boris Cherny 是我們很敬佩的工程師。先前他在 The Peterman Pod 的訪談中 (連結)，罕見地不是聊 Claude Code，而是談他的職涯歷程，從大學讀經濟系輟學，到加入 Meta 在六年由中階工程師 (E4) 升到首席工程師 (E8)，再到打造年化經營收入破十億美元的 Claude Code。我們也針對他的分享，寫了聽完後的心得 (連結)
在聖誕假期間，社群中有一項白帽駭客的資安揭露 (連結)，是很多公司有使用的 AI 驅動文件平台 Mintlify 被發現有嚴重漏洞，讓大規模 XSS 攻擊變得可能。由於非常多公司 (包含 Cursor、Discord 等) 都使用 Mintlify，讓該漏洞的影響範圍極大 (連結)。我們有根據白帽駭客的公開分享，寫了一篇中文摘要 (連結)
Math Academy 把先前他們用來教機器學習入門的完整教科書免費公開。這系列教材當初是用來教美國的資優高中生，幫高中生打下能修碩博士課程的基礎。換句話說，只要會高中數學，基本上就能讀懂這本入門教科書。如果想趁著 2026 入門機器學習，蠻推薦可以一讀這本教科書 (連結)。
Andrej Karpathy 當年寫給史丹佛學生的「如何把課修好 Doing well in your courses」指南 (連結)。雖然是談如何修好課，但實際上更像談如何學習；雖然目標讀者是大學生，但裡面談的很多點適用各個階段的學習者。我們也寫了讀後心得 (連結)。
哈佛大學教授 Arthur Brooks 談「你需要無聊」 (連結)，因為在研究中發現，當人處在無聊的狀態時，思維系統會轉向使用大腦中的預設模式網路 (Default Mode Network, DMN)，這會讓人增加思考那些真正重要問題的時間。我們有根據他的分享，寫了一篇中文摘要 (連結)
文末彩蛋
在軟體工程師的工作中，經常會需要評論事情，例如常見的 Code Review 與 Technical Design Review。在寫 Code Review 時如果能帶著善意表達不同觀點，會對團隊的整體文化比較正面。
因此，在這期的彩蛋，想分享先前到已故心理學家 Anatol Rapoport 分享的「如何帶著善意批評」。相信如果帶著善意與建設性，能讓團隊整體的 Code Review 不僅品質好，也能同時有良好的氛圍。
Anatol Rapoport 提到有四個步驟
第一步，先嘗試把對方的立場重新表述得足夠清楚且公允，清楚到讓對方看了會忍不住說「謝謝，這正是我想說的，只是我沒想到可以這樣表達」。
第二步，清楚列出你與對方立場一致的地方，除了顯而易見的共識外，要特別寫下較為細緻或少見的認同點。
第三步，明確指出你從對方的觀點中學到了什麼。
最後，只有在完成以上這些之後，你才能開始提出任何的反駁或批評。
這個方法特別適用於「假如你已經跟某個人有過節或不愉快」的情境。很多人可能因為先前衝突留下的疙瘩，在 Code Review 時會針對性地留下不恰當的用詞，變成對人不對事。假如能夠跟著上述的四步驟，在衝動留言之前，能夠有效緩衝，讓最後留下的言是更公允且有建設性的。