Golang on elonnzhang

Agent Development Kit (ADK) · 13 - Session Vertex AI

Wed, 23 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Vertex AI Session：远端后端怎样保持 Session 契约

源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。以下“当前实现”均指此版本。

返回 ADK 源码阅读合集 · 前置阅读：Session、Event 与 State、InMemory、Database · 配套阅读：Runner、Server。

session.Service 是 Runner 依赖的抽象，但不同后端并不提供相同的性能和事务语义。InMemory 把对象放在进程内，Database 把对象编码进本地数据库；session/vertexai 则把 Session、Event 和 State 映射到 Vertex AI Agent Engine 的 RPC。

这篇文章只追踪这个适配层，不把 Agent Engine 当成另一个 Runner。Runner 仍然负责 invocation 和事件消费，Vertex AI service 负责远端 Session 的创建、读取、列举、删除及追加。

一、源码入口与阅读地图

入口	源码	要回答的问题
构造	`session/vertexai/vertexai.go#L34-L56`	Project、Location、ReasoningEngine 怎样变成 Service？
Service	`vertexai.go#L58-L155`	五个公开操作如何委托远端 client？
本地句柄	`session.go#L29-L91`	远端 Session 返回后，Runner 持有的对象保存什么？
State	`session.go#L116-L154`	State 的读写是否需要再次 RPC？
RPC 映射	`vertexai_client.go#L69-L110`	Create 如何映射 Agent Engine resource？
Get 并发	`vertexai.go#L69-L114`	Session 元数据和 Events 如何同时读取？

runner.Run
 │ session.Service
 ▼
vertexAiService
 ├─ vertexAiClient.Get/Create/List/Delete
 ├─ Vertex AI Agent Engine RPC
 └─ localSession（本地句柄与快照）
 ├─ State() → 本地 map + mutex
 └─ Events() → 本地切片快照

二、接口与数据：远端资源加本地句柄

1. 配置中的 AppName 不是 Reasoning Engine ID

VertexAIServiceConfig 要求 ProjectID、Location 和 ReasoningEngine。创建 Session 时，client 会根据 req.AppName 解析对应的 Agent Engine resource，再把 req.UserID、初始 State 和可选 SessionID 转成 CreateSessionRequest（vertexai_client.go#L69-L105）。因此一个 service 可以服务多个 app，但每个 app 必须能解析到自己的 reasoning engine。

Agent Development Kit (ADK) · 20 - Auth、Telemetry 与 Platform

Wed, 23 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Auth、Telemetry 与 Platform：横切能力怎样进入一次运行

源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。本文的“当前实现”均指这个版本。

返回 ADK 源码阅读合集 · 配套阅读：Runner、Context、Plugin、Server。

ADK 的主链文章通常从 Runner 开始：取得 Session，运行 Agent，保存 Event。但真实应用还要解决三类横切问题：工具访问外部服务时用谁的凭据，运行过程怎样被观测，以及事件里的时间戳和 ID 怎样在测试中变得可控。

这三件事分别落在 auth、telemetry 和 platform 包。它们都不负责调用模型，也不拥有 Session；它们通过接口和 context.Context 进入调用树，把能力交给真正的请求、事件或服务。

凭据和测试 provider 都沿着 context 或对象边界传递。因此“配置了 ADC”不等于每个 HTTP 请求都会自动带 token，“初始化了 Telemetry”也不等于已经注册成全局 provider。

阅读前先分清三个层次

层次	负责什么	不负责什么
`auth.CredentialProvider`	在一次请求上下文中解析可用凭据	不发送 HTTP 请求
`auth.Credential`	把已解析凭据写入 HTTP headers	不决定何时刷新或重试
`auth.Transport`	每次 `RoundTrip` 解析并应用凭据	不替调用方管理用户授权
`telemetry.Providers`	持有 OTel tracer/logger provider，注册和关闭	不自动创建业务 span
`platform` provider	为当前 context 提供时间、UUID 和任务调度策略	不改变包级默认行为

