C# Buffer.BlockCopy复制后short数组元素存32位值问题咨询

你看到的“short数组里存了32bit值”是调试器的显示bug，Buffer.BlockCopy的操作本身没有任何问题，不存在内存写坏的情况：

• 先理清楚复制逻辑：Buffer.BlockCopy是纯字节级的内存拷贝，根本不关心源和目标数组的元素类型，计数单位就是字节。你定义的Int16[]长度是4，每个Int16固定占2字节，整个数组的总内存大小刚好是8字节，你传入的拷贝长度也是8字节，整个拷贝操作完全内存对齐，没有越界：8字节刚好把4个Int16的位置填满，每个元素严格占2字节。值类型数组的元素是连续定长排布的，单个16位的元素根本没有多余空间存32位的值，从内存布局上就不可能出现你以为的“存了32bit值”的情况。
• 异常显示的来源：你是在调试的时候把Int16[]强转成UInt16[]在监视窗口看的对吧？C#里值类型数组的引用强转不会重新拷贝内存生成新数组，旧版Visual Studio的调试器在处理这类同尺寸值类型数组的强转显示时，有个很常见的步长计算bug：它偶尔会错把16位整数数组当成32位整数数组来遍历，按4字节的步长读内存，把相邻两个16位的值拼成一个32位值显示，索引计数也会跟着偏移。你看到的所谓“第3个元素的32Bit值”，就是调试器拼错了两个相邻元素读出来的错误结果，根本不是数组里真的存了这个值。
• 验证方法：别在监视窗口里强转数组看值，直接写个循环遍历max17261_results逐个打印元素，或者开内存窗口直接看数组的原始字节排布，就能看到所有元素都是标准16位长度，没有任何32位的异常值。

提示：调试值类型数组时不要轻信强转后的监视窗口显示，这类显示bug非常容易误导排查方向，要确认真实内存内容要么直接代码输出取值，要么用内存窗口看原始字节。

内容的提问来源于stack exchange，提问作者Atom