本文永久链接 – https://tonybai.com/2025/05/13/go-prefer-less-framework

大家好，我是 Tony Bai。

Go 语言自诞生以来，就以其简洁、高效和强大的并发模型赢得了全球开发者的青睐。它的设计者们，包括 Rob Pike、Ken Thompson 这些计算机界的巨匠，在创造 Go 的时候，秉持了一种鲜明的风格：“少即是多” (Less is More)。这不仅体现在其精简的语法和关键字上，更深刻地影响了 Go 社区对于“框架” (Frameworks) 的普遍态度。

虽然 Go 官方从未明确宣称“轻框架或无框架”是其核心哲学，但从其设计选择——如强大的标准库、鼓励组合优于继承——以及社区早期的主流声音来看，Go 显著地倾向于“轻框架”，或者说“反大型、侵入式框架”。

但这种在语言层面推崇的“轻盈”与“自由”，在实际的团队协作和大型项目开发中，究竟是解放生产力的“馈赠”，还是悄然套上了一层限制效率的“无形枷锁”？今天，我们就来探讨一下 Go 社区这种独特的“轻框架”理念。

“轻框架”的初心：拥抱简洁、掌控与标准库的力量

Go 社区对“轻框架”的偏爱，并非空穴来风，而是源于对传统大型框架某些弊端的回避，以及对 Go 自身优势的充分自信：

1. 对“重框架”的反思： Go 的设计者们深谙大型框架（如 Java Spring, Ruby on Rails 等早期版本）在提供便利的同时，也可能带来学习曲线陡峭、过度设计、灵活性受限、性能开销以及难以捉摸的“魔法”等问题。Go 倾向于让开发者更接近底层，更清晰地理解代码的执行路径。
2. 强大的标准库 “自带电池”： 这是 Go “轻框架”理念的底气所在。Go 标准库异常强大且全面，覆盖了网络、HTTP、JSON/XML 处理、加密、并发原语、测试等核心功能。许多在其他语言中需要依赖框架才能便捷实现的功能，Go 标准库直接提供，鼓励开发者首先“向内求”。
3. 组合优于继承，接口驱动设计： Go 语言本身的设计哲学鼓励通过组合小而专注的组件来构建复杂的系统，并通过接口实现解耦和多态。这种范式使得代码更易于理解、测试和维护，自然降低了对庞大、层级复杂的框架的需求。
4. 赋予开发者掌控权： “轻框架”意味着更少的隐藏逻辑和约定。开发者对代码的执行流程有更强的掌控感，这对于构建高性能、高可靠性的系统至关重要。
5. 鼓励针对性解决方案： Go 社区倾向于针对特定问题选择或构建小而美的库，而不是试图用一个“万能框架”解决所有问题。这促进了 Go 生态中大量高质量、专注的第三方库的涌现。

这种“轻框架”理念带来的益处显而易见：

• 学习曲线相对平缓： 开发者可以更快地掌握语言核心和标准库，而不必先学习一个庞大的框架体系。
• 高度灵活性： 开发者可以根据项目具体需求自由选择技术栈、架构模式和第三方库，不受框架的强约束。
• 性能透明且可控： 避免了大型框架可能引入的未知性能开销。
• 社区库的“专而精”： 催生了大量专注于解决特定问题的优秀第三方库，开发者可以像搭积木一样按需选用和组合。

对于许多追求极致性能、需要高度定制化、或者开发者经验丰富的场景，Go 的这种“轻框架”倾向无疑是一种解放。

当“轻盈”遭遇“团队”：浮现的挑战与“结构缺失”感

然而，当我们将视角从个体开发者的“自由创作”转向需要多人协作、长期维护的大型复杂系统时，Go 社区这种“轻框架”的理念，有时却可能带来新的挑战，让团队感受到一种“结构缺失”的困扰，甚至演变成效率瓶颈：

