不管磁盘速度，8G 内存就可以劝退了，现在如果有除了爱奇艺看剧和 Excel 以外的需求，8G 妥妥的不够用。

身份证设计之初，没有挂失的操作，原证件在多数场景下依旧能使用。少数场景下，如银行开户等要求持有最新的证件，而银行判断你是否持有新证件，是通过判断身份证上的照片、有效期实现。

多数场景下，并没有验证是否为最新证件，只验证是否为真证件。

我自己尝试过在有效期内的旧证件乘坐高铁、飞机、酒店住宿等都没有任何障碍。

资本不是数学游戏，涨跌并不是 50%的概率对半开。

扇贝跑路、叫停课外培训、老板出轨、俄乌战争、疫情出现等等，这些都不是数学上 50%可以概括的。任何一个看似毫不相干的事情，都实实在在的影响着股市。

国内股市还充斥着各种玄学，"日周月金叉，砸锅卖铁买"，当年都忽悠到了不少人，甚至当年川普当选，企业川大智胜改名字都涨了一波。

哪怕回归到股市的本质，应该反应一家企业的经营状况，这同样不是 50%的赌大小。

最后，在频繁交易下，你远远低估了手续费的占比。

珍爱生命，远离股市。有这钱，还不如买点排骨吃，不香嘛。

复杂的数据库请求，手写 SQL 基本很难避免，各个语言的 ORM 对于简单的查询支持都没问题，比如单表查询，简单的多表查询，但是一旦复杂起来，ORM 生成的 SQL 通常只是能用，但执行效率很一般。

另外就是一些关于数据库相关的特殊语法，ORM 支持程度也很有限。以我常用的 postgresql 为例，如果需要跨数据库查询，甚至需要使用 join 语句进行 update ，ORM 都无法完成，需要使用许多代码，先进行查询，数据送到应用程序内，再通过游标逐条判断进行 update 。而这些对于现代的数据库，基本上都提供了原生的支持。还是以我常用的 postgresql 为例，上面的需求只需要这样的一句 SQL 即可完成。

with t as (
select t1.identifier as tid,t2.created_at
from table_devices t1 left join dblink('self','select identifier,created_at from table_devices')
as t2(identifier text,created_at timestamp)
on t1.identifier = t2.identifier
)
update table_devices
set created_at = t.created_at
from t
where identifier=t.tid and t.created_at is not null

就我个人而言，ORM 的主要用途是提供了数据库表到编程语言的类（ golang 中的 struct ）以及数据类型的对应关系。如果不是单表操作，我更倾向于手写 SQL 。

至于 ORM 支持不同数据库之间的水平迁移，本身就是个伪需求，实际生产中，几乎不会出现底层数据库的切换。如果真的发生，本身就需要细致的测试。简单的 select/join 这种操作，原本就是所有关系型数据库都支持，并不需要 ORM 。而带有数据库特色的语法，多数 ORM 也根本就不支持，这些功能就是手写的。

^-?(?:[1-9]{1,1}\d{0,}|0)(?:\.\d{0,}[^0]|)$

但是可读性真的很差，而且速度也不快。

怀疑可能是 X-Y 问题，多数情况下可以利用语言提供的 parseInt/parseFloat 一类的方法来处理，但是又要排除 01.32 这种情况，着实有点奇怪。

我分别在 JavaScript 、Golang 、Kotlin 使用过，但是个人感觉提示的效果很一般。反而有的时候提示写的注释还不错，甚至根据上下文，还可以直接有中文注释。

@icegaze #71 同北京电信，很早以前注册的大三元，2017 年冲了 20 块钱，至今没用完。长期用来注册不知名网站以及收快递。现在也是进入了保护性停机，可以被叫，可以收短信，但是不能主叫。简单咨询了客服也是要走楼主的复开流程。

不过因为本来也不需要打电话，也没啥影响，就暂时不管了。不知道后期会不会彻底停机。哈哈哈

有些软件似乎在 alpine 上表现不一致，原因是 alpine 并没有使用 glibc 。当时困扰了我很久，得知原因后，就没用过 alpine 了。说到底还是自己太菜了。

老哥跑偏了，在工作地方，使用工作单位提供的工作工具，产出的成果属于工作单位。虽然不能说 100%合理，但也不是 100%不合理。

所以想要避免只需要下班了回家搞就行了，爱怎么搞都行。什么？非要用公司的电脑写？

@Livid #9 IPFS 这个在国内可用性非常差，之前某个项目调研期间简单测试过，全国接近 2000 个节点，有三四成彻底不可用（原因不明，暂时归咎于运营商阻断），而公共网关基本也都已经被防火墙拦截了，cloudflare 的公共网关勉强有的一用。但首次开，非常的慢。

@skys215 #7 试用了下，填写信息都是公开信息，企业名称、社会统一信用代码、法人姓名，唯一不公开的只有法人手机号

首先，一年开不到 5000~8000 公里的，不需要买车，打车更便宜。

其次， [前提是汽油车的使用成本真的比电车贵很多，这个前提是成立的吧] ，未必。电车贬值远比油车更快。同时如果一旦电池损坏，更换费用很可能达到整车 50%以上。油车哪怕三大件坏了，一般也没这么贵。电车的底盘磕碰到了，比较容易损毁电池。

再次，现在新能源补贴已经逐渐褪去，价格上是偏高的，这差价用了加油足够用好几年甚至 10 年。

最后，除非仅需求市内通勤或城市限号，否则都不建议考虑电车。电车的里程焦虑远没有解决，还需要等待社会基础设施的建设。

@lnyNice 原来是基于 http 轮询，现在上了 quic ，但没啥区别，为了解析方便可以直接丢掉 UDP ，程序会自己回落到 HTTP 轮询。消息依旧是 protobuf ，本身这个消息没有过多的验证，只是在进入直播间时有个简单的签名。直播间的消息既不需要用户信息，也不验证设备信息。

没有影响。有智能网关，依旧可以离线联动。本身也很少使用远程控制的功能。用的最多的是，小米电饭煲远程取消保温。

第二种可以满足绝大多数情况，如用用超了，可以挂账，即可调用数为负数，除非以后再也不用，否则都要先冲正。

也有可能是薪资待遇差点意思。

可以简单的把 /overlay 下面的复制到外部存储上备份，然后删除下面所有文件即可。

设备本身有足够的存储或想使用外部存储作为 overlayfs ，可以参考官方文档进行变更： https://openwrt.org/docs/guide-user/additional-software/extroot_configuration

注销后，再次注册的，应该认为是一个新的账号，与原账号无关。但是要实现这一点需要在前期设计时，没有过多采用用户的唯一标识符，如手机号。如果业务已经很多地方是通过手机号来关联，就比较难实现这样的功能了。偷懒一点，注销后的手机号，就不再允许注册。用户协议里写好，注销后的手机号，720 天内不允许注册。