一、源码入口与阅读地图

阅读顺序	源码	要回答的问题
1	`auth/credential.go#L25-L120`	一个凭据怎样写到请求头？
2	`auth/providers.go#L29-L178`	Static token、ADC、Service Account 的解析边界是什么？
3	`auth/transport.go#L22-L75`	provider 何时被调用，Request 是否会被原地修改？
4	`telemetry/telemetry.go#L28-L119`	OTel provider 怎样创建、注册和关闭？
5	`telemetry/config.go#L55-L136`	Cloud 导出和自定义 processor 怎样组合？
6	`platform/time.go#L22-L50`、`uuid.go#L23-L52`	时间和 ID 的 provider 如何只影响当前调用树？
7	`platform/exec.go#L22-L94`	模型工具并发怎样替换为宿主自己的 TaskRunner？
8	`auth/gcp/client.go#L203-L370`	Agent Identity / IAM Connector 的 transport client 如何轮询和映射凭据？

agent.Context / request.Context
 │
 ├── auth.Transport.RoundTrip
 │ ├─ CredentialProvider.Credential
 │ ├─ Credential.Apply
 │ └─ Base.RoundTrip
 │
 ├── session.NewEvent / other ADK code
 │ ├─ platform.Now(ctx)
 │ └─ platform.NewUUID(ctx)
 │
 └── telemetry.New → Providers.SetGlobalOtelProviders
 └─ Providers.Shutdown

二、核心接口与数据

1. Provider、Credential、Transport 是三次分工

CredentialProvider 只返回一个实现 Apply(http.Header) 的 Credential。例如 BearerCredential 设置 Authorization: Bearer ...，APIKeyCredential 设置调用方指定的 header；OAuth2Credential 则在每次 Apply 时从 TokenSource 取得 token（credential.go#L47-L95）。

Agent Development Kit (ADK) · 06 - Runner

Mon, 21 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Runner：一次输入的执行、持久化与恢复

源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。本文的“当前实现”均指这个版本。

范围：普通 Run 的两条执行路径、消息与 Plugin、HITL、Live 和 Context Compaction。模型与工具内部循环见 Flow，数据库内部存储见 Session 配套文章。

返回 ADK 源码阅读合集 · 配套阅读：Agent、Flow、Context、Plugin、Workflow、Session Event。

用户问“杭州天气怎么样”，Agent 可以调用工具并产出答案，但应用还需要决定：这条输入属于哪个会话、由哪个 Agent 接着回答、工具结果何时保存、用户确认回来后从哪里继续，以及前端断开后还执行哪些收尾。

Runner 把输入、运行环境、事件持久化和恢复入口接成一条调用链。 它不直接实现模型推理，却决定 Agent 产生的记录怎样进入 Session、怎样经过 Plugin、怎样交到调用方。

本文回答三个问题：

Runner 为一次输入创建哪些对象，它们被谁读取和修改？
用户消息、模型 FunctionCall、工具结果、最终答案如何按序保存并流出？
错误、提前停止、长任务恢复、Live 和压缩分别改变哪一段协议？

阅读前先分清这些词

术语	本文中的含义	易混淆之处
Runner	长期持有 root Agent、服务、Plugin 和配置的运行器	不是每次模型调用都新建
Session	App + User + SessionID 关联的历史与状态	一个 Session 可以有多次 invocation
Invocation	一次执行关联的逻辑 ID	暂停和恢复可能共用 ID
普通 Run	返回一个迭代函数，range 时才执行	非 LLM root 与 LLM root 内部路径不同
Node runtime	LLM root 的合成 workflow / 节点运行路径	不代表所有 root 都进入它
Partial	流式过程中尚未形成完整记录的响应	final 判断和 partial 标志不是同一件事
AppendEvent	服务收到一条待记录事件	不等于跨工具、artifact、数据库的原子事务

贯穿示例

