Go simd/archsimd 为什么代码不能跨架构（参数形态）

Go 的 simd/archsimd 代码不能直接跨架构，核心原因通常不是把变量名改一改就能解决，而是函数参数里已经写进了目标架构、向量宽度和 CPU 特性。archsimd 是低层实验包，接口暴露硬件相关能力；同样看起来像“向量”的参数，在 amd64、arm64 或 wasm 构建中，类型集合、可用操作和特性检查并不构成一份统一的公共契约。

官方文档：https://go.dev/src/simd/archsimd/doc.go?m=text

Go 1.27 发布说明：https://go.dev/doc/go1.27

先确认 archsimd 的实验与架构边界

排查时先把三种现象分开：包根本没有进入当前构建、实验开关没有打开，以及包进入了构建但调用参数来自另一种架构。官方源文件使用 //go:build goexperiment.simd，因此只写导入路径并不能让普通构建自动得到这组 API。

# 只查看当前项目实际使用的工具链和目标参数
go version
go env GOEXPERIMENT GOOS GOARCH GOTOOLCHAIN

# 在自己的构建入口中显式启用 SIMD 实验；不要把示例输出当成已验证结果
GOEXPERIMENT=simd go build ./...

如果错误是“找不到包”或“没有该符号”，先看工具链与实验设置；如果错误已经落到 cannot use、undefined 或方法集合不匹配，再看目标架构和参数形态。本文只提供排障写法，不声称以上命令已在本机执行。

为什么同名向量参数仍然不是可移植契约

archsimd 的类型名称包含宽度信息。官方 amd64 类型文件提供 Float32x4，也提供只有对应架构才适合使用的更宽向量类型；arm64 类型文件的同名基础向量集合并不等于 amd64 的完整操作集合。于是，把 archsimd.Float32x8 写进不带架构约束的公共文件，交给 arm64 编译时就可能因为类型或方法不存在而失败。

参数形态至少要同时看四层：目标 GOARCH 是否匹配，向量类型的元素数量是否匹配，方法需要的向量/掩码/数组参数是否匹配，以及对应 CPU 特性是否可用。比如 amd64 的某些操作会注明 AVX2 或 AVX512，arm64 的对应操作会注明 NEON；“方法名都叫 Add”不代表可以把一套函数签名搬到另一套文件。

按构建标签隔离架构相关参数

实用的隔离方式是让公共入口只暴露业务切片，把 archsimd 的具体向量类型留在对应架构文件中。公共文件负责稳定的数据边界，kernel_amd64.go 负责 amd64 专用参数，kernel_arm64.go 负责另一套实现或明确的回退路径。

//go:build goexperiment.simd && amd64

package kernel

import "simd/archsimd"

// addBlocks 只在 amd64 文件中出现，避免 Float32x8 进入其他架构的参数集合。
func addBlocks(input, output *[8]float32, delta float32) {
    // 广播参数先变成同宽向量，再传给向量 Add；不能直接传 float32。
    values := archsimd.LoadFloat32x8Array(input)
    offset := archsimd.BroadcastFloat32x8(delta)
    values.Add(offset).StoreArray(output)
}

这个片段的重点是文件边界和参数边界：Float32x8、数组长度 8、Add 的同类型实参以及 StoreArray 的目标数组必须一起看。若把函数移到公共文件，跨架构构建时首先失去的不是性能，而是类型可见性与方法集合的一致性。

公共函数只传业务切片，向量留在内部

如果业务层需要在多种架构上保持同一个调用方式，可以让入口接收 []float32，再由架构文件决定内部参数。这样跨架构稳定的是业务数据，而不是把 archsimd.Float32x8、Float32x4 或某个掩码类型伪装成可移植接口。

package kernel

// AddBlocks 保持业务侧使用切片；具体架构参数由同名的构建文件实现。
func AddBlocks(input []float32, delta float32) []float32 {
    // 输出先复制输入，避免把架构向量直接暴露给调用方。
    output := append([]float32(nil), input...)
    addPortableBlocks(output, delta)
    return output
}

公共函数仍然要明确长度、尾部和别名关系；它不会自动解决所有 SIMD 边界。关键是把“业务参数形态”和“硬件参数形态”分层，这样某个架构只增加或替换内部实现，不会把固定宽度类型传播到所有调用者。

排障时按参数形态逐项核对

最终判断可以压缩成一句话：archsimd 的参数形态是“架构 + 向量宽度 + 操作能力 + 构建条件”的组合，不能只看包名或方法名。遇到跨架构错误，先把类型移回对应的构建文件，再决定公共边界是否应退回普通切片。

为什么同名的 Float32x4 也不能直接说明跨架构安全？

同名只说明某个基础形态存在，不能保证关联操作、CPU 特性、构建条件和后续方法集合完全相同。还要按当前目标架构的官方文件逐项看签名。

只在运行时检查 CPU 特性，能解决编译期参数错误吗？

不能。运行时特性检查解决的是目标 CPU 能否使用某项能力；类型不存在、方法不存在和参数形态不匹配属于编译期边界。

为什么公共 API 不建议直接暴露 archsimd 类型？

因为调用者会被固定到某种架构和向量宽度，后续更换目标架构时，类型名、方法签名和构建文件都可能一起变动。把它收在内部，业务接口更稳定。