• 缺乏共享约定，导致“决策疲劳”与“风格各异”：

  • 项目结构“百花齐放”： 由于缺乏官方或广泛接受的项目布局“最佳实践”，不同团队甚至同一团队的不同项目都可能采用迥异的目录结构和代码组织方式。这无疑增加了新成员的上手门槛，也使得在项目间复用经验和代码变得困难。
  • 技术选型无尽的“圣战”： 路由用 Gin、Echo 还是 Chi？日志库选 Zap、Logrus 还是标准库 log 加封装？配置管理、数据库迁移、RPC 框架……由于缺乏“一锤定音”的框架推荐，团队常常需要在这些基础组件的选择、集成、封装和推广上耗费大量精力，进行无休止的调研、讨论甚至内部“站队”。
  • “重复发明轮子”的诱惑： 因为没有现成的、整合好的框架提供“全家桶”服务，团队在面对常见需求（如用户认证、权限管理、任务队列）时，更容易倾向于“自己动手，丰衣足食”，这可能导致大量功能相似但实现各异的内部“准轮子”，长期维护成本高昂。

• 基础设施与横切关注点的“重复建设”：

  • “胶水代码”与“基础设施代码”泛滥： 服务间的API调用、错误处理、链路追踪、监控埋点、配置加载、密钥管理等横切关注点，在缺乏统一框架抽象的情况下，往往需要在每个服务或模块中重复实现或集成，导致大量相似的“胶水代码”和“基础设施代码”。
  • DevOps 实践难以标准化： Dockerfile 的编写、CI/CD 流水线的配置、服务部署脚本等，如果每个项目都“各自为政”，难以形成统一、高效的 DevOps 实践，也增加了运维的复杂性。

• 团队协作与项目传承的隐形成本：

  • “雪花服务”林立，知识孤岛化： 每个服务都可能因为开发者的不同偏好和技术选型，演变成一个拥有独特“方言”和“习俗”的“小王国”。这使得代码复用、知识共享、人员在项目间的流动都变得更加困难。
  • 维护与交接的“噩梦”： 当一个高度定制化、缺乏统一规范的“轻框架”项目（甚至可以说是“无刻意设计的框架”）交到新人手中，或者核心开发者离职后，其理解难度和维护成本可能会急剧上升。
  • 团队规模扩大后的困境： 随着团队成员增多、项目复杂度上升，缺乏统一框架带来的沟通成本、集成成本和质量控制难度会指数级增长。

对于追求快速迭代、需要保持高度一致性、或者团队成员经验水平参差不齐的团队来说，Go 这种“过度自由”的“轻框架”理念，有时反而会成为一种负担。开发者可能会怀念在 Rails、Django 或 Spring Boot 这类成熟框架中那种“约定优于配置”、开箱即用的便利感。

实践中的平衡：在“轻盈”与“结构”间寻找智慧

面对 Go 社区“轻框架”的理念，以及它在团队协作中可能带来的挑战，我们并非束手无策。关键在于如何在享受其“轻盈”与“自由”的同时，有意识地为团队引入必要的“结构”与“秩序”：

• 建立团队内部的“强约定”与“最佳实践指南”：
  • 这是最核心的应对策略。即使 Go 官方不提供，团队内部也必须投入精力沉淀和推广一套自己的项目模板、代码规范（如 Uber Go Style Guide）、推荐库列表（形成内部“技术雷达”）、以及针对常见场景的架构模式和解决方案。
  • 通过严格的 Code Review、定期的技术分享、完善的内部文档，确保这些“内部标准”得到遵守和持续迭代。
• 拥抱“轻框架/微框架”和高质量的第三方库，形成“技术栈共识”：
  • Go 社区有大量优秀的、专注于解决特定问题的库（如 Gin/Echo 用于 Web 开发，GORM/sqlx 用于数据库交互，Zap/Logrus 用于日志等）。团队应在充分调研的基础上，选择并标准化一套适合自己的“技术全家桶”，并围绕它们构建开发模式，避免成员随意引入未经评估的库。
• 善用代码生成、脚手架与项目模板：
  • 针对常见的样板代码（如 API 接口定义、CRUD 操作、项目初始化），可以开发或引入代码生成工具（如 go-swagger, protoc-gen-go 等）和标准化的项目脚手架，提高开发效率，保证代码风格和结构的一致性。
• 强化架构设计能力，明确模块化与接口：
  • 在项目初期投入足够的时间进行良好的架构设计，明确服务边界、模块职责、数据模型和接口定义。清晰的架构是应对复杂性的基石，其重要性在“轻框架”环境下尤为突出。
  • 即使没有框架的强制约束，也要通过清晰的模块化和精心设计的接口来降低耦合，提高代码的可测试性和可维护性。