主线使用 AppName=weather_app、userID=user-1、sessionID=session-1，root 为 chat 模式 weather_agent。输入是“杭州天气怎么样”，模型先请求 get_weather(city="Hangzhou")，工具返回 temperature=26，第二次模型调用生成中文回答。

Agent Development Kit (ADK) · 01 - Overview

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Overview：从一次请求看懂整个框架

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 下一篇：Quickstart · 执行主线：Runner、Flow。

用户问“杭州现在多少度”，模型输出一个 get_weather 调用，工具返回 26°C，模型再组织成自然语言回答。这里至少发生了两次模型请求、一次工具执行和多次事件追加。

ADK-Go 把这些工作分给不同组件：Agent 描述行为，Runner 驱动执行，Flow 连接模型和工具，服务保存历史与状态。一次模型响应只是 Agent 运行过程中的一步。

这篇总览围绕三个问题展开：

从程序入口到模型、工具和数据库，中间有哪些边界？
一次输入怎样变成事件，工具结果又怎样进入下一次模型请求？
接口抽象提供了什么，又有哪些必须结合具体实现理解的限制？

一、源码入口与阅读地图

ADK-Go 是用 Go 代码构建 Agent 应用的框架。应用通过构造函数组合 Agent、Model、Tool、服务和运行入口，不需要先把整个应用写成一份声明式工作流。

阅读层次	文件 / 入口	解决的问题
应用示例	`examples/quickstart/main.go`	最小应用怎样装配
启动入口	`cmd/launcher/launcher.go`	console / web 如何共用应用配置
Agent 契约	`agent/agent.go`	什么对象可以被执行
请求驱动	`runner/runner.go`	一次输入如何进入运行时
模型工具循环	`internal/llminternal/base_flow.go`	模型提出调用后由谁执行
会话记录	`session/session.go`	历史、状态和事件如何表达
图调度	`workflow/scheduler.go`	节点、事件和恢复如何协调

先把模块放在同一张结构图上：

Application
 |
 +-- Launcher / HTTP handler / 自定义入口
 | |
 | v
 | Runner <------ SessionService
 | | <--------- ArtifactService / MemoryService
 | v
 | InvocationContext：绑定本次执行所需的对象
 | |
 | v
 | Agent / node runtime
 | |
 | +-- LlmAgent --> Flow --> Model
 | | | |
 | | +<- Tool <-+ FunctionCall
 | |
 | +-- 自定义 Agent / Workflow / 远程 Agent
 |
 +-- Plugin：在已接入的生命周期边界观察或改变行为

Model 适配器与 Tool 的业务实现可以替换，运行层仍围绕请求、响应和事件协作。但是模型共用接口并不意味着所有 provider 支持相同工具、多模态或流式能力。

Agent Development Kit (ADK) · 02 - 初见 ADK

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Quickstart：一个 main 函数怎样启动 Agent 应用

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 前置阅读：Overview · 后续阅读：Launcher、Model、Agent。

一个能回答天气问题的程序，为什么既要创建 Model，又要创建 Agent，还要经过 Loader 和 Launcher？因为这几个对象回答的是不同问题：调用哪个模型、如何组织行为、如何找到应用入口、用户通过什么界面交互。

官方 Quickstart 把这条装配链放在一个 main 中。先看它的结构，再跟踪用户输入到达以后发生的事情，就能把配置代码与运行代码分开。

一、源码入口与阅读地图

文件 / 符号	在这个例子中的职责
examples/quickstart/main.go	创建模型、Agent、Loader 与 Launcher
gemini.NewModel	创建 Gemini SDK client 和模型适配器
llmagent.New	把配置装配为 LlmAgent
agent.NewSingleLoader	用一个 Agent 提供加载入口
full.NewLauncher	提供 console 与 web 两类启动方式
console.Run	创建 Session 和 Runner，进入输入循环

