我以为你在吐槽隔壁那个帖子，没想到你是认真的

家里淘汰的 DELL 2515U

@jadelike #14 https://i.imgur.com/ZveiiGy.png 你当海关瞎啊，就差把来查我写脑门上了

签名没啥问题，虽然繁琐了一点，但一般是网关要求，锅不在业务身上
至于文档内容的烂，确实是超出了意料，腾讯是完全不打算做 2B 业务是么

做设计规划可能不会有 BUG ，但是你打字肯定会偶尔打错两个字的
专业作家写小说都要一审二审三审，人名写串那也是常事
写代码的时候偶尔脑子抽了，变量用错了，赋值位置错了，那不是很正常？

无论如何也不要双脚开车，从坐姿上来说，刹车大，位置高，油门小，位置低，你两个都要备踩会很累很累
而且左脚大概率悬空，出现紧急情况，脑子一空，大概率也是油门先踩到底再踩刹车，特斯拉加速那么快，这点时间就是生命

@BeautifulSoap #142 如果你在写 go 之前，认真的看过这个东西，你就会明白我说的是什么意思 https://google.github.io/styleguide/go/guide
不想和你继续下去了，你不是来寻找解决方案的，你只是来吐槽的，给你说再多你都认为别人在攻击你，实在是没必要和你继续浪费时间了

@BeautifulSoap 你怎么写个 golang 一股 java 味？看着这些臃肿的抽象层我就头疼，如果你执意要这么玩，那最好还是用回 java 吧，golang 不适合这个玩法

如果你接收到的数据有很大程度的不确定性，那么你做的第一件事应该是消除掉这个不确定性
我理解你希望 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
他都敢卖，都有人敢买，小米有什么不敢的
只要参数好，各种测试过关，小毛病少，肯定很多人买
在电车这里，目前还没建立起太大的品牌效应来