Bun 1.4.2 要不要升級？先驗證 Elysia、AsyncLocalStorage 與 lockfile

1.4.2 修了什麼，哪些專案優先驗證？#

官方目前列出七項修正與 JavaScriptCore 升級。可以依你的實際使用面向排序：

「修正」不等於「所有相關 bug 都不存在」。例如 JIT 和 GC crash 是 rare path，應用程式仍需用自己的 runtime、平台和負載做驗證，不要把官方列出的修正解讀成完整的 stability guarantee。

先確認 binary、revision 和安裝來源#

Bun 官方建議用 bun upgrade 更新 stable，並用 bun —version 和 bun —revision 確認 binary。升級前先記錄目前版本，方便在 CI 與本機比較：

1
bun --version
2
bun --revision
3
which bun

如果 Bun 是透過 Homebrew、Scoop 或其他 package manager 安裝，就用同一個 package manager 更新；不要一邊讓 Homebrew 管理 binary，一邊執行 bun upgrade，否則下次套件更新可能覆蓋你的版本或讓 PATH 指向另一個 binary。

單機安裝的 stable 更新流程可以是：

1
bun upgrade
2
bun --version
3
bun --revision

不要在 production host 上直接切 canary 來確認 bug 是否消失。canary 適合隔離環境做先行驗證，但它不等於 stable release，也會帶來另一組未知變更。

Elysia：先做 build diff，再啟動產物#

如果你的 Elysia 專案使用 bun build，1.4.2 的回歸修正值得優先驗證。不要只看 build command 的 exit code，還要檢查產物能不能啟動並處理一條真實 route：

1
rm -rf .tmp-bun-142-dist
2
bun build ./src/index.ts --target bun --outdir .tmp-bun-142-dist
3
bun run .tmp-bun-142-dist/index.js

上面的 entrypoint 和輸出檔名請換成自己的設定。測試重點包括：

• 同一個 block 內是否有依賴變數名稱或 closure 行為的程式碼。
• Elysia plugin、middleware 和 route 是否被 bundler 產出正確。
• production env、dynamic import 和 error handler 是否仍照預期。
• build 前後的 source map、artifact size 和啟動時間是否出現異常。

如果你是透過 framework script 產生 build，先把真正執行的 Bun command 印出來；bun run build 可能呼叫另一個 bundler，不能用它的成功代替 bun build regression test。

AsyncLocalStorage：測 nested context 與長時間生命週期#

官方修正的是 exit() 和 nested run() 不再保留外層 store。這類問題很難用一次請求看出來，應該做一個最小測試再接到實際 logger／request context：

1
import { AsyncLocalStorage } from 'node:async_hooks'
2

3
const storage = new AsyncLocalStorage<{ requestId: string }>()
4

5
storage.run({ requestId: 'outer' }, () => {
6
  storage.run({ requestId: 'inner' }, () => {
7
    console.log(storage.getStore()?.requestId)
8
  })
9
})

真正的回歸測試還要覆蓋：

1. request A 與 request B 並行時，context 不會交叉。
2. nested run 完成後，外層 store 仍可用但不會無限保留短生命週期資料。
3. exit() 後的 callback 不會讀到錯誤的 request context。
4. 長時間壓測的 heap／RSS 沒有因 middleware store 持續增加。

不要只用 process.memoryUsage() 的單次數值判斷 memory leak 已修好；請固定 request pattern、跑足夠時間，並比較 1.4.1 和 1.4.2 的趨勢。

worker_threads：事件順序要用事件測，不要用 sleep 猜#

1.4.2 修正 worker_threads 的 online 事件會先於 worker 第一批 message 抵達的順序。依賴初始化 handshake 的程式，應直接把順序寫成 assertion：

1
const events: string[] = []
2

3
worker.on('online', () => events.push('online'))
4
worker.on('message', () => {
5
  events.push('message')
6
  if (events.length >= 2) {
7
    console.assert(events[0] === 'online')
8
  }
9
})

測試時不要用固定 setTimeout(100) 等待「應該已經 online」。正確做法是等待事件、設定 timeout 作為失敗保護，並測試 worker error、early exit、重啟和 shutdown。若應用程式使用 @discordjs/ws 或其他 event-driven library，還要跑一次實際 reconnect 流程。

lockfile panic：在乾淨工作目錄重現#

如果你曾遇到 bun install 對 package-name hash 不一致的 lockfile panic，請不要在目前工作目錄直接刪 lockfile 來證明問題消失。先複製到暫存目錄或使用 CI 的 clean checkout：

1
git clone --no-local . /tmp/bun-142-check
2
cd /tmp/bun-142-check
3
bun --version
4
bun install --frozen-lockfile
5
bun test

實際專案若使用 Git worktree、private registry、workspace 或 patched package，要把相同的設定帶進測試。測試通過後再決定是否更新 lockfile；不要因為 Bun 1.4.2 能讀取現有 lockfile，就順便把 npm、pnpm、Yarn 和 Bun 的 lockfile 全部換掉。若團隊仍以 pnpm 為主，可以先參考pnpm 安裝時的 hardlink／copy fallback 排查，把 package manager 的責任邊界分開。

圖片、JSON 與 runtime crash 的小型 fixture#

對其餘修正，使用固定 fixture 比用人工點選更容易回歸：

• 準備 CMYK／YCCK JPEG，確認 Bun.Image 可以解碼，並檢查輸出色彩與尺寸。
• 準備截斷 JSON 和錯誤 MIME response，確認 .json() 會得到預期 SyntaxError，且 retry 不會重複寫入資料。
• 在 glibc 與 musl container 各跑一次長時間 process，記錄 JIT／GC crash、RSS 和 exit code。
• 對 Date、Intl、TypedArray 的 hot path 跑現有效能基準；JavaScriptCore 升級後不要假設結果完全相同。

這些測試的目的，是確認你的程式能從修正中受益，而不是重做 Bun 官方完整測試套件。遇到差異時，保留 Bun version、revision、OS、CPU、lockfile、最小 reproduction 和完整 stderr，才容易交叉比對。

上線前的升級矩陣#

可以用以下順序把 Bun 1.4.2 放進團隊流程：

1. 在隔離 branch 更新單一 CI job 的 Bun binary。
2. 跑 clean install、type-check、unit test、build 和主要 route smoke test。
3. 對 AsyncLocalStorage、worker_threads、圖片和 JSON 依實際使用面向補 regression。
4. 做一次 staging soak test，觀察 memory、crash、log 和 request latency。
5. 用 bun —revision 寫進 build metadata，確定 production 實際跑的是驗證過的 binary。
6. 若使用外部 package manager，確認它的 lockfile 與 cache 行為沒有被一併改動。

結論：以受影響路徑決定升級範圍#

Bun 1.4.2 的價值在於修正幾個會讓 production 很難排查的 regression：Elysia build rename、AsyncLocalStorage memory leak、worker event ordering、JIT／GC crash 和 lockfile panic。升級時先確認 binary 來源與 revision，再按你的實際使用面向跑 targeted smoke test；不要只把版本字串改成 1.4.2，也不要同時把整個 package manager 流程改掉。這樣即使升級後仍有問題，你也能知道是 runtime、bundler、lockfile 還是部署層。

常見問題#