构造阶段
 genai.ClientConfig
 |
 v
 gemini.NewModel -> llmagent.New -> NewSingleLoader
 |
 v
 launcher.Config
 |
运行阶段 v
 os.Args[1:] ----------------> Launcher.Execute
 |
 console 或 web 入口
 |
 Runner / Agent

创建了 Agent 对象，还不代表模型已经生成过一次回答。模型请求通常要等到入口收到输入并消费运行事件时才发生。

Agent Development Kit (ADK) · 03 - Launcher

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Launcher：从命令行到 Runner

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 前置阅读：Quickstart · 后续阅读：Runner、Flow。

Launcher 是 ADK 应用的进程入口层。它处理命令行参数、校验进程级配置、选择运行方式，并把同一份 AgentLoader、SessionService、Plugin 和鉴权配置交给 console 或 web 子入口。

它不负责模型推理，也不负责工具执行。Launcher 选择怎么进入应用，Runner 才驱动一次 Agent 运行。

一、源码入口与阅读地图

层次	文件 / 符号	作用
顶层契约	`cmd/launcher/launcher.go`	Launcher、SubLauncher、Config
选择器	`cmd/launcher/universal/universal.go`	按第一个关键词选择入口
预设组合	`cmd/launcher/full/full.go`	console + 全部 web 子入口
生产组合	`cmd/launcher/prod/prod.go`	REST API + A2A
终端运行	`cmd/launcher/console/console.go`	Session、Runner、stdin 循环
HTTP 运行	`cmd/launcher/web/web.go`	router、sublauncher、HTTP server
REST 挂载	`cmd/launcher/web/api/api.go`	创建 `adkrest.Server` 并挂到 path prefix

整体关系可以先压缩成一张图：

Agent Development Kit (ADK) · 04 - Model

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Model：统一接口怎样连接不同模型服务

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

系列目录 · 配套阅读：Quickstart、Flow、Tool。

Flow 已经准备好用户消息、历史、指令和工具声明，下一步要把请求交给模型服务。Gemini 和 OpenAI 的请求字段、角色、函数调用与流式事件并不相同；Model 层把这些差异放在适配器中处理，向上提供统一的 LLMRequest → LLMResponse 接口。

实现了同一个 LLM 接口，不代表所有模型支持相同的配置和工具。这篇文章围绕一次天气函数调用，说明统一数据怎样跨过 provider 边界，以及信息在转换中如何被保留或拒绝。

一、源码入口与阅读地图

model/
├─ llm.go LLM / LLMRequest / LLMResponse
├─ registry.go 模型名正则 -> Factory
├─ gemini/gemini.go GenAI SDK 适配器
├─ openaimodel/
│ ├─ openai.go Responses API 调用与流式收尾
│ ├─ request.go 请求、消息、配置转换
│ ├─ tools.go 函数声明与 tool choice
│ ├─ response.go 返回内容、usage、结束原因
│ └─ stream.go Responses 事件 -> GenAI 中间结构
└─ apigee/apigee.go 配置代理后委托 Gemini adapter

入口 / 文件	阅读时要回答的问题
model/llm.go	上层到底传什么、收到什么
Flow.callLLM	哪些 callback 返回后不再调用模型
gemini.GenerateContent	普通调用和流式调用如何选择
buildOpenAIParams	通用请求如何转换成 Responses 参数
streamTranslator	provider 的 delta 事件怎样转成通用 part
streamingResponseAggregator	增量和完整响应怎样共存
model.Register / NewLLM	字符串名称怎样解析成实例

二、核心接口与数据结构

1. 两个方法的公共契约

下面是接口与请求结构的源码摘录：

Agent Development Kit (ADK) · 07 - Flow

Sun, 20 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读笔记 · Flow：一次 LLM Agent 回合是怎样跑完的

源码版本：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。以下“当前实现”均指这个版本。

返回源码阅读合集 · 配套阅读：Runner、Context、Tool、Plugin。相关模块的阅读顺序见合集。

