签名没啥问题，虽然繁琐了一点，但一般是网关要求，锅不在业务身上
至于文档内容的烂，确实是超出了意料，腾讯是完全不打算做 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
他都敢卖，都有人敢买，小米有什么不敢的
只要参数好，各种测试过关，小毛病少，肯定很多人买
在电车这里，目前还没建立起太大的品牌效应来

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

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

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