如果你接收到的数据有很大程度的不确定性，那么你做的第一件事应该是消除掉这个不确定性
我理解你希望 json 包帮你解决这个问题，但它没有不是因为它有问题，而是它要服从于 go 的设计逻辑
在 go 里，明确有*int 这样的指针来判断这个参数的 “有”和“无”，所以 json 包没必要越俎代庖，否则也会有另一批人跳出来说它有毛病
你现在的问题很简单，用*int 能解决你的校验问题，但你不愿意用，因为对后续其它逻辑处理流程太麻烦
我们的解决方案很简单，你只要多加一层 struct 就行了，这层 struct 和你现在 struct 的区别在于，那些不能接受默认值的字段，改成指针
用这个校验 struct 对进来的数据进行校验，校验通过复制到逻辑 struct 里去，后面的流程不变

@InkStone
这还是需要区分讨论的，如果我是个内部的 grpc 服务/消息队列消费者，我不会对这种奇怪的情况做兼容
如果我是个面向外部的 HTTP 服务，我不可能直接用 decode http body 的 struct ，让它透传到数据库或消息队列
楼主的问题我觉得很好理解，他接受请求用的 struct 用在了后面的很多处理流程里，没有一个“消毒区”，把前端进来的数据处理成面向系统内部流程的 struct ，导致他出现了这么多痛苦的情况
如果本身接收外部请求的是一个专用 struct ，里面可以包含很多{A *int}这类为了检验而存在的妥协，校验完成后新组成的对象就完全可以是 {A int}了啊

@BeautifulSoap
为什么年龄会有 null 呢？如果是必填数据，人还没出生这个人的数据从哪来的？
如果这是个非必填数据，使用*int 又有什么问题呢？
感觉很多写 go 的人非常排斥使用*string 或者*int ，想不通为什么

你要的是数据验证，而不是 json 反序列化，应该用这个
https://github.com/go-playground/validator

我调一个服务，从他那获取我需要的数据，他是我的上游
我调用一个服务，把需要处理和执行的任务发送给他，他去处理后续操作，他是我的下游
我是这么理解的，有问题么?
上下游是根据主动被动划分的么？那 callback 怎么算？

坐标上海，我周末在高架上看到创维的电动车，就那个造电视的 skyworth
他都敢卖，都有人敢买，小米有什么不敢的
只要参数好，各种测试过关，小毛病少，肯定很多人买
在电车这里，目前还没建立起太大的品牌效应来

@junkk #27 没用过 jb 家的东西，但是 vscode 是通过 remote 的方式进行的，在 wsl 里起一个 vscode server ，你在 windows 里的 vscode 编辑会传送给 server ，然后 server 修改 wsl 系统下的文件。虽然说起来很繁琐，但是实际体验和直接编辑 windows 目录下的文件没有区别，甚至更好，因为 vscode 的内置 terminal 也会直接在 wsl 下运行。
可以找找试试 jb 家的 remote ，应该也是支持 wsl 的

没问题啊，我一直都很好理解为啥那么多物理学家信教
参照系么，以你自己为中心的观测参照系，就是唯心主义

减产就是认怂了，价格战打不下去了

小米安全守护关了就行了

沙发，坐深很重要，当年逛了一整个家具城，国产牌子的沙发大多数坐深都很浅，不符合我瘫在上面的需求
床垫买的金可儿，主要是老婆对威斯汀的床垫印象很好，去线下店里试睡了一个适中的床垫，因为我们俩体重差距太大了，对她最合适的对我太软，对我最合适对她太硬。
床垫带来的提升真的是颠覆性的体验，睡眠质量能提升好几个等级
不过那是四五年前了，这几年国产品牌应该有挺大进步的了，喜临门什么的看着也不错
另外，目前这些牌子线上线下一般都不同款，如果价差不太大的话，就在线下买吧，毕竟能试的到，有时候软硬度差一点，确实感觉不一样

个人口味：20 度以上就不适合直接入口，不喜欢酒精入喉管的强烈刺激性感觉，尤其是 52 度的高度酒，再好入口也不好入喉

没有 GPT5
只会继续更新 GPT4 的版本