Go 语言进阶（进阶特性）
反射
反射是指程序在运行时检查其自身结构（变量、类型、函数等）的能力。go 的反射核心是 reflect 包。
核心逻辑
- reflect.Type：它是什么？？（类型信息，如 int, string, struct）
- reflect.Value：它存了什么？？（具体的数值）
tip：
reflect.TypeOf 是“拿到类型信息”（里面有很多子信息）
t.Field(i)：返回第 i 个结构体字段的“字段定义信息”
v.Field(i)：返回第 i 个字段的“字段值”（返回的是一个 reflect.Value，不是普通值，所以要用.Interface( ) 变成go里面的普通类型）
反射的“代价”
- 性能损耗：反射是运行时的逻辑，比静态代码慢几个数量级
- 不安全：反射操作如果类型不匹配，会直接 panic
- 晦涩：大量使用反射会让代码逻辑变得难以追踪
泛型
泛型可以再编写函数或者结构体时，先不指定具体类型，而是用一个占位符 [T any] 代替
泛型约束
在 go 里，不能随心所欲使用任何类型，需要约束
- any：任何类型（等同于之前的 interface{}）
- comparable：支持 == 和 != 的类型
- 自定义接口：要求类型必须实现某些方法
反射与泛型的区别
| xxx | 泛型 | 反射 |
|---|---|---|
| 生效时间 | 编译期 | 运行期 |
| 性能 | 几乎无额外开销 | 性能损耗大 |
| 安全性 | 编译期检查，很安全 | 运行期检查，易 pannic |
空接口
在 go 1.18之后，any 成了 interface{} 的别名，空接口不包含任何方法，所以任何类型都实现了空接口
核心逻辑
- 空接口就像一个可以装任何东西的“盒子”。而且go 的空接口会带着类型信息
![img]()
类型断言
空接口可以装任何东西，那么当你把东西拿出来时，你需要一种逻辑来确认它到底是什么。这就是类型断言
核心逻辑：
断言有两种方式：1. “赌一把”（不安全，失败会 Panic）2. “商量着来”（安全，使用 Comma-ok 模式）
包管理
Go Modules (go mod) 是现代 Go 项目的工程标准。它解决了 C++ 开发者常遇到的“库版本冲突”和“编译依赖”难题。
核心逻辑
- go.mod：项目的“户口本”。记录了模块名称、Go 版本和依赖库的版本
- go.sum：哈希校验表。确保你下载的依赖包没有被篡改，保证逻辑安全性
| 命令 | 逻辑功能 |
|---|---|
| go mod init <名称> | 初始化项目，生成 go.mod 文件 |
| go mod tidy | 最常用。自动分析代码，下载缺失包，删除未用包 |
| go build | 编译项目，所有依赖会打包成一个独立的可执行文件 |
测试
单元测试
用于验证单个函数逻辑是否符合预期
- 文件名：必须以 _test.go 结尾（例如 math_test.go）
- 函数名：必须以 Test 开头，接收参数 (t *testing.T)
- 逻辑判定：使用 t.Errorf 或 t.Fatalf 报告错误
- 直接在终端输入 go test -v 就可以自动识别测试文件
假如有一个待测函数：
那配套的单元测试：
基准测试
基准测试用于测量代码的性能（吞吐量和耗时）
- 函数名：必须以 Benchmark 开头，接收参数 (b *testing.B)
- 文件名：必须以 _test.go 结尾（例如 math_test.go）
- 循环结构：必须使用 for i := 0; i < b.N; i++。b.N 是由系统动态调整的，直到获得一个稳定的统计结果
![img]()
示例测试
示例测试既是测试，又是文档。它的逻辑非常巧妙：它会捕获标准输出并与注释中的预期输出对比。
- 函数名：必须以 Example 开头
- 预期输出：在函数末尾使用 // Output: 注释
- 文件名：必须以 _test.go 结尾（例如 math_test.go）
当运行 go test 时，Go 会执行这个函数并对比输出。如果不一致，测试就会失败。
进阶测试
- 测试覆盖率
- go test -cover：它会给出一个百分比
- 网络与外部依赖 Mock
- 定义 Interface，然后在测试时传入一个模拟的对象（Mock）
性能分析（pprpf）
pprof 是 Go 内置的性能分析利器。
它可以告诉你：程序里哪个函数最占 CPU？哪里在疯狂分配内存？有没有协程死锁了？
核心逻辑：采样与可视化
- CPU Profiling：每隔 10ms 采样一次，看哪个函数在栈顶
- Heap Profiling：监控内存分配，查找内存泄漏
- Goroutine Profiling：查看所有协程的调用栈（找死锁和泄露的神器）
分析：
- 浏览器查看：访问 http://localhost:6060/debug/pprof/
- 终端分析：使用交互式命令行：go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
- 火焰图 (Flame Graph)：go tool pprof -http=:8080 [采样文件]火焰图越宽，代表该函数消耗资源越多。这是寻找 RAG 检索逻辑瓶颈最直观的方式。
代码规范（gofmt、golint）
官方给出一套标准，你必须遵守
- gofmt
- gofmt 会自动把你的代码修成标准样子
- golint 与 golangci-lint
- golint：检查你的代码是否符合《Go Code Review Comments》
- golangci-lint (进阶)：这是目前工业界的标准。它集成了几十个检查器，能查出你的代码里没处理的错误、未使用的变量、甚至是潜在的并发死锁风险。