vector是C++标准库中基于动态数组实现的序列容器，支持O(1)随机访问、尾部高效增删、内存连续布局及自动扩容机制，底层采用三指针模型（_start/_finish/_end_of_storage）管理。
Vectorfor 还慢。
Vector 和 Vector 在 x64 下性能差异大吗？
差异明显。.NET 6+ 在 x64 下默认对 Vector<float></float> 启用 AVX2（256 位，8 个 float），而 Vector<int></int> 多数运行时仍回落到 SSE2（128 位，4 个 int），除非显式检查并调用 Vector.IsHardwareAccelerated 确认支持 AVX2 的整数向量。这不是语言限制，而是 JIT 当前实现策略——float 向量的硬件加速路径更成熟。
-
Vector<float>.Count</float>在 AVX2 机器上通常是 8，Vector<int>.Count</int>往往是 4 - 相同数组长度下，float 向量一次处理 8 元素，int 向量可能只处理 4，吞吐量天然受限
- 若逻辑本质是整数运算但可转为 float（如归一化索引、定点缩放），有时主动用
Vector<float></float>+Vector.ConvertToInt32()反而更快
为什么 Vector.LoadUnsafe 常崩溃或结果错乱？
根本原因是未满足内存对齐与长度双重要求：Vector.LoadUnsafe(ref T source, int elementOffset) 要求从 source 偏移 elementOffset 后的地址开始，必须有连续 Vector<t>.Count</t> 个 T 元素，且起始地址需自然对齐（AVX2 要求 32 字节对齐，SSE2 要求 16 字节）。
- 常见错误：直接传入
floatArray.AsSpan().Slice(i)—— Span 可能来自堆分配，地址不对齐 - 静默损坏比崩溃更危险：不对齐读取可能返回垃圾值，尤其在 AVX-512 或某些 Arm 平台
- 安全做法：先用
Unsafe.AlignUp(ref span[0], (uint)(Vector<float>.Count * sizeof(float)))</float>对齐指针，再校验剩余长度 ≥Vector<float>.Count</float>
数组长度不是 Vector.Count 整数倍时怎么补足？
必须手动处理末尾残余，Vector 不会自动帮你跳过或截断。漏掉这步会导致越界读写或结果缺失。
- 典型模式：主循环用
for (int i = 0; i .Count + 1; i += Vector<float>.Count)</float> - 末尾用标量循环：
for (int i = length - length % Vector<float>.Count; i </float> - 别依赖
Vector.Count动态变化——它在运行时固定，但不同机器可能不同（如老 CPU 返回 4，新 CPU 返回 8），所以补足逻辑必须基于实际Vector<float>.Count</float>值计算
Vector.Fill 是并行填充吗？
不是。Vector.Fill 是纯语法糖，底层仍是标量循环调用委托。它不触发任何 SIMD 指令，和手写 for 性能一致，甚至略差（委托调用开销）。
- 误用示例：
Vector<float>.Fill(100, i => data[i])</float>—— 完全没加速，还多一层间接调用 - 真正高效填充：用
Span<float></float>配合Vector<float>.Count</float>步进，批量Vector.Load或new Vector<float>(value)</float>广播，再Vector.Store - 广播初始化正确写法：
var vOnes = new Vector<float>(1f)</float>，不是Vector.Fill(n, _ => 1f)
真正难的不是写对 Vector 语句，而是判断某段逻辑是否值得 SIMD 化——得看数据局部性、访存模式、分支概率，以及目标机器是否真有对应指令集。很多“加速”代码跑在没有 AVX2 的机器上，只是安静地变慢而已。
