在 Go 1.21 版本之前，go.mod 文件中我们常见的指令无非是 module、go、require、replace 等几个老朋友。然而，当你打开一个较新的 Go 项目时，可能会发现一个陌生的面孔——toolchain 指令。这个从 Go 1.21 引入的新特性，究竟扮演着什么角色？它又能为我们的项目带来哪些好处？这篇文章就来揭开它的神秘面纱。

简单来说，toolchain 指令用于声明构建当前模块所需的 Go 工具链版本。它是 Go 团队为了解决多版本 Go 环境共存问题而引入的重要特性。

让我们先看一个典型的 go.mod 文件示例：

你有没有遇到过这样的情况：和 AI 聊了十几轮，突然发现它"忘记"了之前说过的内容？或者 API 调用因为 Token 超限直接报错？

这是因为大模型有上下文长度限制，对话越长，历史消息越多，就越容易超限。结合我的理解，这篇文章分享一下如何实现上下文压缩，让你的 AI 应用既能"记住"关键信息，又能节省成本。

调用大模型 API 时，你有没有遇到过这些问题：某个模型突然限流、响应变慢、甚至直接挂掉？或者 不同模型价格差异大，想根据任务复杂度选择合适的模型？如果你的服务只依赖单一模型，这些问题就是单点故障。解决方案很简单：多模型 + 负载均衡。这篇就聊用 Go 实现 AI 多模型负载均衡的思路和代码。

假设你的应用只调用 OpenAI 的 GPT-4，某天 OpenAI 服务波动，你的应用就跟着「躺平」。更现实的问题是：

调用大模型 API 时，你是直接拼接字符串，还是用模板管理？如果只是简单调用，字符串拼接够用；但当 Prompt 越来越多、越来越复杂，散落在代码各处的字符串就成了维护噩梦。变量替换、多语言提示、版本化管理，这三个问题不解决，代码迟早变成「意大利面条」。这篇就聊用 Go 实现 Prompt 模板管理的实践。

假设你有一个翻译场景，最简单的写法：

做 RAG、语义检索或推荐时，要把 Embedding 向量 存起来、按相似度查，就得用向量数据库。Go 里常见的选择有三类：Pgvector（PostgreSQL 扩展）、Milvus、Qdrant。选哪个取决于你是否已有 Postgres、数据量和运维成本。这篇就聊这三者在 Go 里的客户端选型和接入要点。

• Pgvector：是 PostgreSQL 的一个扩展，向量当一列存。适合本来就用 Postgres 的团队，不想多维护一个组件，数据量在百万级以内、QPS 不是特别夸张时很够用。Go 里用 pgx + pgvector-go 即可。
• Milvus：独立向量库，支持大规模、分布式，适合向量数据量很大或要单独扩缩容的场景。官方有 milvus-sdk-go，接口偏「集合 + 列式插入 + 建索引再搜」。
• Qdrant：也是独立向量库，API 设计偏 REST/gRPC，过滤条件（payload filter）和多向量支持比较顺手。Go 用 github.com/qdrant/go-client，文档和示例都比较全。

想让大模型回答你公司内部文档的问题？直接喂文档太占 Token，而且模型会「忘记」长内容。RAG（检索增强生成） 的做法是：把文档切块、转成向量存起来，用户提问时先检索相关片段，再把片段和问题一起发给模型，让它基于这些上下文回答。实现一套 RAG 服务，核心就三步：文档切块、向量化、检索。

大模型有两个局限：上下文长度有限（不能塞太多文档）、知识有时效性（训练数据可能过时）。RAG 的做法是：

用 Go 做语义检索、推荐或 RAG 时，总要算向量相似度。做法大致三种：自己写几行、用数值库、或者交给向量数据库。下面按「方案」捋一捋，方便你按场景选。

向量相似度用在语义检索、推荐、去重聚类等场景很常见，但数据量差别很大：有时就几百几千个向量在内存里算，有时是百万级要做近似最近邻（ANN）检索。所以没有一种写法能通吃，有的场景适合手写，有的适合用库，有的直接上向量库。下面分别说。

大模型支持「工具调用」后，对话里可以查天气、查库、调 API；模型会返回该调用哪个函数、传什么参数。服务端要做的，就是解析模型返回的 tool_calls、执行对应逻辑、把结果塞回对话。用 Go 实现，结构清晰、易维护。下面说清楚解析、执行与一整轮怎么串起来。

