我都是直接浸水里拍水下画面。。。当然，在水下时，屏幕触控是用不了的。

不，我肯定不选微信登录。因为如果是微信登录，那么，在你微信扫码后，紧接着就要你输入手机号和验证码。。。

数据量大是没办法优化的。。。

都 2023 年了，JS 连长整型都不支持。。。辣鸡

我说，你们是真的闲！有这个狗功夫，和我一样自己撸一个 utils 不好么？有 bug 自己秒修。

微服务从来没有说要多少用户量才值得上，微服务主要解决的是系统复杂度的问题。解决量的问题，是分布式系统的事，只不过微服务天然就支持分布式而已。

所以，只要系统比较复杂，哪怕只是为了能够方便维护和扩展功能，只要会用一些 devOps 工具，譬如会简单使用 k8s 来解决运维领域的问题的话，微服务就是最好的解决方案，没有之一。

我上个月接了个活，才 6w 。如果我从无到有给他搞单体服务，估计 2 个月才能搞得定。而采用微服务方案，上线时间就变成 20 天了。

需要两次反代。云服务器反代到 NAS ，一般是统一转发到一个内部 80 映射出去的高端口，譬如 20080 -> 80 。NAS 上再监听 80 端口反代到服务。

定时器每天凌晨扫一次表，符合条件的发通知就完了。写代码，最简单有效的笨方法才是最好的。

几行命令的事，有什么维护成本？

这不是音乐界的“苍天已死，黄天当立”么。

我的领克，提车出来就没有什么味道。

不是，我们腐竹都是泡好等着的，随便加。。。事实上，只要架构设计合理，程序员比厨子好做得多。

@lzgshsj 这货跳票跳了多少年了啊，会买，但不见得会玩。。。

确实不管什么游戏，都提不起劲了。玩着游戏能睡着你敢信？

哪有那么多不可以泄漏的密码。。。一般的网站，譬如 v2 ，我都是用同一个密码，谁爱扒就扒去好了。重要的密码，譬如 github ，那就一定要独立的密码且双因素认证才行了。

光看手续费的话，相当于年化 1.4 ，这个很低啦。

分布式系统你是很难保证严格按照时间同步递增的，保证单机单调递增就够了。

功能越多，用户使用效果越差。所以，正确的做法是先实现核心功能，让用户获得价值提升。然后不断改进已有功能，提升用户体验。最后，要不要增加新功能，看竞品而不是自己或用户的意愿。