@GuuJiang 换一个思考方式会不会好一点：我只是借用了一个 64bit 的数据类型（这个类型很常见）并没有把它当作数值进行计算，实际上这也没有意义；
而所谓的字符串也好，我这种做法也好，实际上都是身份证号的一种编码方式，相对于 144bit 更加节省而已～

@wxf666 还是不行，很多地方不便于使用 无符号数，那么实际上可用的值最大只有 2^63 ，溢出了

@wxf666 视为两位十进制数这点我没想到，我光考虑前面那种了🤣

话说大家真的有遇到过身份证号模糊匹配的需求吗，这点有些好奇，我确实没见过…

@oneisall8955 @IvanLi127 如果是字符串正则查找，那确实是不行了，不过我没见过这种场景；允许存错误的身份证号这就没办法了🤣除非在一开始明确提出我不会考虑这种需求

@wxf666 可以是可以，主要会不直观，如果只是简单去掉最后一位，不影响以十进制方式阅读

@janus77 主要是便于用数值而非字符串类型存储，19+字节变成定长 8 字节吧，我觉得对于某些量大的场景还是很划算的。

@eason1874 只有在系统边界将身份证号类型装换成字符串类型传输的时候才需要计算和补足最后一个校验码，校验算法非常简单，所以应该不会消耗过多的 CPU

tab all 也不是时间排序啊

好玩

@hankli 即使是最新的 Java ，特性和 Kotlin 比也有很大差距。更别说很多项目不让你动 JDK

感觉写 SQL 补全还得是 Datagrip

@ysc3839 行尾反斜杠好像是 GitHub Flavor 里的

比如说我在 Redis 里存了 protobuf…lua 就不太方便了

在你不想 /不便于使用 lua 时，事物还是有点用的

@pastor 使用零值就没有麻烦了吗🤣

@RedBeanIce 用 Unix 时间戳也不是不行，这个问题和时区也没什么关系，就是 RFC3339 是明确的标准，时间戳就稍差点。
我的重点是不管用哪种，前端都需要处理，不是说用时间戳前端就省多少事

我倾向于是否允许 null 跟着业务走，尽量不用零值做特殊值，null 就是 null ，0 就是 0

@Oktfolio 我这边的做法都是代码中只出现时间类型，Java 里用 Instant Go 里用 time.Time ，系统边界尽量用 RFC3339 字符串传递

@GTim 说的好像用 timestamp datetime 前端不用格式化似的。啊，你们不会都拿 String 传时间吧

没必要一个对象从头捅到尾，该转换转换就好了

@snw 无视掉初始 RST 就行了吧，不过···似乎可以先 ACK 了再 RST 掉······这手段确实是扭曲