vector256.issupported 为 true 且运行环境满足 x64+.net 5+ + cpu 支持 avx 时才真正启用 avx 指令，否则退化为标量循环；需用 perfview 确认汇编中出现 vaddps 等指令，而非仅依赖调试器显示实例。
Vector256 不是“写了就能加速”的类型，它只在 x64 + RyuJIT + AVX 三者同时满足时才真正发射 AVX 指令；否则退化为标量循环，性能反而更差。
如何确认 Vector256<float>.IsSupported</float> 真生效
别信 Vector.IsHardwareAccelerated —— 它只表示 SIMD 基础可用，不保证 Vector256 被 JIT 编译成 AVX 指令。
-
Vector256<float>.IsSupported</float>必须为true，且运行环境是 .NET 5+（.NET Framework 不支持） - 项目必须设为
x64平台（AnyCPU 且勾选“首选 32 位”会直接禁用） - CPU 需支持 AVX（Windows 上可用
coreinfo -f查看；Linux 可查/proc/cpuinfo中的avx标志） - 调试器里看到
Vector256<float></float>实例 ≠ 真正向量化——得用 PerfView 或 dotnet-trace 抓 JIT 后的汇编，确认是否出现vaddps、vloadps等 AVX 指令
为什么 new float[n] + Vector256.Create() 一定慢
托管堆分配不保证 32 字节对齐，而 Vector256.LoadUnsafe 在未对齐地址上会回退到低效路径；Vector256.Create() 更是纯标量打包，完全绕过硬件向量寄存器。
- 改用
NativeMemory.AlignedAlloc(size, 32)（.NET 6+）或Marshal.AllocHGlobal+ 手动对齐 - 加载必须用
Vector256.LoadUnsafe(ref array[0], offset)，它会根据地址自动选vloadps（对齐）或vloadups（非对齐） - 绝对避免
Vector256.Create(array[i], array[i+1], ...)—— 这种写法强制拆包再装包，JIT 无法优化 - 若必须用托管数组，可配合
Span<float>.DangerousGetPinnableReference()</float>获取指针后调用LoadUnsafe
for (int i = 0; i 是常见但危险的写法
硬编码步长 8 会掩盖越界风险，且未分离主循环与尾部处理，JIT 很难做有效优化。
- 主循环应写成：
int i = 0; for (; i ，确保 <code>i + 7 - 尾部必须单独处理：
for (; i ，不能用 <code>Span<float>.Slice(i).CopyTo(...)</float>—— 那会引入额外边界检查和复制开销 - 若输入尺寸固定（如图像宽高），建议预填充（padding）至 8 的倍数，彻底消除分支
- 不要依赖 RyuJIT 自动展开：它对
Vector256循环的展开能力极弱；需手动展开（如每次迭代处理 2 组Vector256）才能榨干吞吐
Vector256<double></double> 和 Vector<float></float> 的实际选择差异
宽度不是越高越好。Vector256<double></double> 一次仅处理 4 个 double，而 Vector<float></float> 在 AVX 下通常也是 8 个元素，但吞吐受内存带宽和寄存器压力影响更大。
- 计算密集型（如热阻 ΔP）优先用
Vector256<double></double>：双精度误差敏感，且 4 路并行已显著减少迭代 - 数据密集型（如图像灰度转换）优先用
Vector256<float></float>：单指令 8 路，更匹配内存吞吐瓶颈 -
Vector<t></t>是运行时自适应宽度（SSE/AVX 切换），适合兼容性要求高的场景；但失去对 256 位寄存器的精确控制 - AVX-512（
Vector512）目前仅限 Intel 高端 CPU，且功耗和散热代价明显，生产环境慎用
真正卡住性能的从来不是“会不会写”，而是对齐、边界、运行时支持这三点没抠准。哪怕代码逻辑全对，只要其中一环断掉，Vector256 就只是个胖一点的 struct。
