@nomagick #23 很多项目已经逐渐完全放弃 cjs ，也不提供 cjs 产物，全面转向 esm 是必然的事。
这跟 esm loader 没多大关系，主要是几万个 package 一开始不愿意支持 esm ，毕竟它还能跑对吧。
有些库作者激进地 esm-only ，用户又要问为什么不支持 cjs ，这十年是用户与作者们在拉扯，nodejs 对此是没什么办法的。
esbuild 之类的工具尽量解决历史遗留问题，nodejs 没必要重新实现一遍，因为未来某个时间点会放弃 cjs 。

另外现阶段还是建议用 tsx(不是 react 的那个 tsx) 运行 ts 文件，直到 nodejs 没有这些问题了再说。

tsc 虽然能编译成 js ，但这不是它该干的活，毕竟它只是老老实实地把 ts 翻译成 js 没有任何优化，tsc 用来检查类型就行了。
我的做法是 "moduleResolution": "bundler"，后端使用 tsup/tsdown ，前端使用 vite 。
虽然官方推荐显示指定扩展名，但说实话完全没必要，未来真有必要也可以写个脚本全加上。

@mkoijnbhu #74 那是你们学校执行得好，本来就只应该看硬指标。你可以谷歌搜一下"保研 献血"，我大学时三位同寝保研的都去献了血，献血有优先权几乎是人尽皆知的潜规则。

@forisra 能透明公开地卖血也没什么不好的，不管是对缺血的还是卖血的，现在这样钱都被一层层中间商和血站给卷走了，依然严重缺血，卖血的被层层剥削。

前端加密解决的是敏感，而不是安全 (无法以任何手段保证绝对安全)，即原始明文是否应该发送到服务端，对用户来说是一件敏感的事。 (虽然服务端并不会储存原始明文，csdn 这种傻逼公司很好地说明了储存明文密码不会带来任何益处反而后害无穷)
前端加密只需要任何一种不可逆算法就行，不要考虑太复杂的东西。

@Chalvh #55 我说的是半强制，即有的选。
大学生为了学分去献血是挺常见的事。如果是保研的，不献血就少十分，最终所有人都得去补这十分，谁也不想因为这种可笑的理由落选吧。像这种事其实很多，特别是越来越卷的当下。学校都有献血指标，体现出来就是故意制造障碍或者区别对待让学生被自愿献血。

对程序员这个职业，我觉得 5-6 小时会比较合理，下班了还可以上 github 保持精力继续写，可以形成一个良好的正循环，保持持续向上的技术迭代。
但某些资本方不会这么看，他们希望程序员老老实实地在公司做事、浪费时间、内耗、KPI 化，他们不在意你的技术提高到什么程度，只要够用就行，最重要的是要驯化你，要绑死你。
我问过几个活跃的贡献者为什么都是在半夜提交，他们说至少 10 点才能下班，回到家处理好杂事打开电脑已经 12 点了，明天 10 点多又要开启新一天的循环，只能在 0-2 点这个时间段提交。
我悲观地认为中国与美国的差距会永远这么持续/扩大下去，直到有一天大厂没有了 996 。

@pkokp8 #34 之前献过一百次也没用，血站只认近期是否有献血记录
地方献血条例大于国家政策
https://stcn.com/article/detail/1302313.html

@sundev 1998 年颁布的献血法规定了优先用血权和互助献血，这不是前置要求，但 10 年开始就变味了，变成了强制措施，任何地方想要用血，先拿血过来换，不然就等死你。

@nxuu 献血的人越来越少，是血站管理不当，灰色地带侵蚀白色地带，恶性循环导致正常人都不会去献血。献血者不希望折腾自己拿个几毛钱几块钱小礼物，然后被几十块几百块甚至上千块卖掉，他们帮不到想帮的人，从中中饱私囊的人导致了现状，而这个现状只能从上到下去改变，普通人无能为力。除非医院强制要求，否则离献血车远点就是了。
另外现在大学/中学普遍开始半强制献血了，真是作孽。

女方的支出项到底是什么，我很好奇。
按照之前帖子的单方面说法，女方看起来是那种花钱不过脑子以为自己是什么公主转世，而她的父母很明显把她惯坏了，你也把她惯坏了。这里的支出明显存疑，女方一个月花掉接近一万块到底在干啥。
现在的困境，是你的收入无法满足她的欲求，我很好奇是什么促使了你二人结婚，双方的价值观看起来是不可调和的。
最惨的应该是孩子，孩子的开销只占据男方的 24%，家庭一分钱没存下来，让我感觉这个孩子是生下来为了过苦命日子的。

@newtype0092 #10 `随机获得一条数据`这种需求，一般量级也就几千到一两万，调用频率不高就别管了。
拿 mysql8 试了下，2w 条是 20 毫秒，如果用
JOIN ( SELECT CEIL(RAND() * (SELECT MAX(id) FROM `xxx`)) AS rand_id )
替代 rand() 可以快 20%左右
不超过 5w 我是无所谓，这种奇葩需求一般也不会有大量数据。

@Gilfoyle26 #6 获取一条随机数据是很正常的需求，例如随机点一首歌，随机找一位幸运观众 (假设不想使用任何手段的缓存)。

------
其实 rand() 的 O(n*log(n)) 开销在部分场景还是能承受的
换聚簇索引或者抽样可以快一点:
https://stackoverflow.com/questions/40273291/sql-select-a-random-row-in-o1-time
https://stackoverflow.com/questions/60019318/sql-command-to-include-a-random-row-from-the-table
如果 ID 连续还可以通过两次请求实现 O(1), 但额外请求开销值不值就另说了。

信息量太少了，技术栈 python 等于没说，起码也得说下框架和数据库，内存和 CPU 占用情况。
我瞎猜个数据库/文件连接没关闭。

@xided #4
···js
const data1 = [
{
type: '长方形',
value: { width: 100, height: 100, length: 200 },
dateTime: '2025-01-01 12:00:00',
},
{
type: '三角形',
value: { angle1: 30, angle2: 60, angle3: 90 },
dateTime: '2025-01-01 12:00:00',
},
]

const data2 = [
{
type: '长方形',
width: 100,
height: 100,
length: 200,
dateTime: '2025-01-01 12:00:00',
},
{
type: '三角形',
angle1: 30,
angle2: 60,
angle3: 90,
dateTime: '2025-01-01 12:00:00',
},
]
```
有两种方案，看你自己选择了，我喜欢第一种。

B+树、最左匹配，几乎是面试必考题。

如果用不到复杂聚合查询，json 是最好方案。