先破除幻想，便捷性和安全必须做取舍，举几个例子。
1. 2FA / n-FA 启用与否
- 多因素（多步骤）验证，你可以理解成 key->key->key 钥匙链，少一个都过不了
- 安全性换来了什么，你弄丢某个 key 都会导致没办法验证（所以都是 2FA 而非 nFA 是一个现实情况的取舍）
2. 绝对离线（ KeePassXC ）和多端同步（ 1Password/Bitwarden ）
- 上云就意味着你的密码可能通过不信任的信道传输（不管传输加密与否）
- 1P 宣传自己端端是 zero-knowledge 加密，你能自行验证吗？验证的代价是会影响传输的性能
3. 依赖 Chrome 的密码本或者系统钥匙串，还是必须独立密码管理软件（上面几个）
- 前者当然用的爽，无感填充强密码还帮记录，依赖 DPIPC 就意味着用着系统会话窗口对密码全接管，代价是 IPC 被 hack 就完蛋。
- 前者多一层鉴权，但即便是你自己用着信任的电脑也要每次输入密钥（ PS 密钥还不能明晃晃放到桌面上，我在回复里就看到有人这么干，不做评价）。

@areless #43 嗯我同意你说的理论是理论，实际是实际，我也很费解自然光强度下的问题，这个视频作者是科普理论的，论文中训练 cnn 分类内容也全略去了（可能是作者觉得这个和人脸识别正交，可以用其他方法）。所以你说的假的就是假的，那就是说都是存视频（简单比对），然后后台风控逻辑起作用吗。

@gdfsjunjun 个人感觉，支付宝更考虑便捷性，易用好用，幼稚园小孩和岁数大的不识字老人都能用是最希望的。而钉钉更考虑安全性，PS 如果你是老板，你希望员工拿照片刷脸然后可以虚拟 ip 定位打卡吗。所以钉钉慢是正常些。。。

@areless #37 测测微信和支付宝？

我猜测支付宝是牺牲了安全性换便捷（或者引入其他维度比如 ip ）。微信用的应该是腾讯优图开发出来的算法，各种随机组合颜色测反射+动作模拟。
正好前两天看到一个蛮好的博主视频讲解，可以看一下： http://xhslink.com/a/Tszp4m3YeNw3 。解释还是很详细的，为什么要多种颜色，怎样应对视频录制/照片模拟等常见伪造手段。

@geelaw #18 对于 git 的 commit hash 我看完后的理解：那用 sha-1 或者 md5 都可以吧？虽然不抗碰撞但是这种场景下不会有人去费劲构造，所以至今不需要更新散列函数。而对于 Git commit 的签名（之前没有仔细想过是对快照+元信息而非 commit hash 签名，~~GitHub 上这个 verified 标志挂在 commit hash 上给了我一种错觉~~），我倾向于理解为 git 加入这种签名更像是一种代码提交者的“宣告”（这是我用这只笔写的），并没有意图用数字签名来溯源验证提交者，如果私钥泄露就相当于自愿放弃之前提交的宣告，但对于代码提交本身是无影响的。

@leejinhong 想请教一下用 redis 去重是什么概念

后悔没早看到，今天调一个奇怪的路由编译报错，才发现是 tokio 的 mutex 和 std mutex 混用，后者跨 await 导致的。

代码核心逻辑就是混淆地址-查询余额-直接转出，尼玛的人家后两个演都不带演，你就真转账啊。

GPT 都给你分析出来 fetchMempoolData 就包一层，encode 包一层，startExploration 再包一层，三层饺子就下锅了。

我只想看看有没有推荐赛博乔伊的

2024 是未来最好的一年。

8500 出相机吗？
@orioleq

仅考虑书
稍微理解《 The Little Schemer 》
多点理解《 The Little Typer 》
深入理解《计算机程序的构造与解释》 SICP

深浅选择可能影响眼睛疲劳度，配色方案纯看个人喜好，我自己用 Catppuccin 配色方案，提供了中等对比度的浅色--->深色四种方案，白天晚上自动配一下。

@wolfie #15 我觉得这个方案合理，为了可读性半解耦子函数还不如定义一个 helper 写明白，易于维护。

怀疑楼主说的把“λ ...... {...} 函数体”后置是单子组合的写法，但这和你需求的 application 先于 define 不一致啊。

没太看懂问题，函数式编程里也不能自行推断匿名函数行为

win 上开始用 utools 以后习惯"win+spce 搜索-回车"，迁移到 mac 系统也一样“command+space”，桌面只存少量截图、参考文档。

我也赛博邯郸学步了，这样按 ctrl 对于我这种 ctrl/command/option 都要频繁使用敲公式的反而更麻烦。现在只能感谢 emacs 和 vscode 插件作者救我狗命。