9
背景
Egg 已经保持在 2.x 版本很久了，一开始的想法很简单，我们在企业内部需要同时维护 1.x 和 2.x，如果过早的发布 3.x，会带来较大的升级成本，而且在那个时候看有很多希望放到 3.x 的特性，不如憋着一个大招，但我们就是这样一直在顾虑着很多东西，不知不觉已经好几年了。
到现在这个阶段，Egg3 规划的很多特性在 Artus 去实现了，而它的架构跨度太大，要基于它封装上层框架 Egg3，还有很多事要做，譬如新的 Router、新的 Multipart 等等。
但以此同时，Node.js 版本已经从当年的 8.x 变为 16.x 了，我们的很多底层类库也逐渐不再支持低版本，导致我们一些安全漏洞无法升级。
我们在对待其他类库开发者时，不都经常劝他们不要吝啬版本么，我们也应该反思下，不要太纠结了 3.x 这个版本了。
思路勇敢点，分 2 个里程碑：
- 先发一版 Egg3.，目标是在尽量少 Break 的基础上，尽可能小的升级成本，把一些困扰 Egg2.0 较久的问题先解决掉。
- Egg4 才是基于 Artus 的，这个不追求完全的兼容性，而且面向未来的去勇敢的 Break。
如果不这样的话，一方面基于 Artus 的 Egg 版本会束手束脚，一直要考虑 Egg2 的升级平滑度，另一方面原来 Egg2.0 的用户会一直被锁死。双输。
目前看到可以在 Egg3.0 包含的特性：
- 升级 Node.js 最低版本为 16.x
- 16.x 在 2022.10 进入维护期
- 但 18.x 由于对操作系统有要求，很多存量应用很难升级
- 升级 loader 支持异步加载配置
- 这是一个呼吁了很久的特性，只需修改 egg-core 里面的 loader 方法改为 async function
- 该特性对应用层不算 break，仅仅会影响到上层框架，需对应的修改 async function 即可，影响面相对可控
- 其他
- 评论区可以讨论下，譬如要不要默认关闭 static 插件
- [ ] some task
- [ ] PR URL