• 投资于平台工程与 DevOps 工具链：
  • 将基础设施的配置、部署、监控、日志收集等工作尽可能平台化、自动化，减少手动操作和人为错误。
  • 构建统一的 CI/CD 流水线，提供标准化的 Docker 镜像基础，推广基础设施即代码 (IaC) 的理念。
• 审慎评估并引入“有观点”的 Go 开发平台或框架 (如果真正适合)：
  • 近年来，Go 社区也开始涌现一些试图提供更完整解决方案、更具“观点”的开发平台或集成度更高的框架。它们可能内置了项目结构、服务发现、API 定义、部署等方面的约定。如果团队的痛点与这些工具试图解决的问题高度匹配，并且其引入成本和学习曲线可接受，可以考虑审慎评估和引入，它们或许能在 Go 的自由与团队所需的结构之间提供一种新的平衡点。

结语：自由的艺术在于自律与智慧的构建

Go 社区的“轻框架”理念，本质上是将设计的权力和责任更多地交还给了开发者和团队。这既是一种极大的自由，让我们能够摆脱不必要的束缚，打造出极致性能和高度定制化的系统；同时，它也是一种严峻的考验，要求我们具备更高的技术素养、更强的架构能力和更严格的团队自律。

• 对于经验丰富、纪律性强、且有能力驾驭这种自由的团队或个人，它可以释放出巨大的创造力和效率。
• 但对于缺乏经验、规范不足、或追求快速标准化的团队，这种“轻盈”也可能导致“结构缺失”的混乱和低效。

最终，Go 的“轻框架”理念是馈赠还是枷锁，并不取决于理念本身，而取决于使用它的人和团队如何理解这种理念，并有意识地、智慧地去构建适合自己的“秩序”与“结构”。在 Go 的世界里，真正的自由，或许并非随心所欲，而是通过团队的共同智慧和高度自律，构建起一套虽“轻”却不失章法的“隐形框架”，从而在享受简洁与高效的同时，也能保障项目的稳健、协作的顺畅与长远的发展。

你和你的团队在 Go 项目中是如何平衡自由与结构的？你们是否也曾感受到“轻框架”或“结构缺失”带来的困扰，又是如何解决的？欢迎在评论区分享你的宝贵经验和思考！

精进有道，更上层楼！

如果你已经掌握了 Go 语言的基础，渴望在语法强化、代码设计以及工程实践等方面获得更深层次的提升，那么我最新上架的Go语言进阶课程正是为你准备的！这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”。

扫描下方二维码，立即解锁你的 Go 语言进阶之路！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/04/16/ai-protocol-prefer-jsonrpc

大家好，我是Tony Bai。

在AI技术飞速演进的今天，底层通信协议的选择对系统效率和互操作性至关重要。细心的开发者可能已经发现，新兴的AI协议如模型上下文协议（MCP）和Agent2Agent（A2A）协议，都不约而同地将目光投向了JSON-RPC 2.0。这并非巧合，而是一个深思熟虑的技术选型。在这篇文章中，我将和大家一起看看JSON-RPC 2.0的起源、核心规范以及历史应用，并解读这个10多年前定义的“老协议”为何能在AI时代能再次获得青睐。

1. JSON-RPC 2.0：起源与核心规范

JSON-RPC协议的诞生，源于对早期RPC协议（如XML-RPC、SOAP）复杂性的反思，旨在提供一种更轻量、更简洁的远程过程调用机制。其2.0版本规范（基于2009年草案，正式发布于2010年左右）更是将这一理念发扬光大。其核心设计哲学正如规范开篇所言：“It is designed to be simple!”

很多开发者日常都是用过JSON-RPC 2.0，但可能没有对其规范做过深入的了解，借此篇文章机会，让我们依据其官方规范，深入了解其关键特性。。

1.1 核心原则

我们先来看一下JSON-RPC协议设计的几个核心原则。

• Stateless (无状态): 每次请求都是独立的，服务器不保存客户端状态。
• Light-weight (轻量级): 协议开销小，消息体紧凑。
• JSON Data Format (JSON数据格式): 使用广泛流行、易于解析和人类可读的JSON(RFC 4627) 作为数据交换格式。
• Transport Agnostic (传输无关): 协议本身不限定网络传输方式，可在HTTP、WebSocket、TCP、甚至进程内等多种环境使用。

