分类 技术志 下的文章

自定义Hash终迎标准化?Go提案maphash.Hasher接口设计解读

本文永久链接 – https://tonybai.com/2025/04/17/standardize-the-hash-function

大家好,我是Tony Bai。

随着Go泛型的落地和社区对高性能自定义容器需求的增长,如何为用户自定义类型提供一套标准、安全且高效的Hash计算与相等性判断机制,成为了Go核心团队面临的重要议题。近日,经过Go核心开发者多轮深入探讨,编号为#70471 的提案”hash: standardize the hash function”最终收敛并被接受,为Go生态引入了全新的maphash.Hasher[T] 接口,旨在统一自定义类型的Hash实现方式。

这个旨在统一自定义类型Hash实现的提案令人期待,但我们首先需要理解,究竟是什么背景和痛点,促使Go社区必须着手解决自定义 Hash 的标准化问题呢?

1. 背景:为何需要标准化的Hash接口?

Go 1.18泛型发布之前,为自定义类型(尤其是非comparable类型)实现Hash往往需要开发者自行设计方案,缺乏统一标准。随着泛型的普及,开发者可以创建自定义的哈希表、集合等泛型数据结构,此时,一个标准的、能与这些泛型容器解耦的Hash和相等性判断机制变得至关重要。

更关键的是安全性。一个简单的func(T) uint64类型的Hash函数看似直观和易实现,但极易受到Hash 洪水攻击 (Hash Flooding DoS) 的威胁。

什么是Hash洪水攻击呢? 简单来说,哈希表通过Hash函数将键(Key)分散到不同的“桶”(Bucket)中,理想情况下可以实现快速的O(1)平均查找、插入和删除。但如果Hash函数的设计存在缺陷或过于简单(例如,不使用随机种子),攻击者就可以精心构造大量具有相同Hash值的不同键。当这些键被插入到同一个哈希表中时,它们会集中在少数几个甚至一个“桶”里,导致这个桶形成一个长链表。此时,对这个桶的操作(如查找或插入)性能会从O(1)急剧退化到O(n),消耗大量CPU时间。攻击者通过发送大量这样的冲突键,就能耗尽服务器资源,导致服务缓慢甚至完全不可用。

Go内建的map类型通过为每个map实例使用内部随机化的 Seed(种子)来初始化其Hash函数,使得攻击者无法预测哪些键会产生冲突,从而有效防御了此类攻击。hash/maphash包也提供了基于maphash.Seed的安全Hash计算方式。因此,任何标准化的自定义Hash接口都必须将基于Seed的随机化纳入核心设计,以避免开发者在不知情的情况下引入安全漏洞。

明确了标准化Hash接口的必要性,尤其是出于安全性的考量之后,Go核心团队又是如何一步步探索、权衡,最终从多种可能性中确定接口的设计方向的呢?其间的思考过程同样值得我们关注。

2. 设计演进:从简单函数到maphash.Hasher

