@ChangJingli 忽然想到其实可以把这个常用的需求封装成一个方法，做一层抽象，用起来就能“优雅”一点了

@phithon 这些垃圾网站太特么恶心了……

@zzhzero 楼主在第一段就说了，在公司所在地缴纳。

@lurker 两代人的确分开住更合适一些，生活习惯，作息规律，各个方面都不一样，住在一起很容易产生矛盾。

Node.js 为什么要写成 NodeJs……

我也分不清楚，看得各种头大，哈哈

```js
const query = {
nickname: { $regex: nicknameReg }
}

if (id) {
query._id = ObjectId(id)
}
if (status) {
query.status = status
}

const findList = await userModel.find(query)
```

真遇到重大事故又找不着头绪的时候，心里就完全不是这种感觉了……

@noe132 这代码看着 真舒服，好评。

@sagaxu 我一同事负责的一项业务有不少 SQL 查询，前一段时间发现服务器 CPU 经常飙到 100%，排查来排查去发现一堆慢查询，最后追根溯源发现数据库各个表所有被查询到的字段都没有设置索引……

@wh469012917 他们这个智商，就告别这一行吧

@no1xsyzy 小黄鸭调试法很久以前就看到过，不过一直都没有很好地践行这个方法，工作好几年了，感觉工作的方法和习惯还是很原始 @_@

@xuanbg
@no1xsyzy

我这几天又思考了一下这个随机抽题的需求和实现思路，整理后的内容如下，欢迎指正：

前提：
1. 题库中一共有 N 道题。目前这个 N 为四位数，且在可以预期的未来，也不会有大量的增长。
2. 每道题目均为单选题、多选题、判断题中的一种。
3. 单选题、多选题、判断题的数量之比为 N1 : N2 : N3，且 N1 + N2 + N3 = N 。

需求：
1. 对每个用户来说，在每一轮游戏中，系统会将题库中的这 N 道题目，最多只有一次地、随机地呈现给用户，让用户回答。
2. 如果用户答对了题库中的所有题目，或者答错了 1 道题，则本轮游戏结束。
3. 为减轻系统负担，对于题库中的 N 道题，每次从中抽取 M 道题，全部抽完假设共需 L 次。对于每次抽取到的 M 道题，单选题、多选题、判断题的比例，尽量保持在 N1 : N2 : N3 这个比例上，也就是和这三类题目在总题库中的比例尽量相同。
4. 对同一个用户而言，各轮游戏的题目出现顺序应当不同，比如某一轮最开始拿到的题目是 1 、5 、9 、7，下一轮就不能也是这个顺序了。对于不同用户则没有要求。

大致实现思路：
1. 由于题目数量不多，可以在数据库中给题目增加一个序号字段，用自增的正整数来标记每一道题目的序号。
2. 在每个用户的每一轮游戏开始前，将所有题目的序号按题目类型进行分组，发给用户。例如用户收到的数组是
arr = [[1, 5, 7, 10, ...], [2, 3, 4, 8, ...], [6, 9, 11, 13, ...]]，那么 arr[0]、arr[1] 、arr[2] 分别是所有单选题、多选题、判断题的序号。
3. 由于在一轮游戏中，每一次需要抽取 M 道题目，那么可知需要抽取单选题的数量为 Q1 = M * N1 / N，多选题为 Q2 = M * N2 / N，判断题为 Q3 = M * N3 / N 。
4. 前端在 arr[0] 中随机抽取 Q1 个元素为单选题的序号，在 arr[1] 中随机抽取 Q2 个元素为多选题的序号，在 arr[2] 中随机抽取 Q3 个为判断题的序号，并将这三组序号分别从 arr[0]、arr[1]、arr[2] 中移除。
5. 前端用这三组序号，从后端抽取 Q1 + Q2 + Q3 共 M 道题目并呈现给用户，让用户答题。
6. 如果这 M 道题用户全部回答正确，则重复第 4 、5 两步，继续抽取新的 M 道题给用户，直到用户答对所有题目，或者答错 1 道题目。

上面这个思路把抽题功能的主要部分交给了前端来做，感觉这样后端的负担可以小一些，也是对后端不够熟悉，就选择了这么一个相对比较取巧的办法。

PS：在整理这个需求和实现思路的时候，发现自己的表述的确不够清晰准确，就上面这段文字，来来回回修改了好几遍，用了两个多小时才完成，就这还是感觉表达得不够好，知易行难呐。

@yoa1q7y
@code4you
看了看 typeorm，prisma，sequelize，这三个 repo 的 issues 都是 1200+、1300+，哈哈

@Smash GitHub 的搜索结果默认是按照“Best match”排序的，你切换成按照“Most stars”排序，typeorm 就排第一了。

@fox0001

1. 光盘里放的是执行程序，不审查源代码，只审查最终产品。
2. 这一点倒是没有要求，这么说的确弄个一键部署方便很多。
3. 只是审查用，并不是长期运行，所以这些怎么方便怎么来。

@ksc010 对，需要实现的就是你这样的效果，我去研究一下。

@cadmuxe 非常感谢你的提问，很详细，我一一回答一下：

1. 不是 Live 光盘，是用来提供安装包和运行环境的光盘。可简单类比为以前的电脑游戏光盘，需要先安装相关依赖，然后再运行光盘上的游戏。
2. 见前一条。
3. 是要制作成一个可安装的程序，离线部署到用户的电脑上，不对外提供服务，仅供用户在本机使用。