Express.js 是 Node.JS 诞生之初，最早出现的一款框架，现在仍然很流行，作者是 TJ。 Koa.js 是一款微型 Web 框架，写一个 hello world 很简单，但 web 应用离不开 session，视图模板，路由，文件上传，日志管理。这些 Koa 都不提供，需要自行去官方的 Middleware 寻找。然而，100 个人可能找出 100 种搭配。 Egg.js 是基于 Koa.js，解决了上述问题，将社区最佳实践整合进了 Koa.js，另取名叫 Egg.js，并且将多进程启动，开发时的热更新等问题一并解决了。这对开发者很友好，开箱即用，开箱即是最(较)佳配置。 现在 TypeScript 大热，可以在编码期间，提供类型检查，更智能的代码提示。Egg.js 不支持 TypeScript，此时淘宝团队在 Egg.js 基础上，引入了 TypeScript 支持，取名叫 MidwayJS。 TypeScript 是绕不开的话题。 基于 Express.js 的全功能框架 Nest.js ，他是在 Express.js 上封装的，充分利用了 TypeScript 的特性；Nest.js 的优点是社区活跃，涨势喜人。缺点是，如果从来没有接触过 TS，刚开始学习曲线有点陡峭。 总结 Egg.js 和 Nest.js 相对于 Express、Koa 做了更高层面的封装。 好处是一些需要配置的东西开箱即用，而且写法相对统一，团队协作成本低。 坏处是灵活性降低，扩展性受到约束，一些特定的业务需求实现起来比较麻烦。 参考链接 koa.js,egg.js,express.js 三者有什么区别？

考虑这样的场景：

构建后的目录需要放在客户机器服务的指定目录下。例如之前的请求是 /assets/a.png 可以访问, 现在需要改成 /a/b/assets/a.png 才能访问，这时候应该如何处理？

哪些方面需要选型 框架（React, Vue, Angular） 渲染方式（SPA，SSR，SSG） 选型依据 基于团队考虑 成员之间差异 团队由许多的个人组成，每个成员的技术能力、技术偏好存在一定的差异。所以在选型时，要考虑这些差异加以权衡。 是否有助于团队成长 团队如同一个孩子，挑食会导致影响不良，均衡的技术栈能让人更好地成长，所以技术选型要考虑是否有助于团队的成长。 如果团队都是 React 项目的，可以考虑在一些边缘项目或者简单的 C 端项目引入 Vue，对整体技术体系冲击不大同时团队也有了 Vue 的能力储备。 与已有的整体相协调 要考虑迁移成本。 新的选型最好与旧体系相协调，协调意味着新、旧能够共生，而不会产生较大的破坏力。 新的技术体系引进来之后，是否要对老项目进行迁移，迁移会产生多少的成本。 选型处理要与团队已有的技术栈相协调之外，在公司范围内，选型需要考虑与公司整体的技术栈相协调（不一定要强一致调）。协调的好处有很多，例如：可复用性方面，其他团队的轮子可以直接接入到项目中，本团队有的轮子可被其他团队复用。 长期可维护 要考虑社区活跃度，维护团队、文档 结合项目特点 偏逻辑还是偏展示 是否需要兼容老的浏览器（IE） 是否多端显示（移动端、微信小程序、支付宝小程序） 参考文章 前端技术选型最佳实践

他是运行跨平台设置的和使用环境变量（Node 中的环境变量）的脚本。 cross-env 解决什么问题 当我们使用 NODE_ENV = production 来设置环境变量的时候，windows 和 其他 unix 系统 bash 的命令是不一样的，例如： 在 windows 上 使用： “SET NODE_ENV=production && webpack” 在其他 unix 系统上使用： “EXPORT NODE_ENV=production && webpack” 因此，就可以使用 cross-env ，可以理解为它能够将命令兼容于 windows 和 unix 。这样就可以 unix 方式设置环境变量，同时在 windows 上也是可以兼容的。即用一行 uinx 命令，再在不同端执行。 “cross-env NODE_ENV=production && webpack” 一句话总结 cross-env 也可以理解为一个 npm 的插件，他可以处理 windows 和其他 unix 系统在设置环境变量的写法上不一致的问题。 参考文章 对 cross-env 模块的理解

整理一下使用 node 写一些小工具时会用到一些交互式命令的相关库