@theprimone Rust 呀

Python 的作用域规则跟 C 不一样，cname 在出了 for 循环之后还是一个有效的对象，在下一次 for 循环中做的事情不是重新绑定了这个对象，而是修改了这个对象的值。

扫二维码这个事情可大可小。完全不利用什么漏洞的话，很多时候就是引流钓鱼；小漏洞的话可能会触发隐式的关注、加群什么的；高危漏洞的话，扫个二维码已经可以盗刷你的钱了。

看小说，看论文，看图看照片看网页。

刷剧我倒是更倾向在电视上看，除非是外出。

这就是“复杂性不会消失，只会转移”。

最佳实践应该就是不要盲目追求灵活性，像数据格式这种东西就应该老老实实约定好固定下来……API 和 DAO 中间还是需要中间层做解耦，不要搞什么 API 的字段直接对应到数据库的飞机。

@smlcgx 上了有啥意义，把原本巨大的流量入口作掉了然后去小平台有人用你的 app 么？

@smlcgx 想多了，就是那一次不能上架而已，稍微绕一下实现重新审核就行了。

曾经的移动端开发表示，用个 iPhone 就想不被乱搞真是想多了。国产 app 里各种动态代码加载，审核根本拦不住（或者是不拦）。

就之前 PDD 那个事儿，它本身就是通过漏洞去做的。iOS 上不是做不了，只是出于经济性考虑没去做而已……

@noErr 如果我手机上都没有这个功能，我当然不会有这个需求。幸存者偏差而已

@orangie 其实这个事情反过来也是一样的。iOS 也有很多顽疾一直没得到解决。不说侧载这种争议大的，就完全正面提升的一些特性，比如工作日闹钟、全局返回、开放 NFC ，就一直做不到。

很多 iOS 转 Android 只能看到缺点看不到优点，只是因为这部分功能在 iOS 上根本没有，所以成为了认知盲区

fetchData 的参数设计太烂了。这种设计字段一变动直接 gg 。排序这种场景就应该直接根据传入的字段动态生成 query 。

这是 password 不是 crypto key 。你传个二进制数据进去本来就不符合用法……

你要传二进制用普通的 hmac 别用 pbkdf_hmac 啊

gradle 我个人感觉适合构建需求复杂的中型项目。

如果构建需求比较简单，那直接 maven 就行了。

如果是大型项目，那 gradle 的兼容性会让你痛不欲生。

避免频繁的线程创建销毁呗。

上面有人提到的 mermaid 文本绘图，notion 和语雀都支持。

因为设计者并不鼓励你将不可靠的通知栏作为一个长期的信息驻留通道，如果通知没有及时被消费，就默认可以被丢弃。你应该按正确的用法使用你的手机🐶

@wanghuinet 怎么可能。我申过三个软件专利，两个软著，都是专利事务所帮忙搞的。自己只需要写个一千字出头的专利交底书