Go无内置向量相似度搜索，需依赖第三方库（如faiss-go、lance-go）或自行实现暴力遍历+余弦相似度；前者适合大规模低延迟场景，后者适用于小规模可控场景。
Go 里没有内置向量相似度搜索，得靠第三方库或自己写核心逻辑
Go 标准库不提供向量索引、近似最近邻（ANN）或余弦相似度批量计算等功能。你不能直接 import "math/vector" —— 这个包根本不存在。实际落地时，基本只有两条路：用成熟 ANN 库的 Go binding（比如 faiss-go 或 lance-go），或者自己实现轻量级方案（如暴力遍历 + cosine.Similarity）。前者适合千万级向量和低延迟要求，后者适合几百到几万维、且更新不频繁的场景。
用 go-faiss 做小规模向量搜索要注意 ABI 和构建环境
go-faiss 是 Facebook FAISS 的 Go 封装，但不是纯 Go 实现，它依赖 C++ 编译产物。常见报错像 undefined reference to `faiss::IndexFlatL2::IndexFlatL2(long long)'，本质是没链接上 FAISS 动态库。实操建议：
- 用 Docker 构建时，先
apt install libfaiss-dev，再go build；宿主机编译则需确认pkg-config --modversion faiss能返回版本 - 初始化索引别用
faiss.NewIndexFlatIP(d)直接传维度——如果向量是 float32 切片，必须提前转成*C.float并确保内存不被 GC 回收（常用C.CBytes+runtime.KeepAlive） - 搜索返回的
distances是平方 L2 距离，不是余弦相似度；要算余弦，得先归一化向量，再用IndexFlatIP（内积等价于余弦，前提是单位向量）
不用 C 依赖？自己实现余弦相似度 + 线性扫描足够快
对 10 万以内向量、维度 ≤ 1024 的场景，纯 Go 暴力搜索反而更稳、更易调试。关键不是“快”，而是“可控”。示例逻辑：
// vecs 是 [][]float32，query 是 []float32
func cosineSimilarity(a, b []float32) float64 {
var dot, normA, normB float64
for i := range a {
dot += float64(a[i]) * float64(b[i])
normA += float64(a[i]) * float64(a[i])
normB += float64(b[i]) * float64(b[i])
}
if normA == 0 || normB == 0 {
return 0
}
return dot / (math.Sqrt(normA) * math.Sqrt(normB))
}
注意点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 别用
float32做中间累加——容易溢出或精度丢失，dot和norm*必须用float64 - 如果向量已归一化（L2 norm = 1），可跳过分母计算，直接
return dot，性能提升约 30% - 并发搜索多个 query 时，用
sync.Pool复用临时切片，避免高频分配
向量更新频繁时，别硬扛——换用支持增量的库如 lance-go
FAISS 的 IndexFlat 不支持删除/插入，每次增删都得重建索引；而 lance-go（LanceDB 的 Go client）底层基于列式向量存储，支持追加写入和带谓词的混合查询（比如 “similarity > 0.85 AND tag = 'user'”）。但它目前不支持 GPU 加速，且仅适配 Lance 文件格式（.lance 目录）。如果你的 pipeline 已有 Parquet 流水线，这个组合很自然；但如果只是临时跑个相似推荐，引入 lance-go 反而增加部署复杂度。
真正容易被忽略的是：向量相似度本身不解决语义漂移。哪怕你用上了 faiss.IndexIVFFlat，如果原始 embedding 来自一个没 fine-tune 过的 Sentence-BERT 模型，搜出来的“相似”可能全是句式雷同、语义无关的结果——算法再快，也救不了特征质量。
