Go语言无原生Option类型，所有实现均为第三方库（如samber/mo）或手写泛型struct封装，核心是显式表达“值可能存在或缺失”的语义，要求显式构造Some(T)/None[T]()，禁止直接当T使用，必须解包。
Go里没有原生Option，得靠泛型自己造
Go语言本身不提供 Option 类型，不像Rust的 Option<t></t> 或 Scala 的 Option[T]。你不能直接写 var x Option[string] 并期待编译通过。所有“Go版Option”都是第三方库（如 samber/mo、fp-go）或手写泛型结构体实现的封装，核心目标是把“值可能存在也可能为nil”的语义显式化，避免裸指针判空带来的不确定性。
关键点在于：它不是语法糖，而是类型安全的容器——Some(T) 和 None[T]() 必须显式构造，且一旦声明为 Option[T]，就不能直接当 T 用，必须先解包。
samber/mo 的 Option[T] 怎么用才不踩坑
samber/mo 是目前最成熟的 Go Option 实现之一，它的 Option[T] 是一个 struct，不是 interface，因此零值是可预测的（isPresent=false），也支持比较（只要 T 可比较）。
- 创建时别漏泛型参数：
option.Some(42)是错的，必须写option.Some[int](42)或依赖上下文推导；option.None[string]()不能省略[string]，否则编译器无法确定类型 -
From[*T]是常用入口，但注意：传nil *string得到None[string]，传非 nil 指针才得Some；如果指针本身指向空字符串/零值，它仍是Some，和“值是否为空”无关，只和“指针是否为 nil”有关 - 不要用
==直接比较两个Option[T]，除非T实现了Equal方法或本身就是可比较类型（如int、string）；否则应调用.Equals(other) -
MustGet()会 panic，仅限调试或已确认IsPresent()为 true 的场景；生产代码优先用OrElse(default)或Map(fn)
自己手写 Option[T] 要避开哪些设计雷区
如果你不想引入外部依赖，可以自己定义泛型 Option，但常见错误包括：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
interface{}替代泛型参数——失去类型检查，退化成弱类型容器 - 把
None设计成全局变量（如var None Option[int]），会导致所有Option[T]共享同一零值，无法区分None[int]和None[string] - 忘记为
Option[T]实现方法时加泛型约束——比如Map[U any](f func(T) U) Option[U]，若漏掉[U any]，编译失败且报错晦涩 - 在
Some构造时不做字段赋值校验（如传入NaNfloat 或非法 time.Time），导致后续逻辑崩溃；建议在Some内部做轻量验证，或由调用方负责
Option 和指针、error 组合使用的实际边界在哪
很多人疑惑：既然有 *T，为啥还要 Option[T]？区别很实在：
-
*T的 nil 表示“未设置”或“未初始化”，但无法区分“用户明确设为 nil”和“根本没赋值”；Option[T]的None明确表达“此处本应有值，但当前缺失” - 函数返回
(T, error)适合错误可恢复场景；而Option[T]更适合“查无此数据”这类业务上合法的空结果（比如缓存未命中、数据库 SELECT WHERE id=123 返回空） - 组合使用常见于配置解析：例如
type Config struct { Timeout Option[time.Duration] }，比Timeout *time.Duration更清晰表明“该字段允许不提供，且提供时必为有效值” - 千万别混用：不要写
func Load() (Option[*string], error)——这等于套了两层可选性，语义冗余；要么用Option[string]，要么用(*string, error)，二选一
最易被忽略的一点：Option 不解决并发安全问题。如果多个 goroutine 同时读写同一个 Option[T] 实例，仍需额外同步机制，它只是值语义的包装，不是线程安全的容器。
