前言
最近项目中使用Node开发，Nest.js作为框架，TypeOrm连接数据库，期间遇到一些坑，这里记录一下。
问题
1. 插入数据之后返回的ID集合，ID相同
在TypeOrm插入数据库操作的返回结果中，identifiers字段会是插入数据的id集合，预期情况应该是这样的：
1 | [ |
但实际开发中发现是这样：
1 | [ |
因为，业务中后面要根据返回的ID值给其他数据做关联，所以返回相同ID会造成异常。
查看了github，有相关issue，但是一直处于open状态：https://github.com/typeorm/typeorm/issues/2131。
最后临时方案是采用在后面操作中，用id+数组index的方式，拼出id。
2. JavaScript对数据库中int和bigint的区别对待
刚开始开发中，线下测试数据库id字段采用int，数据库SELECT操作返回的结果是Number，但是使用bigint，数据库返回的为String，初步猜想是因为bigint的值范围会超过Number，所以采用String。
但是这样会对我们业务产生巨大影戏那个，一方面，DTO校验会无法通过，另一方面，问题1中的业务逻辑会受影响。
经过查找各方文档，解决方案是在数据库连接配置中配置：
1 | "supportBigNumbers": false |
可以配置这个的原因是我们的业务ID距离Number的上线远远达不到，所以可以用这种方式让
bigint也返回Number。
但是这样配置，TypeOrm插入操作的返回值中的identifiers字段中的id还是String，所以问题1中的处理方式也要对String进行parseInt操作。
3. 数据库版本区别问题
测试上线时，发现功能无法使用，测试环境正常，经过线上测试库分别连接测试定位后，发现还是identifiers，返回的id为undefined。
线上数据库版本为5.6，测试数据库版本为5.7。TypeOrm的insert()生成的SQL会有插入id的操作，值为默认值，5.7中可以正常插入，5.6中会插入异常，返回值为undefined，导致报错异常事务回滚。
经过测试，插入数据库操作时，id赋值为null可以解决，后更新上线，因为部署问题无法上线，等待后续上线后检验时候还存在问题。
4. TypeOrm数据库配置问题导致编译慢
项目刚开始开发时，每次本地编辑十分慢，查找文档等发现问题是配置原因，刚开始数据库的entities配置项是这样的：
1 | "entities": ["src/entities/*.ts"] |
编译时候应该是先会把ts文件编译成js，所以耗时比较久，后改成
1 | "entities": ["output/nodeapp/kid-mis-backend/src/entities/*.js"] |
直接使用编译后的js文件，编译速度大大提升。
总结
后端开发和前端开发有很大的区别，各种解决问题思路不同，后端部分还有很多需要我学习的地方。