围绕如何设计这个标准接口,Go 团队进行了广泛的讨论(相关issue: #69420, #69559, #70471)。

最初,开发者们提出的 func(T) uint64 由于无法有效防御 Hash 洪水攻击而被迅速否定。

随后,大家一致认为需要引入Seed,讨论的焦点则转向Seed的传递和使用方式:是作为函数参数(func(Seed, T) uint64)还是封装在接口或结构体中。对此,Ian Lance Taylor提出了Hasher[T]接口的雏形,包含Hash(T) uint64和Equal(T, T) bool方法,并通过工厂函数(如 MakeSeededHasher)来管理 Seed。 然而,这引发了关于Seed作用域(per-process vs per-table)和状态管理(stateless vs stateful)的进一步讨论。

Austin Clements 提出了多种接口变体,并深入分析了不同设计的利弊,包括API 简洁性、性能(间接调用 vs 直接调用)、类型推断的限制以及易用性(是否容易误用导致不安全)。

最终,为了更好地支持递归Hash(例如,一个结构体的Hash需要依赖其成员的Hash),讨论聚焦于将*maphash.Hash对象直接传递给Hash方法。maphash.Hash内部封装了Seed和Hash状态,能够方便地在递归调用中传递,简化了实现过程。

经历了对不同方案的深入探讨和关键决策(例如引入 *maphash.Hash),最终被接受并写入提案的maphash.Hasher[T] 接口究竟长什么样?它的核心设计理念又是什么呢?接下来,让我们来详细解读。

3. 最终方案:maphash.Hasher[T]接口

经过审慎评估和实际代码验证(见CL 657296CL 657297),Go团队最终接受了以下maphash.Hasher[T]接口定义:

package maphash

// A Hasher is a type that implements hashing and equality for type T.
//
// A Hasher must be stateless. Hence, typically, a Hasher will be an empty struct.
type Hasher[T any] interface {
    // Hash updates hash to reflect the contents of value.
    //
    // If two values are [Equal], they must also Hash the same.
    // Specifically, if Equal(a, b) is true, then Hash(h, a) and Hash(h, b)
    // must write identical streams to h.
    Hash(hash *Hash, value T) // 注意:这里的 hash 是 *maphash.Hash 类型
    Equal(a, b T) bool
}

该接口的核心设计理念可以归纳为如下几点:

  • Stateless Hasher: Hasher[T] 的实现本身应该是无状态的(通常是空结构体),所有状态(包括 Seed)都由传入的 *maphash.Hash 对象管理。
  • 安全保障: 通过强制使用maphash.Hash,确保了 Hash 计算过程与 Go 内建的、经过安全加固的Hash算法(如 runtime.memhash)保持一致,并天然集成了Seed 机制。
  • 递归友好: 在计算复杂类型的 Hash 时,可以直接将 *maphash.Hash 对象传递给成员类型的 Hasher,使得递归实现简洁高效。
  • 关注点分离: 将 Hash 计算 (Hash) 和相等性判断 (Equal) 分离,并与类型 T 本身解耦,提供了更大的灵活性(类似于 sort.Interface 的设计哲学)。

下面是一个maphash.Hasher的使用示例:

package main

import (
    "hash/maphash"
    "slices"
)

// 自定义类型
type Strings []string

// 为 Strings 类型实现 Hasher
type StringsHasher struct{} // 无状态

func (StringsHasher) Hash(mh *maphash.Hash, val Strings) {
    // 使用 maphash.Hash 的方法写入数据
    maphash.WriteComparable(mh, len(val)) // 先写入长度
    for _, s := range val {
        mh.WriteString(s)
    }
}

func (StringsHasher) Equal(a, b Strings) bool {
    return slices.Equal(a, b)
}

// 另一个包含自定义类型的结构体
type Thing struct {
    ss Strings
    i  int
}

// 为 Thing 类型实现 Hasher (递归调用 StringsHasher)
type ThingHasher struct{} // 无状态

func (ThingHasher) Hash(mh *maphash.Hash, val Thing) {
    // 调用成员类型的 Hasher
    StringsHasher{}.Hash(mh, val.ss)
    // 为基础类型写入 Hash
    maphash.WriteComparable(mh, val.i)
}

func (ThingHasher) Equal(a, b Thing) bool {
    // 优先比较简单字段
    if a.i != b.i {
        return false
    }
    // 调用成员类型的 Equal
    return StringsHasher{}.Equal(a.ss, b.ss)
}

// 假设有一个自定义的泛型 Set
type Set[T any, H Hasher[T]] struct {
    hash H // Hasher 实例 (通常是零值)
    seed maphash.Seed
    // ... 其他字段,如存储数据的 bucket ...
}

// Set 的 Get 方法示例
func (s *Set[T, H]) Has(val T) bool {
    var mh maphash.Hash
    mh.SetSeed(s.seed) // 使用 Set 实例的 Seed 初始化 maphash.Hash

    // 使用 Hasher 计算 Hash
    s.hash.Hash(&mh, val)
    hashValue := mh.Sum64()

    // ... 在 bucket 中根据 hashValue 查找 ...
    // ... 找到潜在匹配项 potentialMatch 后,使用 Hasher 的 Equal 判断 ...
    // if s.hash.Equal(val, potentialMatch) {
    //     return true
    // }
    // ...

    // 简化示例,仅展示调用
    _ = hashValue // 避免编译错误

    return false // 假设未找到
}

func main() {
    // 创建 Set 实例时,需要提供具体的类型和对应的 Hasher 类型
    var s Set[Thing, ThingHasher]
    s.seed = maphash.MakeSeed() // 初始化 Seed

    // ... 使用 s ...
    found := s.Has(Thing{ss: Strings{"a", "b"}, i: 1})
    println(found)
}

这个精心设计的 maphash.Hasher[T] 接口及其使用范例展示了其潜力和优雅之处。然而,任何技术方案在落地过程中都难免遇到挑战,这个新接口也不例外。它目前还面临哪些已知的问题,未来又有哪些值得期待的发展方向呢?

4. 挑战与展望

尽管 maphash.Hasher 接口设计优雅且解决了核心问题,但也存在一些已知挑战:

  • 编译器优化: 当前 Go 编译器(截至讨论时)在处理接口方法调用时,可能会导致传入的 *maphash.Hash 对象逃逸到堆上,影响性能。这是 Go 泛型和编译器优化(#48849)需要持续改进的地方,但核心团队认为不应因此牺牲接口设计的合理性。
  • 易用性: maphash.Hash 目前主要提供 Write, WriteString, WriteByte 以及泛型的 WriteComparable。对于其他基础类型(如各种宽度的整数、浮点数),可能需要更多便捷的 WriteXxx 方法来提升开发体验。
  • 生态整合: 未来 Go 标准库或扩展库中的泛型容器(如可能出现的 container/set 或 container/map 的变体)有望基于此接口构建,从而允许用户无缝接入自定义类型的 Hash 支持。

综合来看,尽管存在一些挑战需要克服,但maphash.Hasher[T]接口的提出无疑是Go泛型生态发展中的一个重要里程碑。现在,让我们对它的意义和影响做一个简要的总结。

5. 小结

maphash.Hasher[T]接口的接受是Go在泛型时代标准化核心机制的重要一步。它不仅为开发者提供了一种统一、安全的方式来为自定义类型实现 Hash 和相等性判断,也为 Go 生态中高性能泛型容器的发展奠定了坚实的基础。虽然还存在一些编译器优化和 API 便利性方面的挑战,但其核心设计的合理性和前瞻性预示着 Go 在类型系统和泛型支持上的持续进步。我们期待看到这个接口在未来Go版本中的落地,以及它为Go开发者带来的便利。

更多信息:

对于这个备受关注的 maphash.Hasher 接口提案,你怎么看?它是否满足了你对自定义类型 Hash 标准化的期待?或者你认为还有哪些挑战或改进空间?

非常期待在评论区看到你的真知灼见!


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}
img{512x368}
img{512x368}

著名云主机服务厂商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

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

AI新宠?解读MCP、A2A为何偏爱JSON-RPC 2.0

本文永久链接 – 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-RPCSOAP)复杂性的反思,旨在提供一种更轻量、更简洁的远程过程调用机制。其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的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商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

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats