标签 接口 下的文章

自定义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

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

Go testing包将迎来新增强:标准化属性与持久化构件API即将落地

本文永久链接 – https://tonybai.com/2025/04/07/go-testing-add-attr-and-artifactdir

Go语言的testing包即将迎来两项备受期待的增强功能:标准化的测试属性(Test Attributes)和测试构件(Test Artifacts)管理。这两项提案(#43936 和#71287)均已获得Go团队的批准或高度认可,旨在显著提升Go测试的可观测性、调试效率以及与外部工具链(如CI/CD系统、测试管理平台)的集成能力。本文将深入解读这两项提案的设计理念、核心API、应用场景及其对Go开发者的潜在影响。

1. Go测试过程中的“痛点”

长期以来,Go开发者在处理测试过程中的元数据和输出文件时,常常面临一些挑战,不得不依赖非标准的约定或变通方法,这直接影响了测试效率和工具集成的流畅性。

1.1 痛点一:脆弱且混乱的测试元数据传递

现代开发流程中,我们常常需要将测试与外部系统关联起来。例如,将自动化测试结果上报给TestRailAllure这样的测试管理平台,或者在CI/CD报告中直接链接到相关的Jira问题、代码提交或详细日志。

在t.Attr提案(#43936)出现之前,开发者通常只能通过t.Log或t.Logf输出特定格式的字符串来实现这一目标,例如类似以下的日志行:

// 示例:试图通过日志传递元数据
TESTRAIL_CASE_ID: C12345
JIRA_ISSUE: PROJ-789

这种方法的弊端显而易见:

  • 极其脆弱: 任何对日志格式、前缀或分隔符的微小改动,都可能导致依赖这些日志的外部解析工具(如CI脚本、报告生成器)失效。
  • 缺乏标准: 每个项目或团队可能会发明自己的格式,导致工具难以复用和维护。
  • 信息混杂: 重要的元数据与普通的测试日志信息混合在一起,增加了提取难度和误判的可能性。
  • 工具集成困难: 像go test -json这样的官方工具,其输出的Action: output 事件并不区分普通日志和这种“伪装”的元数据,下游消费者需要进行额外的、不可靠的字符串解析。

总之,这种方式给需要自动化处理测试结果的场景带来了持续的维护负担和不确定性。

当然痛点不限于此,我们再来看一个。

1.2 痛点二:转瞬即逝的测试构件,调试与归档的障碍

Go testing包提供了t.TempDir函数,用于创建测试期间使用的临时目录和文件,这在隔离测试状态方面非常有用。然而,t.TempDir的核心特性——在测试(无论成功或失败)结束后自动清理其内容——在某些场景下反而成了阻碍。想象以下常见情况:

  • 调试失败

一个复杂的集成测试失败了。测试过程中可能生成了详细的调试日志、服务间通信的网络抓包、或者是对比失败的实际输出文件。当你想检查这些文件以定位问题时,却发现它们随着测试的结束一同消失了。开发者不得不采取临时措施,比如注释掉t.Cleanup调用,或者在测试失败路径上手动复制文件到其他位置,过程繁琐且容易遗漏。

  • CI结果归档

在CI/CD流水线中,我们通常希望在测试失败时自动收集相关的诊断信息(如core dump、截图、性能剖析文件等)作为“构件(artifact)”进行归档,以便后续分析。虽然Go提供了-cpuprofile, -memprofile等标志并将结果放入-outputdir指定的目录,但对于测试代码自身产生的其他类型构件,缺乏一个统一且可靠的机制来指示它们需要被保留。

为了解决上述这些长期存在的痛点,Go社区积极讨论并推进了t.Attr和t.ArtifactDir这两项关键提案,旨在通过标准化的API为go testing包带来现代化的测试信息管理能力。

下面我们就来正式看看这两个提案究竟给我们带来了哪些测试过程中的便利。先来看看t.Attr提案。

2. t.Attr:为测试附加结构化元数据(#43936)

状态:已接受 (Accepted)

提案#43936旨在提供一种标准化的方式,将结构化的键值对元数据与特定的测试(或子测试)关联起来,并使其在go test -json的输出中易于访问。

2.1 核心API

该提案在testing.TB接口中增加了Attr方法,其定义如下:

package testing

type TB interface {
    // ... 其他方法

    // Attr 发出与此测试关联的测试属性。
    //
    // key不能包含空白字符。
    // 不同属性键的含义由持续集成系统和测试框架决定。
    //
    // 测试属性会立即在测试日志中发出,但应被视为无序的。
    Attr(key, value string)
}

开发者可以在测试代码中调用t.Attr(“myKey”, “myValue”)来记录元数据。经过社区的深入讨论,API最终确定为接受string类型的键和值。这主要是字符串简洁,易于理解和使用;与现有的主流测试管理系统(如 JUnit XML、Google 内部的 Sponge 系统)对属性/特性的定义(通常是string-string)保持一致。同时,还避免testing包引入对encoding/json的依赖。如果需要传递复杂结构,开发者可以自行将值JSON编码为字符串。

2.2 输出格式

t.Attr的调用会在标准测试日志中产生如下格式的输出:

=== ATTR  TestName <key> <value>

当使用go test -json运行时,test2json工具会将其转换为结构化的JSON事件:

{"Time": "...", "Action": "attr", "Package": "package/path", "Test": "TestName", "Key": "key", "Value": "value"}

go testing包增加了Attr后,在测试管理中,集成Go测试与系统如TestRail和Allure变得更加轻松,通过t.Attr可传递测试用例ID、特性标签和故事标签等信息。此外,测试输出中可以嵌入指向外部资源的链接,如日志系统、问题跟踪器(如Jira)、构建产物和文档。这种方式增强了CI/CD流程,使CI系统能够解析这些属性,以便于测试结果的分类、过滤和报告生成,或触发特定工作流,例如通过t.Attr(“environment”, “staging”)标记测试运行环境或关联代码提交哈希。最终,这种标准化的方法告别了脆弱的日志解析,提供了一种可靠的方式来提取测试元数据,取代了过去依赖特定日志前缀或格式的做法。

接下来,我们再来看看另外一个增强项:t.ArtifactDir。

3. t.ArtifactDir:持久化测试构件(#71287)

状态:很可能接受(Likely Accept)

提案#71287针对的是测试过程中产生的、可能需要后续检查的文件(即“测试构件(Artifact)”),它提供了一种机制,让开发者可以选择性地保留这些文件,而不是让它们被t.TempDir这种“阅后即焚”的特性自动删除。

3.1 核心API与标志

该提案在testing.TB接口中增加了ArtifactDir方法,其定义如下:

package testing

type TB interface {
    // ... 其他方法

    // ArtifactDir 返回一个目录供测试存储输出文件。
    // 当提供了 -artifacts 标志时,此目录将位于输出目录下。
    // 否则,ArtifactDir 返回一个临时目录,该目录在测试完成后被移除。
    //
    // 每个测试或子测试(在每个测试包内)都有一个唯一的构件目录。
    // 在同一测试或子测试中重复调用 ArtifactDir 返回相同的目录。
    // 子测试的输出不位于父测试的输出目录下。
    ArtifactDir() string
}

与此API配套的是一个新的go test命令行标志:-artifacts。它的行为特点如下:

  • 默认行为 (未指定-artifacts)

在这种情况下,t.ArtifactDir()的行为类似于t.TempDir(),返回一个临时目录,测试结束后其内容会被清理。这确保了测试行为的一致性,无论是否需要持久化构件。

  • 启用持久化 (指定-artifacts)

t.ArtifactDir()将返回一个位于-outputdir(默认为当前工作目录)下的特定目录,该目录及其内容在测试结束后不会被删除。

3.2 目录结构与输出

为了确保唯一性,尤其是在运行多个包(例如使用“./…”)或使用-count=N时,构件目录的路径结构经过了仔细考虑。最终采用的结构类似:

<outputdir>/<package_path>/<test_name>/<random_or_counter>

具体的路径转换和命名规则会进行必要的处理(如路径安全化、截断长名称等),但核心目标是提供一个可预测且唯一的存储位置。

当启用构件存储且测试首次调用ArtifactDir() 时,会输出类似信息:

=== ARTIFACTS TestName/subtest_name /path/to/actual/artifact/dir

在go test -json模式下,对应事件为:

{"Time":"...", "Action":"artifacts", "Package":"package/path", "Test":"TestName/subtest_name", "Path":"/path/to/actual/artifact/dir"}

其中Path字段包含了实际的构件目录路径。

综上,有了t.ArtifactDir()后,在调试失败的测试时,用户可以轻松检查测试生成的实际输出文件、对比文件、日志、核心 dump、网络抓包和性能剖析数据,而无需修改测试代码以阻止临时目录清理。此外,CI系统可以通过设置-artifacts和-outputdir标志,自动收集所有测试产生的构件,并将其存档或用于后续分析。在测试代码生成时,生成的代码可以输出到t.ArtifactDir()返回的目录,方便在验证失败时与预期的黄金文件进行对比。这种方法提供了一种官方推荐的方式来处理测试产物,减少了各个项目自行实现此类机制的需求。

4. 协同效应:属性与构件的强强联合

t.Attr和t.ArtifactDir这两个提案并非孤立存在,它们可以协同工作,提供更强大的测试信息管理能力。

最典型的场景是:使用t.ArtifactDir管理构件文件的存储,并使用t.Attr记录指向这些构件的元数据。

例如,一个测试可能会:

  • 调用dir := t.ArtifactDir()获取构件目录。
  • 在该目录中生成一个重要的日志文件,假设名为trace.log。
  • 调用t.Attr(“trace_log_path”, filepath.Join(dir, “trace.log”))来记录这个日志文件的确切路径。
  • 或者,如果CI系统会将构件上传到对象存储,测试可以记录其访问URL:t.Attr(“trace_log_url”, “s3://bucket/…”)。

这样,外部工具不仅知道测试产生了构件(通过Action: artifacts事件),还能通过解析Action: attr事件找到访问或描述这些构件的具体信息,实现了端到端的关联。

5. 小结

t.Attr和t.ArtifactDir的引入,标志着Go标准测试库在满足现代软件开发流程需求方面迈出了重要一步。它们通过提供标准化的API和工具链支持,极大地增强了测试的透明度、可调试性以及与自动化系统的集成深度。

随着这两个提案的落地(预计在未来的Go版本中),我们期待看到Go社区能够更轻松地构建健壮、可观测的测试体系,并与各种先进的开发运维工具无缝集成。这无疑将进一步巩固Go在构建可靠、高效软件系统方面的优势。开发者应密切关注这些新特性,并考虑如何在自己的项目中利用它们来改进测试实践。

6. 参考资料


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