小編精選 - 技術文章翻譯 · 09月17日

採用新語言「Hike」作為系統後，二進位檔案縮減了99.8%，網路與實際處理效能也大幅加速

皆位好！平常我一邊做管理與其他事業，一邊也身兼從基礎設施到應用程式都能處理的現場 IT 萬事通。

某天，我在 Qiita 的熱門文章中看到 kanryu 先生的不小心做出了世界最強的 Wasm 編譯器這件事等文章，心想：「這是不是可以用在我們公司的檔案加密與大量傳送系統上？」這就是一切的開端。

實際試用後，我被意外驚人的輕量化（減少 99.8%）與壓倒性的高速化所震撼，立刻決定導入到實務中。更在這個過程中，第一次在 GitHub 上送出 bug 修正補丁（Issue），也獲得了非常珍貴的體驗。

其實這次也是我第一次在 Qiita 發文，我就把從技術選型到貢獻的整個過程，當作備忘錄分享給大家！

背景：既有技術的煩惱（JS 的極限 vs Go 的肥大，以及 TinyGo 的檢討）

在公司內部的檔案共享、加密與資料傳送系統中，上傳與下載的過程會在用戶端（瀏覽器）執行「加密／雜湊」、「檔案壓縮封裝」、「QR Code※ 處理」、「圖片中繼資料移除」。

1. 原本 JS 實作的極限

大容量會造成記憶體爆掉（OOM）：
當要在 JS Heap 上處理數 GB～100 GB 規模的資料時，會超過瀏覽器的記憶體限制（1～2GB），分頁會立刻當掉。
效能下降、凍結：
若用 JS 自行處理二進位與串流資料，因為 GC 壓力與 JIT 的型別轉換開銷，CPU 會飆到 100%，UI 也會卡死。

2. 標準 Go 語言的 WASM 障礙

二進位檔約 9MB，太重了：
我們也驗證過使用標準函式庫將 Go 轉成 WASM，但 4 個模組合計變成 約 9,100 KB（9.1MB），體積非常龐大，無法接受作為行動端（PWA）的首次載入負擔。

3. TinyGo 這個定番選項及其限制

一提到 Go 語言的 WASM 輕量化，工程師第一個想到的通常就是 TinyGo。實際測試後確實比標準 Go 小很多，但因為其獨特的 LLVM 後端所帶來的語言規格限制，以及在大容量串流中簡化 GC 的行為與卡頓疑慮，仍然讓人有所保留。

在這些反覆嘗試之中，我遇到了一個兼具數 KB 等級的驚人輕巧與舒適開發體驗的新語言——「Hike」。

採用的決斷：因為是 WASM，所以「實質上零風險」

在把新興的編譯器／語言導入實務系統時，雖然會擔心「WASM 環境或瀏覽器相容性會不會有風險？」，但我們是這樣判斷並著手實作的：

多重防護的 fallback 機制：
即使遇到不支援 Wasm 的瀏覽器，或發生預期外的問題，也會透過 wasm_loader.js 自動安全切換回傳統第一代 JS（WebCrypto／各種函式庫等）。因此風險實質上幾乎是零。

Hike 的使用手感與開發體驗（VS Code 除錯＆ AI 串接）

接近 Go 的寫法：
語法很像 Go，因此從既有程式碼移植過來非常順利。
可在 VS Code 進行原始碼層級除錯：
只要在 hikec 加上 -g 旗標輸出 LLVM DWARF 中繼資料，就能在 VS Code 中使用 GDB 或 LLDB 進行原始碼層級的中斷點、單步執行、變數檢視。即使在低階二進位處理出現問題時，定位原因也變得非常順暢。
與 AI（Gemini）的相容性良好：
透過 AI 協助進行程式碼討論、重構與最佳化，開發速度大幅提升。

結果：二進位大小壓縮 99.8% 以上與壓倒性的速度提升

針對導入的 4 個 WebAssembly 模組，以下比較「① 原本的 JS 單體」、「② 標準 Go WASM」、「③ Hike WASM（目前）」三個世代。

所有模組總結比較

模組名稱① 原本的 JS 單體② 標準 Go WASM③ Hike WASM（目前）主要角色crypto_pipeline5.1 KB（JS）/ WebCrypto約 2,500 KB**5.8 KB（🔻99.7%）100GB 串流 SHA-256、Base32、XOR 加密zip**97.6 KB（jszip.min.js）約 2,300 KB**4.2 KB（🔻99.8%）多檔案高速 ZIP 生成、CRC-32 計算qr**56.7 KB（qrcode.js）約 2,200 KB**3.1 KB（🔻99.8%）裝置連動 QR 生成、從攝影機影像進行二值化掃描image_optCanvas 重繪／手動切片約 2,100 KB**2.3 KB（🔻99.9%）JPEG EXIF／PNG 中繼資料移除、解析度判定總二進位約 160 KB約 9,100 KB（9.1MB）15.4 KB（完全不需要 JS glue code）所有模組合計> 💡 關於二進位縮減率：從標準 Go WASM（約 9,100 KB）移轉到 Hike WASM（15.4 KB）後，整體二進位大小縮減率達到 約 99.83%。

效能與執行特性的比較

評估項目① 原本的 JS 單體② 標準 Go WASM③ Hike WASM（目前）總下載時間（4G）約 130ms約 7,300ms（7.3 秒）約 12ms（立即完成）**總下載時間（3G）約 1.3 秒約 72.8 秒（1 分鐘以上）約 120ms（0.12 秒）**冷啟動（啟動）10ms～30ms150ms～450ms1ms～5ms（即時串流）**記憶體消耗（footprint）不固定（交給 GC，數十 MB）25MB～60MB64KB～1MB（固定線性記憶體）**JS glue code 依賴沒有必須（wasm_exec.js 18KB）完全不需要（0KB）**SHA-256 串流15～25 MB/s30～45 MB/s55～85 MB/s（最快）**ZIP 生成吞吐量30～40 MB/s60～80 MB/s120～150 MB/s**攝影機 QR 解析（640x480）15～35ms（30fps 會掉幀）10～20ms3～5ms（穩定超過 60fps）**100GB 連續處理的穩定性OOM 當機頻繁堆積膨脹風險以固定記憶體完成，連 1 秒延遲都沒有---

結論：為什麼是 Hike WASM

JS 單體：
受限於記憶體上限（OOM）與 GC，無法承受大容量串流處理。
標準 Go WASM：
功能與安全性都很完整，但 4 個模組總共 9.1 MB 的載入負擔是致命缺點。
Hike WASM：
透過 C-ABI 與 LLVM 最佳化，達成 4 個模組合計 15.4 KB（完全不需要 JS glue code）。完美兼顧「毫秒級啟動」、「零 GC、零複製的 100GB 固定記憶體完成」。

GitHub 首次貢獻（Issue＆修 bug 的故事）

在實務驗證的過程中，我遇到了一個與右移（lshr）相關的 LLVM 程式碼生成行為問題。

身為過去只會只讀不寫的作者，我鼓起勇氣第一次在 GitHub 上以 Issue 形式提交 bug 回報與修正補丁。結果不僅被作者 kanryu 先生非常迅速地合併，甚至還額外幫忙新增了多值語法模式，讓我感受到難以言喻的驚喜。這是一次親身體會到開源開發溫度與速度感的最佳經驗！

今後的展望：應用到其他系統

在這次導入中體會到驚人的輕量化成效後，目前也正在把 Hike 應用到公司內部另一套系統中較重的前端處理。

由於處理的是完全封閉的內部系統，無法公開詳細程式碼令人有些可惜。不過如果之後能有不涉密、可以分享的知識或能切割成 OSS 的題材，我也希望能再寫成續篇到 Qiita 上分享！

致謝

這次是我第一次在 Qiita 發文，也是第一次做 OSS 貢獻，非常感謝開發並公開這個優秀新語言「Hike」的 kanryu 先生，以及社群的各位。

另外，本篇文章的架構討論與技術驗證也有使用生成式 AI（Gemini）協助。在 AI 強力支援下，我順利完成了從驗證到撰寫的整個過程。

如果你對輕量化的 Wasm 環境、前沿開發、或是利用 AI 的開發方式有興趣，請一定要試試看 Hike！

補記（2026 年 9 月 16 日）

承蒙大家支持，儘管是第一次發文，仍有很多人閱讀了這篇文章，PV 已經突破 1000！收到超乎預期的迴響與溫暖的留言，我非常受到鼓舞。
另外，關於續篇文章，雖然受限於公司內部因素無法保證，但我目前仍在積極準備與努力，希望能盡量完成。若之後能公開，也希望大家能再賞臉閱讀。今後也請多多指教！

※「QR Code」是 DENSO WAVE 株式會社的註冊商標。

原文出處：https://qiita.com/kinop3/items/fdb57313458c2aa1bcdc