Go 1.27 的 simd/archsimd 为什么在 RK3588 上触发 SIGILL：硬件能力探测边界

把项目升级到 Go 1.27 后，CI 在 ARM64 构建机上突然不是编译失败，而是在 GOEXPERIMENT=simd go test simd/archsimd/... 阶段直接收到 SIGILL。这类现象通常不是 Go 代码写错，而是测试执行到了当前处理器没有实现的 SIMD 指令；RK3588 就是官方 issue 中明确记录的一个场景。

先确认处理器能力与测试目标是否匹配，再决定升级工具链、调整测试矩阵或暂时跳过实验包；不要把 SIGILL 当成普通断言失败重试。

为什么 GOEXPERIMENT=simd 会在 RK3588 上撞到 SIGILL

Go 1.27 的发布说明把 simd 与 simd/archsimd 列为新增的实验性 SIMD 支持。官方 issue #80991 记录了在 Linux/ARM64 上引导 Go 1.27.0 后执行 archsimd 测试的情况：工具链本身可以构建，但测试进入 CarrylessMultiplyEven 后收到 SIGILL。

这里有一个容易混淆的边界：GOARCH=arm64 只说明目标是 ARM64 指令集家族，不能证明具体 SoC 提供每一条扩展指令。RK3588 的 CPU、内核、编译器目标和 Go 的实验包测试能力是四个不同层次。构建通过只覆盖了语法和目标架构检查，真正执行时才会暴露硬件缺口。

把硬件能力探测和 archsimd 测试分开看

排查时先把失败位置分层。simd/archsimd 是 Go 代码与汇编实现的组合，CarrylessMultiplyEven 代表具体的向量运算入口；当它被映射到处理器不认识的指令时，操作系统会报告 SIGILL。这不是测试数据导致的异常，也不是把 uint64 换成别的类型就能修好的参数问题。

更稳妥的做法是把板卡信息写入 CI 标签，至少区分通用 ARM64、带目标扩展的 ARM64 与 RK3588。只有硬件能力满足测试前提时才运行这组实验测试；如果只是构建标准业务包，可以保持实验开关关闭。这个决策应记录在测试矩阵里，方便后续升级 Go 版本后重新核对。

升级或绕开之前先核对这张边界表

Go 1.27.1 的官方发布记录说明该版本包含 SIMD 和 archsimd 相关修复，但修复工具链问题不等于让每一颗 ARM64 芯片获得新的硬件指令。升级后仍应在真实 CI 节点上验证；如果节点能力不满足，保留普通实现并把实验测试移到匹配的机器更可控。

常见问题

收到 SIGILL 是否说明 Go 1.27 编译器一定有 bug？

不一定。它首先说明执行到了当前 CPU 不支持的指令，只有在硬件能力满足而生成代码仍不正确时，才应进一步提交编译器问题。

GOEXPERIMENT=simd 能否在所有 ARM64 机器上打开？

不能。实验开关只启用相关实现和测试入口，实际可用性仍取决于处理器扩展、操作系统环境与 Go 当前支持范围。

CI 里怎么避免 RK3588 让整条流水线失败？

给测试节点打硬件标签，把 archsimd 测试限定在满足能力的节点；普通构建与通用单测保持独立，并保留失败日志供升级后复查。