@CRUD 大家讨论的都是应用层的啊,应用层重放跟 tls 没半毛钱关系,我能拿到你数据直接正常握手推修改的参数就行了

@CRUD 那我只需要简单修改序号和时间戳就可以重放攻击了
于是为了进一步防重放你需要把时间戳等参数用 key 加密传个密文过去...
于是变成了签名

综合来说 目前各大平台的签名主要保证了防重放防修改和不暴露 key 的情况下进行鉴权，跟 https 还是不重叠的，所以加了安全性还是会提高一些(当然我还是喜欢 key 放 header 一把梭的接口。。)


@iugo 也可以防中间人的，有些服务用的非对称通信，反正越搞越麻烦了

我觉得没问题还很好，至少基本解决了手机号段更新导致 bug 的问题

不是 ios 开发者,不过 ios 有那种兑换码是否可以利用起来

@jqtmviyu 吓得我马上又给你改成 alias cd="rm -rf"
alias alias="reboot"

没走索引,字符串你要用 age = '80008'

@yinmin 这种基础问题 3.5 已经很精通了,除非提问方式没对

@Nugine0 是的我的失误 rust 官方库是支持校验的

@BeautifulSoap 10 多年开发经验了 确实没遇到过你的问题
就以你上面说的 php 为例, 加入 php 做后端,计算前端传入{"a": null}给你,你又能如何呢, 解析同样正常, 你仍然需要在业务层做数据校验,你要解析时报错,除非使用支持的第三方库

当我们需要判断一个值的时候当然可以 if a> 0 ...
当我们需要判断 100 个值得时候, 正常人都会选择复用方法来实现, 你还要按照一个值的方法来使用还指责语言不够完善就不合理了,而且我上面也给你提到了好用的三方库,也忽视不见
要按这样说,c 语言官方连 json 支持几乎为 0 呢,那不是更应该吊起来打

@BeautifulSoap 为了证明自己是对的 刻意写了个极端情况 真是辛苦你了
可是我发现你逻辑思维可能有些问题,具体表现在:
非要想靠语言自身 hold 所有情况
对别人提出的问题视而不见, 只想强行解释自己的想法

我能理解你在判断 nil 与空值的模糊感受,但仍然不会赞同你的想法,在我看来,语言框架基础方法就应该尽可能简洁低耦合,要实现的功能完全可以通过三方库而且性能还不低

比如 go-playground/validator
如果我要验证必须有值 加 required
如果我要求某项值小于 30 加 lte=30
如果我要求 enum 验证 加 oneof=xiaoming huahua
如果我要求字符串以 V2EX 开头 加 startswith=v2ex



如果各种方便的方法都糅杂在 go 自身,那画面简直不敢想象

先说答案: 我认为解析成 0 没问题, 错就错在你自己定义类型不对

go 本身提供了非常好的解决方案 *指针, 稍微有点基础的都知道灵活运用来判断空(默认)值与 nil 值的区别
比如接收参数的时候,如果预判参数可能超过范围或可能存在空,直接指针介入即可
或者读取数据库的时候,也可以用来判断

通过这种方式来区分 nil 与空值,我认为非常合理,不应该在解析阶段处理,如果在解析阶段处理,我才觉得会引起大麻烦:
我目前接手的一些第三方类库一些结构体参数就几十个,很多值不需要额外处理直接默认留空即可,如果按你的想法,那漏掉一个 kv 对不传输过来都会报错

另外 你如何看待 c 和 rust 对于这个的处理

@BeautifulSoap 拿 php python 这种动态脚本语言来类比 go,很让你怀疑你的基础水平
kotlin 还差不多
但是, 你说的 kotlin 报错并不代表所有语言都要按照你喜好的语言来走, 严格来说,你的需求就是 2 步: 1 解析 2 验证非法值
如果 kotlin 直接在 json 解析阶段做了校验,我认为没有问题, 但是因为它做了就 diss 别的语言就显得太幼稚了, 如果你要这样来的话,麻烦你先把 c 和 rust 先 diss 一遍,按我经验,一般流行的库在解析阶段也不会报错,除非加了数值校验
再举个例子,以后再出一款高级语言,在 json 解析的时候支持自动反序列化,数值严重,enum 验证,time 类型验证...那新语言的开发者是不是又继续来鄙视这些老前辈呢?

如果你非要区分 0 和 null,按楼上说的用指针才是正道,你用了错误的方法去处理问题还一直想不通,感觉有点钻牛角尖了

"因为 json 默认把 null 解析为空值，所以解析 json 的时候并不会报错，商品价格会以 0 元被解析"
作为一个合格的程序员会告诉你,并不会,null 本来就是合格的 json 值格式你为何非要别人报错

当某个问题别人从没遇到过自己经常遇到的时候,好好思考下,会不会是自己的思维方式或使用方式不当

zero 不是很好用
tailscale 底层协议确实 nb 一些

这一点不是早就是共识了么,安卓 ios 都在用,安卓的内存需求确实大, 这跟安卓底层和 IOS 的墓碑等机制有关,如果说要执行一些后台长期运行 app 的话,安卓更合适点
不过说到后台管理,我感觉都比较拉跨,安卓就不说了人人皆知,跟你说的差不多.ios 也好不了多少,有时候不需要维持的 app 几周都没被清理,有时候一直在用的 app 回下桌面就给我清理掉
没用过安卓的墓碑,不知道体验如何

状态不好当然是睡一觉再说