base64 编码 float32array 后解码长度变长，根本原因在于直接使用 `array.buffer` 忽略了 `byteoffset` 和 `bytelength`，导致编码了超出视图范围的冗余内存。正确做法是用 `uint8array` 显式指定偏移和字节长度来构造视图。
在 JavaScript 中，Float32Array 是 TypedArray 的一种，它本质上是底层 ArrayBuffer 的视图（view），而非独立拷贝。这意味着它可能只占用缓冲区中的一段连续内存——从某个字节偏移（byteOffset）开始，持续若干字节（byteLength）。若直接传入 array.buffer 给 Uint8Array 构造函数（如 new Uint8Array(array.buffer)），你得到的是整个缓冲区的字节视图，而非该 Float32Array 实际覆盖的那部分。
这正是问题根源：你的原始 Float32Array 长度为 76800，对应 76800 × 4 = 307200 字节；但它的 buffer.byteLength 可能远大于 307200（例如 309136 字节），多出的部分属于未被该视图使用的“闲置”内存。Base64 编码这段完整缓冲区后，解码再重建 Float32Array 时，若仍按完整缓冲区长度除以 4 计算元素数（如 new Float32Array(decodedBuffer)），就会得到错误的 309136 ÷ 4 = 77284 —— 这正是你观察到的长度差异。
✅ 正确做法：始终基于 Float32Array 的 byteOffset 和 byteLength 构造精确的 Uint8Array 视图：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
// ✅ 正确：仅编码 Float32Array 实际占用的字节范围 const uint8View = new Uint8Array( pcdRef.current.buffer, pcdRef.current.byteOffset, pcdRef.current.byteLength ); const base64String = encode(uint8View); // 使用任意 Base64 编码函数（如 stablelib、btoa 等） // 解码后，也需用相同字节长度重建 Float32Array const decodedBytes = decode(base64String); // 返回 Uint8Array const floatArray = new Float32Array( decodedBytes.buffer, decodedBytes.byteOffset, decodedBytes.byteLength / Float32Array.BYTES_PER_ELEMENT );
⚠️ 注意事项：
- 不要依赖 array.buffer 的 byteLength，而应始终使用 array.byteLength（即视图实际字节数）；
- array.length × Float32Array.BYTES_PER_ELEMENT === array.byteLength 恒成立，这是验证视图完整性的重要依据；
- 若你使用 btoa() 或 Buffer.from(...).toString('base64') 等方案，同样需确保输入 Uint8Array 是精确视图，否则问题复现；
- 在 Web API 通信中，建议在 JSON 中额外携带 byteOffset 和 length 元信息（尽管多数情况下 byteOffset === 0），以实现完全可逆序列化。
总结：TypedArray 的“视图”特性是高性能内存操作的基础，但也要求开发者显式管理边界。忽略 byteOffset/byteLength 是 Base64 序列化二进制数据时最常见且隐蔽的陷阱之一——修复它只需一行参数修正，却能彻底解决长度失真问题。
