JavaScript TypedArray.from 的映射时机：先乘十再转整数，为什么与先建数组再 map 不同
把小数测量值乘十后存进字节数组，常见的两种写法只差一步：Uint8Array.from(input, transform)，或 Uint8Array.from(input).map(transform)。它们都返回新的 Uint8Array，却未必保存相同的结果。差别发生在第一次写入目标类型时，小数部分可能已经被舍去。
本文在 Node.js v24.19.0 上运行，使用内存中的两个虚构数值，不读取文件、不访问网络。保存下面完整程序为 demo.mjs，再运行 node demo.mjs。示例的计算规模很小，目的在于看清先后顺序，不是测量性能。
AI模型生成概念示意：同一批色块分别经过“先变换后入格”和“先入格后变换”两条路径；块高只是顺序差异的比喻，不代表代码中的精确数值。
完整实验
const input = [1.2, 2.8];
const early = Uint8Array.from(input, value => value * 10);
const stored = Uint8Array.from(input);
const late = stored.map(value => value * 10);
console.log('input', JSON.stringify(input));
console.log('map-before-store', JSON.stringify([...early]));
console.log('stored-first', JSON.stringify([...stored]));
console.log('map-after-store', JSON.stringify([...late]));
console.log('float-storage', JSON.stringify([
...Float64Array.from(input).map(value => value * 10)
]));
console.log('overflow', JSON.stringify([
...Uint8Array.from([25.6], value => value * 10)
]));
try {
Uint8Array.from([1n]);
} catch (error) {
console.log('bigint-input', error.name);
}本地实际输出
input [1.2,2.8] map-before-store [12,28] stored-first [1,2] map-after-store [10,20] float-storage [12,28] overflow [0] bigint-input TypeError
第一条路径把原始的 1.2、2.8 交给映射函数，乘十得到 12、28，再写入 Uint8Array。第二条路径先构造 stored，两个槽位中已经只有 1、2；后面的 map 只能看见这一版数据，所以结果是 10、20。把后一步放大更多，也无法反推出被丢掉的小数。
float-storage 使用 Float64Array 作为中间存储，因此本例保留了小数，最后也得到 12、28。这说明要检查的是中间类型是否已经改变数据，而不只是两边是否写了同一个乘法函数。TypedArray 的 map 返回同类元素存储，不能把它理解成总会回到普通 JavaScript 数组。
from 的映射回调得到当前值和索引，然后回调结果才进入目标类型。若数据本来来自整数 TypedArray，映射参数也不能恢复更早的精度损失。选择回调放在哪里之前，先标出每一段数据真实存储的类型。
边界与使用约定
overflow 一行故意把 25.6 乘十，得到超出八位无符号整数范围的 256，存储后是 0。这是该整数类型的转换规则，不是自动截在 255。业务若要求限幅或拒绝越界，必须在写入前明确实现相应检查。Uint8ClampedArray 又有不同的限幅规则，不能只看名称相近就替换。
最后的 TypeError 表示 Number 系列的 Uint8Array 不能直接接收 BigInt。映射函数也可能主动抛错；出现异常时应把本轮转换视为失败，不把“尚未得到返回数组”当成输入一定没有副作用。这里的回调没有外部动作，因此失败验证只打印异常类型。
应用到传感器编码、颜色通道或紧凑缓存时，可先用几个手算得出的边界值核对：带小数、恰好为零、刚超过上限，以及不允许的输入类型。先约定缩放与存储规则，再选择在哪一步调用 from。
参考资料
官方资料核验日期：2026-10-02。