用户问“杭州天气怎么样”，模型返回 get_weather(city="Hangzhou")。到这里，天气查询还没有执行，用户也还没有得到答案。程序还必须找到工具、执行代码、把结果交回模型，并判断是否还要继续调用模型。

Flow 就是把这些阶段接起来的内部控制层。 它让一次模型调用成为可以反复“请求 → 执行 → 反馈”的 Agent 运行过程。理解它，关键是同时追踪控制流和数据：下一步由谁触发，上一轮结果又通过什么对象进入下一步。

本文回答三个问题：

谁创建 Flow，它依赖哪些接口和数据？
一条模型 FunctionCall 如何变成工具结果，再进入下一次模型请求？
Flow 与 Runner、Model、Tool 之间的职责边界在哪里？

主线先看普通 Run 的一次工具调用闭环；SSE、确认、transfer 和 Live 放到第四节展开。本文不是 Workflow scheduler 或 Session 数据库实现的完整说明。

阅读准备。 只需要了解 Go 的接口、指针、map，以及大语言模型的 Function Calling：模型输出函数名和参数，实际函数由应用执行。如果不熟悉 iter.Seq2，第三节会结合代码解释；无需先掌握 ADK 的全部模块。

先约定几个容易混用的词：

术语	本文中的含义	天气例子中的数量
Session	持续保存多次交互的会话及其历史、状态	1 个，可以继续提问
Invocation	一次执行上下文所关联的运行；恢复路径可能沿用原 invocation ID	普通无暂停路径为 1 次
Flow step	一次 `runOneStep`：准备请求、消费模型响应、处理工具及后续动作	通常 2 步
模型调用	真正进入 `GenerateContent`；BeforeModel 可使它被跳过	本例 2 次
Event	一条向上返回的运行记录，可能承载文本、函数调用、结果或控制信息	主线为用户输入、调用、结果、答案 4 条；外层还可能有控制事件
Partial / final	Partial 表示响应尚未聚合完成；`IsFinalResponse()` 是事件的结束判定方法	不是“每条 Event 都是一轮模型调用”

第一次阅读可先读第一至第三节，再看第五至第七节；第四节用于沿具体问题深入。文中标为“源码摘录”的代码对应固定 tag；省略外围代码会明确说明。“伪代码”“示意数据”和教学示例不冒充源码原文。

ADK-Go 源码阅读系列

Sat, 19 Sep 2026 00:00:00 +0800

ADK-Go 源码阅读合集

用户发来一句“杭州天气怎么样”，从接收输入到给出答案，中间会经历模型请求、工具执行、事件保存和下一轮推理。多 Agent、人工确认、流式输出和长会话则会改变这条路径。

这个系列沿着一次请求追踪 ADK-Go 的实现：谁创建对象，谁调用接口，数据在哪一步变成事件，结果又如何成为下一次输入。 各篇聚焦一个模块，并用相邻模块的实际调用方说明它的边界。

系列源码基准：ADK-Go v2.4.0，commit 4e57df40cbd35f055ba654b03ffb0e509fdd754a。

各篇使用同一版本的接口、实现和调用方。普通 Run、Live、不同模型适配器与存储后端的行为分别说明；一种运行方式的结论不自动适用于其他方式。

阅读路线

Overview / Quickstart
 ↓
Launcher / Model / Agent
 ↓
Runner → Flow → Tool
 ↓
Context → Session / Event
 ↓
Memory / Plugin / Workflow
 ↓
Artifact → Server → Registry
 ↓
Auth / Telemetry / Platform

如果还不了解 ADK，先读 Overview 和 Quickstart；如果已写过简单 Agent，可从 Flow 的天气示例进入，再沿 Runner → Tool → Context → Session 追踪它上下游的实现。

Go 代码规范

Wed, 31 Dec 2025 00:00:00 +0800

Golang 代码规范 - Tencent golang 代码规范

内容从网上搜索得到

