我有一个日期时间的字段它有可能为空，我问 Go 该怎么办……

@PTLin 为啥算坑，我觉得 age 为 0 还蛮符合直觉的，反而报错有点不符合直觉。

@javalaw2010
我的理解是，比如 struct A {A,B}。
用字符串"{A:xxx,B:xxx,C:xxx}"可以成功解析，但是"{A:xxx}"不应该成功解析，因为缺少 B 字段的信息，这种情况要是想要成功解析需要库提供一种假如没有这个字段就用默认值的方法，但是不应该把这种解析方式当成库的缺省实现。
对于这个例子还好，因为 age 年龄逻辑上不可能为 0 ，但是更复杂的场景就容易碰到问题。

你问 Go 怎么办？是有哪个新的 LLM 起名叫 Go 了吗？

在编程语言 Null/Nil/Zero 设计取向这个问题上，我很难说清自己的偏好和立场。这个问题我也尝试去理解、思考过很多次，暂时的结论是，对语言设计者来说这是个技术或者取舍问题，对语言的使用者来说更倾向于是一个工程问题。



我就以 Go/Rust 为例做个对比。

Go 的设计是 make zero useful ，相当于扩大了 zero 的功能，减少了 null 的存在。这样做的好处是：

1. 避免了 c 或其他语言的 UBI 初始化前就使用的情况（ go 设计受 c 的影响很大）
2. 简化了编译器开发，go 早期的编译器基本上是手搓的，没有 null 的话数据类型在内存的布局就很简洁
3. 直接支持组合，go 是 duck typing 和组合优于继承思想的产物，基础类型默认零值初始化那么组合类型也间接初始化了
4. 代码稍微简化一点，不太用写 null 判断了

缺点主要是两方面：

1. 零值有歧义
2. 引用类型的 nil 可能不够安全（运行时）

Rust 走的是完全内存安全的路线，所以设计上就没有传统的 Null ，所有 & 引用都永远不会是 Null 。

为了达到这个效果，Rust 强制开发者使用 Option<T> 处理可能的 Null ，同时代码上也要显式初始化变量。即便有默认零值，也是通过 Default trait 来显式指定的。

内存布局方面，因为要在数据本身之外存储是否为 Null 的标记，所以这个内存布局是相对复杂的。为了解决这个问题，Rust 引入了一个叫 Null Pointer Optimization 的优化，具体原理我不太清楚。

总体上代码编译慢和这些设计因素是分不开的。好处是确实不需要写 Null 判断了。

这两个语言在 nil 安全上是没有本质区别的，对 nil 解引用只能在运行时才能发现。而这两个语言都有 ffi 的需要，所以业务层面也是无法避免的。



所以设计起点比较高的语言，根本的目标都是想要优化 Null 处理逻辑，只是方法和路线不一样。

当涉及到具体的业务时，只要用到“数值代表状态”的逻辑，最终总要有代码做判定，区别只是这个代码发生在什么地方。原本这个逻辑和 Null/Zero 不相关，只是因为开发中 Null/Zero 最常用，所以才出现业务代码要判定 Null/Zero 的需求。

所以我的认知里，Null 应当是一个技术细节，而永远不应该是一个业务特性。特别是软件开发越来越强调网络交互而不是单机单体应用的时候，Null 就是个隐患。我更倾向于强制在业务层面上禁止 Null 的使用。但我这种想法实施起来难度很大，几乎稍微有点历史的数据库都是会区分 Null/Zero 的，没有办法禁止其他人使用 Null 特性。

是 ai 来活跃气氛吗？

op 是没用过强类型语言吗... 还是前端转过来的...
不正确的方便理解的说 至少是指针类型才能使 nil

既然你数据库定义了可以为 null ，代码里对应的变量一样这样定义很合理啊。。。不过我一直不理解为什么有的人设计数据库的时候全部可以空

@kuanat 掩耳盗铃罢了，空值作为一个业务上存在的概念，它必然以某种形式在技术上存在，无非是把空指针崩溃变成输出一个全零的值而已。