記憶力測試
在 Chromium 瀏覽器中通過 performance.memory 监控 JavaScript 堆，並可選擇分配 typed-array 塊觀察其接近標簽頁限制的增長。這不是硬件 RAM 測試，在本機執行，不會上傳。
實時堆统计
—
已用堆 (MB)
—
總堆 (MB)
—
堆限制 (MB)
0
測試已分配
—
已用 / 限制 (%)
壓力分配
堆增長圖
绿色：已用堆 · 黄色：總堆 · 红色虚線：瀏覽器限制 (Chromium)。每 500 ms 更新。
使用方法
- 在 Chrome 或 Edge 中開啟以取得完整的堆疊統計資料 (
performance.memory)。 Firefox/Safari 顯示僅指派模式。 - 閱讀 即時堆疊統計資料 — 它們每 500 毫秒自動刷新一次。
- 設定區塊大小（MB）和間隔（毫秒），然後按一下開始分配以對選項卡堆施加壓力。
- 觀看 堆疊增長圖 — 綠色已用，黃色總計，紅色虛線限制。
- 隨時按一下 停止，或讓工具在達到限制的 85% / 500 塊 / 300 MB（無 API）時自動中止。
- 按一下 Release & GC 以刪除測試分配；當 GC 執行時，已使用的堆應該會在幾秒鐘內下降。
- 使用 複製結果 進行票證或之前/之後的比較。
常見問题
為什麼堆限制與我的系統 RAM 不同？
此限制是每個瀏覽器標籤（JavaScript 隔離），而不是總電腦 RAM。桌面 Chrome 通常每個分頁的上限約為 4 GB，無論安裝的是 16 GB 還是 128 GB，以防止一個頁面佔用整台電腦。
這是 MemTest86 的替代品嗎？
不。這僅測量瀏覽器堆行為。 JavaScript 無法測試 DIMM 硬體。使用 MemTest86 可啟動 USB 來確保實體 RAM 的穩定性。
為什麼 Firefox 和 Safari 不顯示堆疊統計資訊？
Performance.memory 是一個非標準 Chromium API。其他瀏覽器會隱藏它以防止指紋辨識。該工具僅追蹤它自己分配的內容，上限為 300 MB。
發布和GC有什麼作用？
它清除對所有測試區塊的引用，以便它們有資格進行垃圾收集。使用的堆通常會在幾秒鐘內丟棄，而無需重新加載頁面。
分配何時自動停止？
當使用的堆疊超過 jsHeapSizeLimit (Chromium) 的 85% 時，在 500 個區塊之後，或在 Performance.memory 不可用時自分配 300 MB 時。
資料會離開我的瀏覽器嗎？
不會。所有監控和分配都發生在本機此選項卡中。
介紹
記憶體測試監視您的瀏覽器標籤正在使用多少JavaScript堆，並且可以選擇分塊分配記憶體，以查看在瀏覽器停止頁面之前您距離選項卡硬限制有多近。
在 Chrome 和 Edge 上，工具每 500 毫秒 讀取一次performance.memory：
- usedJSHeapSize → 已使用堆 (MB)
- totalJSHeapSize → 總堆 (MB)（為此選項卡保留）
- jsHeapSizeLimit → 堆疊限制 (MB) （崩潰/OOM 之前的上限）
在 Firefox 和 Safari 上，這些欄位是隱藏的。該工具仍然執行壓力分配，但僅追蹤分配的測試（MB），安全上限為300 MB。
這不是系統 RAM 測試，不是 MemTest86，也不是 VRAM 診斷。
測試如何進行
1.即時輪詢（500毫秒）
後台計時器呼叫readPerformanceMemory()並將一個點附加到 堆疊增長圖（500 毫秒/樣本時最多約 60 秒的歷史記錄）。
2. 壓力分配
開始分配以您的間隔（50–5000 毫秒）重複新增 Float32Array 區塊（預設 10 MB，可配置 1–100 MB）。
每個區塊都會接觸第一個和最後一個元素，因此分配器無法丟棄空的保留。
3.安全自動停止
| Condition | When |
|---|---|
| 堆限制的 85% | Chromium 上的used / jsHeapSizeLimit |
| 500塊 | 與瀏覽器無關 |
| 300 MB 自分配 | 當performance.memory缺失時 |
4. 發布&GC
釋放&GC清除內部區塊數組。垃圾收集是瀏覽器安排的 — 堆可能會在 1-5 秒內丟棄。可選的window.gc()僅在暴露時執行（某些開發版本）。
了解每個輸出
已用堆 (MB)
它是什麼：performance.memory.usedJSHeapSize— 目前由該標籤中的 JS 物件持有的記憶體。
如何解讀： 分配期間上升；應該在 Release & GC 之後下降。穩定爬升而不釋放表示此標籤或另一個開啟的應用程式標籤中存在洩漏。
總堆 (MB)
它是什麼：totalJSHeapSize— 引擎為隔離保留的記憶體（≥已使用）。
如何閱讀： 隨著分配器增長池，通常會陷入停滯狀態。總空間和已使用空間之間的巨大差距可能意味著碎片或保留但未使用的空間。
堆限制 (MB)
它是什麼：jsHeapSizeLimit— 瀏覽器強制執行的此標籤 JS 堆的最大值。
典型值： 64 位元桌面 Chrome 上約為 4 GB；在行動裝置上要低得多（256-512 MB 等級）。
未測量： 安裝的實體 RAM、作業系統可用記憶體或 GPU VRAM。
按測試分配 (MB)
它是什麼：chunk count × chunk size MB僅在此工具的引用中保存。
如何閱讀： 在 Chromium 上，與 已用堆 上升進行比較 - 它們應該相關。在 Firefox/Safari 上，這可能是壓力期間唯一上升的指標。
使用/限制(%)
它是什麼：usedMb / limitMb × 100當 API 存在時。
**讀法：高於85%**觸發自動停止。達到 100% 的風險會被殺掉（“噢，啪！”/OOM）。
堆疊增長圖
| Line | Color | 說明 |
|---|---|---|
| 已用堆 | Green | usedJSHeapSize隨著時間的推移 |
| 總堆 | Yellow | totalJSHeapSize |
| Limit | 紅色虛線 | jsHeapSizeLimit水平帽 |
| 僅分配模式 | Green | 無 API 時自分配 MB |
該測試測量什麼
| Measured | How |
|---|---|
| Tab JS堆疊使用趨勢 | performance.memory輪詢 |
| 接近選項卡 OOM | 已用/限制% |
| 刻意分配的效果 | 塊應力+圖表 |
| 釋放後GC回收 | 釋放後使用的堆丟棄 |
該測試不測量什麼
| 未測量 | Why |
|---|---|
| 實體 RAM/DIMM 錯誤 | JS 無法存取硬體 |
| 其他選項卡中的記憶體洩漏 | 僅此選項卡的堆 API |
| 本機應用記憶體（Electron main 等） | 僅瀏覽器選項卡範圍 |
| 交換/磁碟分頁 | OS-level |
| 準確的跨瀏覽器堆疊比較 | Chromium 之外缺少 API |
Safety
- 在 RAM 較小或開啟的選項卡較多的電腦上使用適中的區塊大小。
- 自動停止的存在是為了減少 OOM 選項卡崩潰——但不能保證在所有邊緣情況下都如此。
- 未經許可，請勿將其用作針對共享電腦的生產負載測試。
- 如果您分配了大量內存，請在離開頁面之前進行釋放和 GC。
常見用例
1. 這個選項卡有多少空間？
目標： 在載入重型 SPA 或本機 AI 模型之前，請參閱 已使用/限制 %。
執行： 僅打開工具 - 讀取即時統計資料而不分配。
2.您的網路應用程式疑似記憶體洩漏
目標： 將此工具的選項卡作為基準，然後在 另一個選項卡 中重現洩漏，返回並比較 Release & GC 之後的 Used heap。
注意： 測試中的洩漏必須位於您正在偵錯的選項卡中 - 該工具不會讀取其他選項卡的堆。
3. 部署前/部署後
目標：相同的塊設置，注意峰值已用堆和達到 85% 停止的時間 - 在同一瀏覽器中比較臨時構建和生產構建。
4. 向利害關係人解釋「4 GB 限制」與 32 GB RAM
目標： 螢幕截圖 堆疊限制 (MB) 與任務管理器系統 RAM 的比較。
5. Firefox / Safari 開發者
目標： 僅使用分配模式 - 確認應用程式邏輯可以容忍高達 300 MB 上限的增長，而無需依賴堆 API。
相關工具
將此選項卡堆監視器與其他裝置工具檢查配對：
- CPU Stress Test — 多核心Worker負載；查看 CPU 限制（而非堆疊）是否為瓶頸。
- GPU Stress Test — WebGL2 圖形壓力和 FPS 穩定性。
- AI GPU Test — 當大型設備上模型失敗時，WebGPU 準備就緒；先檢查堆淨空。
- Device Info — 粗略的
deviceMemory和環境上下文（與每個選項卡堆限制不同）。