1. 前言

为形成公司统一的 Go 编码风格，以保障公司项目代码的易维护性和编码安全性，特制定本规范。

本规范在 Google Golang 代码规范的基础上，根据腾讯实际情况进行了调整和补充。

每项规范内容，给出了要求等级，其定义为：

必须（Mandatory）：用户必须采用；
推荐（Preferable）：用户理应采用，但如有特殊情况，可以不采用；
可选（Optional）：用户可参考，自行决定是否采用；

目前本规范以 Gometalinter 工具落地，点击查看工具源码。

2. 代码风格

2.1 【必须】格式化

代码都必须用 gofmt 格式化。

2.2 【推荐】换行

建议一行代码不要超过120列，超过的情况，使用合理的换行方法换行。
例外场景：
- import 模块语句
- 工具生成代码
- struct tag

2.3 【必须】括号和空格

遵循 gofmt 的逻辑。
运算符和操作数之间要留空格。
作为输入参数或者数组下标时，运算符和运算数之间不需要空格，紧凑展示。

2.4 【必须】import 规范

使用 goimports 自动格式化引入的包名，import 规范原则上以 goimports 规则为准。
goimports 会自动把依赖包按首字母排序，并对包进行分组管理，通过空行隔开，默认分为本地包（标准库、内部包）、第三方包。
标准包永远位于最上面的第一组。
内部包是指不能被外部 import 的包，如 GoPath 模式下的包名或者非域名开头的当前项目的 GoModules 包名。
带域名的包名都属于第三方包，如 company.code.oa.com/xxx/xxx，github.com/xxx/xxx，不用区分是否是当前项目内部的包。
goimports 默认最少分成本地包和第三方包两大类，这两类包必须分开不能放在一起。本地包或者第三方包内部可以继续按实际情况细分不同子类。
不要使用相对路径引入包：

Go GMP 调度模型

Thu, 14 Aug 2025 00:00:00 +0800

G M P 模型

一句话：调度器调度任务队列、P在M上运行去执行G

两个任务队列 - 全局任务队列 - P本地队列调度器

总览

1、我们通过 go func () 来创建一个 goroutine；

2、有两个存储 G 的队列，一个是局部调度器 P 的本地队列、一个是全局 G 队列。新创建的 G 会先保存在 P 的本地队列中，如果 P 的本地队列已经满了就会保存在全局的队列中；

3、G 只能运行在 M 中，一个 M 必须持有一个 P，M 与 P 是 1：1 的关系。M 会从 P 的本地队列弹出一个可执行状态的 G 来执行，如果 P 的本地队列为空，就会向其他的 MP 组合偷取一个可执行的 G 来执行；

4、一个 M 调度 G 执行的过程是一个循环机制；

5、当 M 执行某一个 G 时候如果发生了 syscall 或则其余阻塞操作，M 会阻塞，如果当前有一些 G 在执行，runtime 会把这个线程 M 从 P 中摘除 (detach)，然后再创建一个新的操作系统的线程 (如果有空闲的线程可用就复用空闲线程) 来服务于这个 P；

Go heap 包笔记

Thu, 14 Aug 2025 00:00:00 +0800

// The Interface type describes the requirements
// for a type using the routines in this package.
// Any type that implements it may be used as a
// min-heap with the following invariants (established after
// [Init] has been called or if the data is empty or sorted):
//
//	!h.Less(j, i) for 0 <= i < h.Len() and 2*i+1 <= j <= 2*i+2 and j < h.Len()
//
// Note that [Push] and [Pop] in this interface are for package heap's
// implementation to call. To add and remove things from the heap,
// use [heap.Push] and [heap.Pop].
type Interface interface {
	sort.Interface
	Push(x any) // add x as element Len()
	Pop() any // remove and return element Len() - 1.
}

初始化一个堆

Go GC 原理与观测

Sat, 02 Aug 2025 00:00:00 +0800

1. 什么是GC

