🏷️ Go 里的“贴标签”艺术：Marker Interface（标记接口）Marker Interface（标记接口

Marker Interface（标记接口）到底是个啥？

“在 Go 里，
有些接口不干实事，
只负责‘贴标签’——
但正是这些标签，让类型有了身份。”

🤔 一、先问个问题：什么是 `error`？

你肯定写过：

if err != nil {
    log.Fatal(err)
}

那你知道 err 到底是什么吗？
答案藏在标准库里：

type error interface {
    Error() string
}

只要一个类型实现了 Error() string 方法，
它就自动成了 error —— Go 的世界，认行为，不认出身。

这很 Go：接口是隐式的，能力即身份。

🧪 二、但有些错误，比普通错误“更特别”

比如这段代码：

func main() {
    var s []string
    s[3] = "oops"
}

运行结果？

panic: runtime error: index out of range [3] with length 0

这个错误不是你 errors.New("xxx") 手动创建的，
它是 Go 运行时亲自下场抛的 —— 我们叫它 runtime error。

那么问题来了：
怎么区分“我写的错误”和“Go 抛的错误”？

答案：看它有没有被贴上一个神秘标签 —— runtime.Error。

🏷️ 三、Marker Interface：不干活，只挂牌

来看 runtime 包里的定义：

type Error interface {
    error               // 嵌入普通 error
    RuntimeError()      // 注意：这个方法什么都不做！
}

RuntimeError() 是个空方法（no-op），
它存在的唯一目的就是：标记这个类型是“运行时错误”。

✨ 这就是 Marker Interface（标记接口）：
不提供行为，只提供“分类身份”。

就像超市里给商品贴“有机”“清真”“临期”标签一样，
Go 用空方法给类型打 tag，方便后续识别。

🔍 四、实战：用 `errors.As` 识别“特殊身份”

假设你想对 runtime error 做特殊处理：

func handlePanic() {
    defer func() {
        if r := recover(); r != nil {
            if err, ok := r.(error); ok {
                // 检查是否是 runtime error
                if errors.As(err, new(runtime.Error)) {
                    fmt.Println("🚨 这是 Go 自己炸的！", err)
                } else {
                    fmt.Println("😅 这是我写的 bug", err)
                }
            }
        }
    }()
    
    // 故意制造 panic
    _ = 1 / 0 // divide by zero → runtime error
}

输出：

🚨 这是 Go 自己炸的！runtime error: integer divide by zero

✅ 关键点：

errors.As(err, new(runtime.Error)) 会检查 err 是否实现了 runtime.Error 接口
即使 RuntimeError() 方法体是空的，只要存在，就算“有标签”

🧱 五、为什么不用字段 or 类型断言？

你可能会想：

“干嘛搞个空方法？直接加个字段 IsRuntime bool 不就行了？”

但那样会带来一堆问题：

所有错误类型都要加字段（侵入性强）
无法兼容第三方错误
判断逻辑变成 if err.IsRuntime，不够通用

而 Marker Interface 的妙处在于：

零成本：空方法编译后几乎无开销
非侵入：任何包都能给自己的类型“贴标签”
组合友好：通过嵌入 error，天然兼容现有错误体系

💡 Go 的设计哲学再次闪光：
用最小的机制，解决最大的问题。

🌐 六、不止 runtime：其他地方也在偷偷用

除了 runtime.Error，标准库和社区里还有类似用法：

ast.Node 相关类型用空方法分组（用于语法树遍历）
某些测试框架用 marker interface 标记“可跳过测试”
一些 ORM 用它区分“软删除” vs “硬删除”模型

虽然不常见，但一旦用上，代码的表达力会突然提升一个维度。

⚠️ 七、小心！别滥用“贴标签”

Marker Interface 很酷，但 Go 官方其实不太鼓励这种模式。

为啥？
因为 Go 推崇 “行为驱动接口” —— 接口应该描述“能做什么”，而不是“是什么”。

RuntimeError() 没有行为，只有身份，
所以它是个 例外，不是范式。

📜 Rob Pike 曾说：
“If your interface has only one method, think twice.
If it has zero methods… you better have a damn good reason.”

所以：能用普通接口就别用 marker；
真需要分类时，marker 才是优雅解。

🎯 结语：标签虽小，意义不小

Marker Interface 就像 Go 语言里的“隐形邮票”——
平时看不见，关键时刻却能决定“这个值该去哪”。

它提醒我们：

类型系统不只是为了校验，更是为了表达意图
有时候，“是什么”比“能做什么”更重要
而 Go，总能在“简单”和“强大”之间，找到那个微妙的平衡点

🏷️ Go 里的“贴标签”艺术：Marker Interface（标记接口）