iceprosurface

至于 console 1212 因为 await 的原因应该是要等到整个微任务队列清空以后才会执行的吧，这种代码我觉得纯 八股文，如果要保证时序，应该从业务考虑

你这段代码：
```
const getNum = () => {
console.log("getnum 执行")
return new Promise(async (resolve,reject) => {
console.log("promise 开始")
resolve(1)
addMicro("haha")
console.log("promise 结束")
addMicro("===")
});
};
```
执行到 addMicro 的时候下一个微任务队列是：

[addMicro("haha").then, addMicro("===").then]

我记得理论上 Promise.resolve().then 的回调函数会在当前同步代码执行完毕后加入微任务队列的。

关系型数据库的话可以考虑 tidb cloud ，查询量不大的话应该也够用

@MrYELiex 值得肯定是值得，能在凑点折扣也成嘛，没有就算了

@miserist 教育版就算了没必要白嫖了，都用这么多年了

@alphardex 很漂亮，但是阅读体验太差了，感觉只适合做个展示

对于问题 1：
要么直接用 option 要么直接用 setup ，目前看这个写法出了麻烦没什么好处，如果是老项目我建议不改，如果是新写，就不要沿用了。

对于问题 2:
对于老项目，重构价值不大的，你领导说的对，不要改，对于新维护，维护频率高的，你可以据理力争改改

对于问题 3:
对于 api 请求我的观点是多少行都无所谓, 应该尽量自动生成，有类型（ PS: 我们项目里面的请求文件目前有 13300 行, 反正 idea 自动折叠无所谓,而且一般不用点进去看）
如果手动写的，确实应该是分模块封装起来用，你领导说的也对，过早的优化是没有必要的

对于问题 4:
按照你们现在这个情况，你领导说的对。因为要执行需要满足下面几个条件：

1. 严格执行 review ，且 review 要求高，必须是交叉 review ，review 不通过不给合并
2. 项目时间安排合理
3. 整个前端所有人达成共识才能执行的
4. 要有对应的规范指南，每个新人进来前两天必须熟读
5. 所有项目的 code style 、lint 规则一致