GC，全称 Garbage Collection，即垃圾回收，是一种自动内存管理的机制。

2. 为什么GC

程序向操作系统申请的内存不再需要时

3. 怎么GC

赋值器（Mutator）：用户代码，负责修改对象引用关系。
回收器（Collector）：负责标记和回收无用内存。

4. GC 可观测

GODEBUG=gctrace=1 debug.ReadGCStats runtime.ReadMemStats

5. 为什么会出现内存泄漏

- 预期能被快速释放的内存因被根对象引用而没有得到迅速释放
		 - 指针
		 - 全局变量
 - Goroutine 泄漏
 Goroutine 作为一种逻辑上理解的轻量级线程，需要维护执行用户代码的上下文信息。在运行过程中也需要消耗一定的内存来保存这类信息，而这些内存在目前版本的 Go 中是不会被释放的。因此，如果一个程序持续不断地产生新的 goroutine、且不结束已经创建的 goroutine 并复用这部分内存，就会造成内存泄漏的现象.
 eg: 曾经项目中遇到的，mock了一个链接，忘记关闭

// FillArgsInSQL 使用 mock db 将参数填回 SQL
func FillArgsInSQL(sql string, args ...any) string {
	db, _, _ := sqlmock.New()
	defer db.Close() // <—— 如果没关闭
	gormDB, _ := gorm.Open(
		mysql.New(mysql.Config{
			Conn: db, // Existing mock database connection
			SkipInitializeWithVersion: true, // 跳过 SELECT VERSION() 检查
		}),
		&gorm.Config{DryRun: true})
	sqlStmt := gormDB.ToSQL(func(tx *gorm.DB) *gorm.DB {
		return tx.Raw(sql, JsonToBasicType(args)...)
	})
	return sqlStmt
}

6. 常见的垃圾回收方法

所有的 GC 算法其存在形式可以归结为追踪（Tracing）和引用计数（Reference Counting）这两种形式的混合运用。目前比较常见的 GC 实现方式包括：

Go sort 包笔记

Tue, 29 Jul 2025 00:00:00 +0800

https://www.notion.so/sort-23f21f3fbf218042a172fcee79ac3d8b?source=copy_link

Go 中 exec.Command 与 os.StartProcess 的区别

Sat, 26 Jul 2025 00:00:00 +0800

exec.Command 与 os.StartProcess 有什么不一样

这是一个非常经典的问题：exec.Command 和 os.StartProcess 都可以启动新进程，但功能和易用性完全不同。我给你详细拆解一下：

1. os.StartProcess

特点

Go 最底层的 进程创建 API，是对系统调用 fork + exec（类 Unix）或 CreateProcess（Windows）的直接封装。
调用麻烦，需要手动准备命令参数、环境变量、标准输入输出、文件描述符等。
返回 *os.Process，只能用它做简单的进程管理（等待、杀死）。

用法示例

package main

import (
	"os"
	"syscall"
)

func main() {
	// argv 必须是完整路径 + 参数数组
	procAttr := &os.ProcAttr{
		Dir: "",
		Env: os.Environ(),
		Files: []*os.File{os.Stdin, os.Stdout, os.Stderr}, // 指定标准IO
		Sys: &syscall.SysProcAttr{},
	}

	process, err := os.StartProcess("/bin/ls", []string{"ls", "-l"}, procAttr)
	if err != nil {
		panic(err)
	}
	process.Wait()
}

👉 缺点：调用复杂，几乎不做封装。

Go 1.23 迭代器原理

Mon, 14 Jul 2025 00:00:00 +0800