接下来，我们再来看一下工作原理。JSON-RPC 2.0是一个相对简单的协议，其规范也就几页，因此其工作原理也非常好理解。

1.2 工作原理

JSON-RPC 的工作原理是向实现此协议的服务器发送请求。在这种情况下，客户端通常是打算调用远程系统的单个方法的软件。多个输入参数可以作为数组或对象传递给远程方法，而方法本身也可以返回多个输出数据（这取决于实现的版本。）

下面是对协议中的一些核心对象的解读。

1.2.1 Request Object (请求对象)

Request Object是发起RPC调用的核心，由客户端发送请求到服务端。我们结合一个示例来理解请求对象的各个字段的含义：

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4}
<-- {"jsonrpc": "2.0", "result": 19, "id": 4}

• jsonrpc: 必须是”2.0″，这是区分版本的关键标识。
• method: 是一个字符串类型的必选字段，表示要调用的方法名。以rpc.开头的为保留方法。
• params: 是一个可选参数，它是一个结构化值Array或Object，包含调用方法所需的参数。

JSON-RPC支持两种传递params的方式，一种是By-name(按名称)，即params是一个对象，其成员名与服务器期望参数名匹配，比如上面示例中params使用的就是一个by-name的参数传递方式。另外一种是By-position (按位置)，即params是一个数组，值按服务器期望顺序排列。比如上面示例中params等价为下面按位置传递方式的params：

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}

• id: 是一个字符串或数字类型的值，用于关联请求和响应。比如上面示例中，请求的id=4，其对应的响应(Response)的id也应该为4才能匹配成功。

1.2.2 Response Object (响应对象)

上面的示例中的第二行其实是一个Repsonse Object，即服务器针对有效请求（非通知类）的回复：

<-- {"jsonrpc": "2.0", "result": 19, "id": 4}

• jsonrpc: 必须是”2.0″，这是区分版本的关键标识。
• result: 包含方法调用的成功结果。如果rpc调用失败，那么响应中不有result字段，可以说与下面的error是二取一的。
• error: 包含一个Error Object。如果rpc调用没有错误发生，响应体中不应该存在error字段。
• id: 与对应请求对象中的id一致。如果检测请求id出错(比如解析出错或非法请求)，则应为Null，比如下面这个示例：

下面是返回错误码的示例：

--> {"jsonrpc": "2.0", "method": 1, "params": "bar"} // method值不是字符串，不是一个合法的请求对象
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}

再强调一下：result 和 error 成员互斥，必须存在其一。

1.2.3 Error Object (错误对象)

错误对象用于描述发生的错误，对象有三个字段：

• code: 错误码，类型为整数，指示错误类型。-32768到-32000 为预定义错误码范围。下面是一些典型错误code：
  • -32700: Parse error
  • -32600: Invalid Request
  • -32601: Method not found
  • -32602: Invalid params
  • -32603: Internal error
  • -32000 to -32099: Server error
• message: 错误信息，字符串类型，用于简短描述错误。
• data: 可选，代表原始值或结构化值，包含额外错误信息。

下面是一个错误对象示例：

--> {"jsonrpc": "2.0", "method": "foobar", "id": "1"}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "1"}

1.2.4 Notification通知

Notification通知一种特殊的Request，它没有id成员。表示客户端不关心响应，服务器也不用回复，适用于无需确认的操作。比如下面这个示例：

--> {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5]}

也就是说当一个合法的Request中没有id，则可以认为是Notification通知。

1.2.5 Batch批量调用

Batch批量调用是指客户端可能发送一个包含多个Request对象的数组，以实现批量处理。服务器应该返回一个包含对应Response对象的数组（通知除外）。请求处理和响应返回可以是无序的，客户端通过id匹配。下面是一个批量调用的示例：

