chrome memory inspector 不支持十六进制内存转储，因其仅分析js堆快照而非物理内存；可通过console手动转换uint8array为hex字符串、console.table查看、导出dump.bin离线分析，或改用node.js/lldb等原生调试工具。
Chrome Memory Inspector 本身不提供直接以十六进制形式查看或编辑原始字节数组的交互界面。它主要用于分析 JavaScript 堆内存快照（Heap Snapshots），定位对象引用、内存泄漏和构造函数分布，而非低级内存调试。原始字节数组（如 Uint8Array、ArrayBuffer）在堆中以结构化对象形式存在，Inspector 显示的是其 JS 层封装（如 length、buffer 引用），不是裸内存地址+hex dump。
为什么不能像 GDB 那样 hex-dump 内存
Chrome 运行在沙箱化的 V8 引擎之上，JavaScript 无法访问进程任意内存地址；所有数组数据都经过 V8 的堆管理与偏移抽象。Memory Inspector 展示的是序列化后的堆图节点，不是物理内存映射。你看到的 Uint8Array 实例指向一个 ArrayBuffer 节点，后者可能被标记为 “(compiled code)” 或 “(external)” —— 若是外部分配（如 WASM 内存或 WebGL buffer），其底层字节通常不可见。
可行的替代方案：间接获取十六进制视图
虽然不能“直接 hex-dump”，但可通过以下方式在 DevTools 中快速检查原始字节内容：
-
在 Console 中手动转 hex 字符串：选中变量后，在控制台输入类似代码：
new Uint8Array(yourArrayBuffer, offset, length).reduce((s, b) => s + b.toString(16).padStart(2,'0') + ' ', '')
可输出空格分隔的十六进制字符串（例如"ff 0a 1b c0 ..."）。 -
使用
console.table()查看小范围字节：对长度适中的Uint8Array，执行console.table(Array.from(yourUint8Array))，再点击表格列标题排序，便于人工扫读；配合右键「Store as global variable」可反复操作。 -
借助 Sources 面板 + 断点 + Scope 检查：在调试运行时暂停后，Scope 面板会列出局部
Uint8Array；展开后能看到buffer字段，点击进入可查看其byteLength和data（若为可序列化 ArrayBuffer）。此时右键 buffer → «Copy object» → 粘贴到控制台，再用new Uint8Array(...)处理。 -
导出 ArrayBuffer 到本地分析：在 Console 中运行：
save(new Blob([yourArrayBuffer]), "dump.bin")
（需先定义save函数或使用 FileSaver.js），下载后用 HxD、xxd、或 Python 的hexdump工具离线分析。
高级场景：WASM 或 SharedArrayBuffer 的字节观察
若处理 WebAssembly 内存或共享内存，可利用：
-
WASM 模块的
memory.buffer：在 Console 中访问wasmInstance.exports.memory.buffer，然后同上转换为Uint8Array并 hex 输出；注意需确保模块已初始化且内存未被 grow。 -
SharedArrayBuffer + Atomics（仅跨线程安全场景）：虽不能直接 inspect 共享内存布局，但可在主线程创建视图（如
new Uint32Array(sharedBuf)），再用循环打印i和view[i].toString(16)观察变化。
不复杂但容易忽略：真正需要“内存级 hex 调试”的场景，往往已超出浏览器 JS 沙箱能力边界——此时应考虑 Node.js（搭配 node --inspect + Chrome DevTools，支持 Buffer 的 .toString('hex')）、或切换到 C/C++/Rust + VS Code + LLDB/GDB 工具链。