(https://mp.weixin.qq.com/s?biz=MzA4ODg0NDkzOA==&mid=2247510020&idx=1&sn=c4daaaf3e895bf17a76e2481a74bf243&chksm=91a791e540e5ee433099f24654eaf06126750dd2392d660bf9144cbf33582e4e0022a6f060f9#rd)

也就是说只有符合上述函数签名的函数类型才是可以被for range支持的iterator。即所谓自定义iterator，本质上就是一个接受一个函数类型参数的函数(如上图中红框①)，按惯例，这个函数类型的参数被命名为yield(见红框②)。从Backward函数的返回值(一个iterator)的实现来看，当yield函数返回false时，迭代结束；否则迭代继续进行，直到集合类型(如slice)中所有元素都被遍历完。

其实，for range+自定义iterator可以看成是Go提供的又一个“语法糖”，它是通过Go编译器在编译阶段的代码转换来实现的。下面我们还基于Backward那个例子来看看这个转换过程：

Go pprof 性能分析

Mon, 14 Jul 2025 00:00:00 +0800

https://www.liwenzhou.com/posts/Go/pprof/

四个方面

CPU profile：报告程序的 CPU 使用情况，按照一定频率去采集应用程序在 CPU 和寄存器上面的数据
Memory profile（Heap Profile：内存使用情况
Block profiling：goroutine 不在运行的状态，可以用来分析和查找死锁等性能瓶颈
Goroutine profiling：goroutines的使用情况，以及调用关系

Go语言内置了获取程序的运行数据的工具，包括以下两个标准库：

runtime/pprof：采集工具型应用运行数据进行分析
net/http/pprof：采集服务型应用运行时数据进行分析

CPU的采集

pprof.StartCPUProfile(w io.Writer)
pprof.StopCPUProfile()

得到采样数据之后，使用go tool pprof工具进行内存性能分析。

内存

pprof.WriteHeapProfile(w io.Writer)

go tool pprof默认是使用-inuse_space进行统计，还可以使用-inuse-objects查看分配对象的数量。

import _ “net/http/pprof”

你的 HTTP 服务都会多出/debug/pprof endpoint

(pprof) top3
Showing nodes accounting for 100.37s, 87.68% of 114.47s total
Dropped 17 nodes (cum <= 0.57s)
Showing top 3 nodes out of 4
 flat flat% sum% cum cum%
 42.52s 37.15% 37.15% 91.73s 80.13% runtime.selectnbrecv
 35.21s 30.76% 67.90% 39.49s 34.50% runtime.chanrecv
 22.64s 19.78% 87.68% 114.37s 99.91% main.logicCode

其中：

Go database/sql 连接池源码阅读

Sat, 11 Jan 2025 00:00:00 +0800

Golang database/sql 数据库连接源码阅读

代码仓库 database/sql

打开数据库连接方法

打开数据库连接 sql.Open() 返回 *sql.DB

// Open 打开一个由数据库驱动名称和驱动特定的数据源名称指定的数据库，
// 通常至少包括一个数据库名称和连接信息。
//
// 大多数用户会通过一个特定于驱动的连接助手函数来打开数据库，该函数返回一个 [*DB]。
// Go 标准库中不包含数据库驱动。请参见 <https://golang.org/s/sqldrivers> 获取第三方驱动列表。
//
// Open 可能仅验证其参数而不创建数据库连接。要验证数据源名称是否有效，请调用 [DB.Ping]。
//
// 返回的 [DB] 对象是线程安全的，可以被多个 goroutine 并发使用，并维护自己的空闲连接池。
// 因此，Open 函数通常只需调用一次。通常不需要关闭 [DB]。
func Open(driverName, dataSourceName string) (*DB, error) {
	driversMu.RLock()
	driveri, ok := drivers[driverName]
	driversMu.RUnlock()
	if !ok {
		return nil, fmt.Errorf("sql: unknown driver %q (forgotten import?)", driverName)
	}

	if driverCtx, ok := driveri.(driver.DriverContext); ok {
		connector, err := driverCtx.OpenConnector(dataSourceName)
		if err != nil {
			return nil, err
		}
		return OpenDB(connector), nil
	}

	return OpenDB(dsnConnector{dsn: dataSourceName, driver: driveri}), nil
}

先看一下DB 定义