Function Calling（Tool Use）指：你把可调用的函数列表以 JSON Schema 等形式传给大模型，模型在需要时会在回复里带 tool_calls，指明函数名和参数。服务端解析后执行真实逻辑，把结果再发给模型，由模型生成最终回答。

最近在折腾 Cursor、Claude 等 AI 编程工具的朋友，多半见过两个词：Skill 和 MCP。一个负责「教 AI 怎么做事」，一个负责「让 AI 能调用外部能力」。于是有人问：既然 Skill 越来越强，会不会有一天完全取代 MCP？

目前来看：不会。 二者解决的是不同层面的问题，更像是「左手和右手」的关系，而不是谁替代谁。

用 Go 写后端、CLI 或运维工具时，要把大模型能力接进去，第一个问题往往是：Go 里该用哪个 SDK？生态够不够用？ 和 Python/Node 相比，Go 的 AI 生态更「散」，但近几年已有不少可用方案。本文按云端大模型、MCP、本地模型、RAG 四类场景盘点主流库，并给出选型建议。

场景：调用 OpenAI、国产大模型或兼容 OpenAI 协议的 API。

首选：openai-go（github.com/openai/openai-go），OpenAI 官方维护的 Go 库，覆盖 Chat 补全、流式输出、Function Calling、Embeddings、语音与图像等能力，与官方 REST API 保持一致，后续迭代有保障。

当 AI 应用需要查数据库、调 API、读文件时，总不能把整套系统都塞进提示词里。Model Context Protocol（MCP） 就是为解决这个问题而生：它让大模型通过统一协议安全、可控地连接外部数据源和工具。如果你在用 Go 做后端或 CLI，用 Go 写 MCP 服务再合适不过——编译成单二进制、并发友好、部署简单。这篇文章就聊聊 Go 里如何快速实现一个 MCP 服务，以及目前主流的 Go MCP 框架 该怎么选。

MCP（Model Context Protocol）是一套开放标准，用来在 AI 应用和外部系统之间建立安全、可控的连接。大模型通过 MCP 可以：

• 调用工具（Tools）：执行计算、查库、发请求等
• 访问资源（Resources）：读文件、读 API 数据等
• 使用提示模板（Prompts）：复用结构化提示

在日常写 Go 的时候，你一定见过 go.sum 这个文件：每次 go get、go mod tidy 之后，它总是自动变长，里面密密麻麻地写着一行行 h1:xxxx 的“奇怪字符串”。很多同学知道它“和安全、完整性有关”，但真正问一句：go.sum 里的这个特殊哈希值到底是怎么算出来的？大多数人其实说不太清楚。

这篇文章，我们就从实战开发者视角，把 go.sum 里的特殊哈希（特别是 h1: 开头的那串值）讲清楚：它是什么、为什么需要它、底层大致怎么算，以及你如何在本地手动验证它。

先看一行典型的 go.sum 内容：

北京时间 2026 年 2 月 11 日凌晨，Go开发团队自豪地宣布Go 1.26正式发布！这一版本带来了语言语法、性能优化和开发工具等多方面的重大改进，堪称Go语言演进道路上的又一里程碑。

无论你是Go老手还是新手，这次更新都值得关注。让我们一起来看看Go 1.26都有哪些亮眼表现！

Go 1.26对语言本身进行了两项重要优化，让代码编写更加简洁优雅。

"Go语言是用什么语言写的？"这个问题看似简单，却隐藏着编程世界里的"鸡生蛋"哲学难题。想象一下：如果Go语言是用Go语言写的，那第一个Go语言编译器又是用什么写的呢？

要理解Go语言的诞生，首先要明白编译器的作用。编译器就像翻译官，把人类能看懂的代码翻译成机器语言。没有编译器，再强大的编程语言也无法运行。

但新语言诞生时，第一个编译器从哪里来？这就像教婴儿说话，婴儿还不会任何语言，你该怎么开始？

在现代Web开发领域，函数式编程思想正逐渐改变我们构建后端服务的方式。与传统的面向对象编程不同，函数式编程强调不可变性、纯函数和函数组合，能够带来更简洁、可测试性更强和更易于维护的代码。这篇文章将深入探讨如何完全采用函数式编程范式，基于Gin和GORM构建一个完整的Go Web项目。

传统的面向对象模式中，我们通常定义结构体并为其添加方法。而在函数式方法中，我们将使用纯函数和高阶函数来构建整个应用，充分利用Go语言在函数式编程方面的特性。

以下是项目目录结构：