前端圈是把传统 native GUI 走过的路再走一遍，区别是因为从业容量的扩大有更多更菜的阿狗阿猫冲了进来。

@lolizeppelin 我知道可以自己打包……但我还是认为春哥这个偏执的操作开了个坏头，基于 OpenResty 的其它方案，比如 Kong 和 APISIX ，都无脑地沿用了 OpenResty 的约定

你需要的可能是一个心思纯粹的程序员下属

如果用的是 deb 系发行版，可以安装 nginx-extras ，会带上 lua 模块。

我也不喜欢装 openresty 打包的那个版本。主要是不喜欢打包的 rpm/deb 不符合 FHS ，用的是 everything-under-prefix 方式，程序/配置/数据/日志的目录在文件系统里还都是同样的 ownership……这样还打个屁的 rpm/deb 包。

你甚至保证不了 JB/VSC 本身的安全。

任何编程语言钻研到深处都不简单。但是有的编程语言可以让外行快速上手，有的则需要征服陡峭的学习曲线，只适合专业人士。

@mytharcher 如果业务逻辑的关注点是年、月、日这些“人为编制的序号”，那么更好的做法是抽出年、月、日建索引，检索时在索引字段上按照更符合人类认知的闭区间来筛选，而不是在 timestamp 上划分范围。

@brader 也就是说，其实 Calendar 相关的东西是跟 time 不同逻辑的数据类型，它不是物理意义上的时间长度和时刻坐标，而是人为的、人文的编号。如果要处理日历上的日期，复杂度远比“存储用 UTC timestamp ，给人看的交给前端去做转换”复杂得多。以前在一个教务系统招生模块里就是因为大意用普通的时间类型保存生日而碰到了中国实行夏时制的年份里出生在夏时制边缘日子里的学生因为算出来的“年龄”不对而无法报名的问题。

作为用户我只想用原生 app……但是想到我很少为优秀的原生 app 付钱，那么，作为雪花，我不是无辜的

另外，除了小数部分之外，23:59:59 还有个问题是表示不了闰秒。

当然，实际应用中，如果业务不是全天候的，或者在那特定一两秒的业务量本来就少，也能承受少量错误的代价，就无所谓了。

如果做比较的时候能保证传入的时间先 truncate 到确定的精度，可以用两端都闭合。否则只能左闭右开才能保证正确性。

因为早在很多年前厂家们就没动力卷桌面 GUI 赛道了，更不要说 native GUI

顺便说一下，enumerate 和 zip 不是语法糖，也跟你“没有学习面向对象的知识”无关。可以算是函数式编程（跟面向对象编程平等的另一种范式）里比较基础的用法。

如果你有这么大的数据量，但给你带来的收益让你连一年不到 5 万的都觉得存储+下载费用都觉得太高，那是不是要考虑一下这个业务的价值，换个赛道了？

那么为啥国内都要做保活呢，为啥混战了这么多年才有好几路的统一推送呢？

发行版自带打包好的内核，开启发行版更新

虽然不懂，但是……有人嫌别人 996 不够卷，想把人当机器。有人要给机器人下班。这个世界啊。

国内服务器的价格，带宽费是大头，你让它如何廉价

趁着 5.7 EoL 的机会，渲染一下恐怖气氛，做一次业务系统大改版……