--> [
        {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
        {"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
        {"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
        {"foo": "boo"},
        {"jsonrpc": "2.0", "method": "foo.get", "params": {"name": "myself"}, "id": "5"},
        {"jsonrpc": "2.0", "method": "get_data", "id": "9"}
    ]
<-- [
        {"jsonrpc": "2.0", "result": 7, "id": "1"},
        {"jsonrpc": "2.0", "result": 19, "id": "2"},
        {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
        {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "5"},
        {"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
    ]

2. JSON-RPC的“前世今生”：应用场景

自诞生以来，JSON-RPC凭借其简洁、轻量、易于实现和跨语言的特性，在多个领域得到了广泛应用，满足了开发者对“高效”通信的需求：

• Web APIs: 作为RESTful API的一种替代或补充，尤其是在需要明确“过程调用”语义的场景。
• 微服务架构: 服务间的内部通信，特别是在追求低延迟、简单交互的场景下，比HTTP REST更轻量。
• 消息队列(Message Queues): 作为消息体格式，在基于消息队列的异步任务处理系统中定义任务和传递结果。
• 桌面应用与Web端交互: 例如，本地应用通过WebSocket与网页前端进行双向通信。
• 物联网(IoT): 资源受限设备间的通信，其轻量特性非常适合。
• 区块链节点通信: 一些区块链项目使用JSON-RPC作为节点间或客户端与节点间交互的标准接口。

这些应用场景充分证明了JSON-RPC作为一种基础通信协议的普适性和生命力。

3. 为何AI时代再次垂青？MCP/A2A 的选择逻辑

MCP和A2A是AI领域新兴的协议，旨在为日益复杂的AI系统（如多模型协作、Agent智能体交互）提供标准化的通信框架，解决互操作性问题。 那么，JSON-RPC 2.0究竟凭借哪些优势，在众多协议中脱颖而出，被MCP、A2A等选中呢？下面我们就来看看JSON-RPC的优势。

• 极致简洁，降低开发与理解成本

JSON-RPC 2.0 使用人类可读的 JSON 格式。其规范非常简单，定义清晰，无论是开发者学习、实现客户端/服务端，还是调试网络通信，成本都相对较低。这在需要快速迭代和广泛协作的AI领域尤为重要。

• 跨语言跨平台，适应AI生态多样性

AI的开发涉及Python、Java、Go、Rust等多种语言和框架。JSON-RPC的简洁性和文本基础使其极易在不同语言和平台间实现互操作，为构建异构AI系统提供了基础通信能力，某种程度上提供了通信层面的“一站式解决方案”的可能性。

• 传输协议无关，提供高度灵活性

JSON-RPC 2.0本身不绑定具体的网络传输协议。它可以承载于HTTP(S)、WebSocket、TCP、消息队列等多种传输层之上。这种灵活性使得它可以适应不同的部署环境和通信需求，无论是需要低延迟长连接的Agent交互，还是简单的模型服务调用。

• 成熟稳定，生态工具丰富

作为一个存在已久的协议，JSON-RPC 2.0拥有大量成熟的库和工具支持，覆盖了几乎所有主流编程语言。这意味着开发者可以快速集成，将更多精力投入到核心的AI逻辑开发上，而不是在基础通信协议上“重复造轮子”，符合用户“要更高效”的心理。比如：golang.org/x/exp/jsonrpc2就是Go team维护的一个高质量JSON-RPC 2.0的实现。

• 清晰的请求-响应模式，契合常见AI服务调用

JSON-RPC明确的请求（方法名、参数）和响应（结果、错误）结构，非常适合表示AI服务中的函数调用、查询等交互模式，使得接口定义和理解更加直观，有助于提升开发和沟通效率。

• 易于扩展

JSON-RPC协议本身简洁，但params和data字段提供了足够的扩展空间来承载复杂的AI特定数据结构。

以上JSON-RPC协议的核心特点与AI时代需求的高度契合。

4. 小结：大道至简，务实之选

综上所述，JSON-RPC 2.0并非昙花一现的“新宠”，而是凭借其诞生之初的简洁设计、久经考验的稳定性、广泛的跨平台能力以及与当前AI通信需求的天然契合，在AI时代焕发了新的生机。MCP、A2A等协议选择它，正是看中了其作为通信基石的扎实、高效和务实。

对于JSON-RPC在AI领域的应用，以及未来可能出现的更优协议，你有何看法？欢迎在评论区分享你的真知灼见！

关注我，持续获取有深度的AI与技术解析。

Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Gopher的AI原生应用开发第一课”、“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。