外观
技术选型
技术选型要考虑的点非常多。
技术偏好
技术选型时需要考虑团队成员的偏好。大体来说：
- 偏好首先必须是正确的：可以不是最优的，要考虑落地难度。
- 尊重团队的整体偏好，如果团队整体没有明显的指向性偏好，应重点考虑团队骨干的技术偏好。
历史积累
团队的历史积累是技术选型时要重点考虑的点。这里说的历史积累不只包括成员的技术储备，也包括团队的技术文档等资产储备。
特别的，如果团队成员整体对新事物的学习能力较差或者学习意愿不强，历史积累就显得尤为重要了。
生态环境
基本的业务功能其实大部分语言都可以实现。但是如果你要做一些比较复杂的任务的话，利用好特定语言的生态就显得尤为重要了。
比如说 PDF 文件的处理，比如 AI RAG 功能的实现，这些并不是所有语言都擅长，语言不合适的话需要大量造轮子，不仅浪费大量时间，而且也未必有能力最终实现功能。
不局限于单一编程语言
自微服务兴起之后，很多项目都已经不局限于单一语言，而是多种语言同时使用了。
这样做的好处有很多，最主要的是可以在使用自己熟悉的编程语言的同时，利用好其他语言的生态或者性能优势。
当然，跨语言的方式不只有微服务或者API交互一种，有些工具/库提供有 cli 命令行支持，或者也可以直接通过文件系统来间接通信（比如生成本地文件给另一个程序读取使用）。
上手难易程度
不仅要考虑相对团队成员水平而言的相对难度，也要考虑技术栈本身的绝对难度。不要有一种难度越大的框架就越好的偏见。
特性不等于优点
举几个例子：
Next 和 Nuxt 支持基于文件系统的路由方式，这种特性，会让你省去手动定义路由的时间，但是相比于失去的灵活性，实现很难说少些几行路由定义算什么优点。
前端有一些库/框架可以帮助你避免手动写 import（由工具帮你写），这个特性会导致从源码角度来看存在一定的黑盒。我个人更偏好显式 import。
黑盒
有些黑盒的存在可以帮助我们提高效率，这无可厚非。但是如果一个框架存在大量黑盒的话，想对其做定制的难度就会很高。
动手实验
如果你不信的话，你可以尝试新建一个项目目录，只允许创建一个 package.json，然后再创建一个 projects 目录，在 projects 目录里新建多个子目录，每个子目录对应一个 nuxt4 项目（不可以含有独立的 package.json 文件），你试试看如何将同时启动他们的本地开发服务。
你可以任意使用 AI 来尝试解决这个问题，它们也解决不了的，因为这首先不是一个常见问题，网络上没有解决方案，其次黑盒不只是对开发者而言的，黑盒也会影响 AI 的发挥。
ROI
ROI 是英文 Return on Investment 的缩写，表示投资回报率。大部分情况下，有一定学习成本的小众框架的 ROI 都是偏低的。
这里我们不谈小众框架，我们谈一谈微前端这个技术方案。
微前端方案利弊
“微前端”这个概念刚出来的时候火了一阵子，现在继续提“微前端”的人已经很少了。从招聘软件的职位描述里可以很明显的感觉到几乎没人提“微前端”了，这是用脚投票实打实得投出来的结果——因为大部分项目都不需要使用微前端。
微前端解决的是什么问题？大部分人会这么说：
- 将大项目拆分成小项目，避免巨无霸项目的编译耗时问题。
- 允许每个小项目使用不同的技术栈，方便逐步升级。
- 每个小项目可以独立发布，风险隔离。
- 多个前端项目在用户侧交互起来像是一个前端项目。
如果再和“不使用微前端，直接使用多个独立前端项目，彼此之间通过 URL 跳转”这种朴素方案对比的话，其实就只有最后一个优点是成立的了。
那这个优点是我们的业务痛点吗？好像是的。但是让我们来看一个场景：你随便打开一个你觉得最复杂的手机 APP 或者PC端的 Web app，你点进去之后你平时经常浏览的页面有几个？根本就没几个页面！而且事实上就算把不常访问的页面都算上，一般也没几个页面。实际上，用户对于低频访问的页面，是不介意多一次明显的页面跳转的，用户只对高频访问的页面的交互体验敏感。比如，对于一个互联网金融项目而言，用户做风险测评和做账户开户这两个操作都是低频操作。大部分项目，完全可以这样设计：
- 高频访问的页面放到一个独立项目里。
- 低频访问的页面按相关性拆分成多个独立项目。
这样就可以避免微前端方案带来的一系列弊端了。
默认优先
典型例子是：npm、yarn、pnpm的选择，以及 JavaScript 语言的服务端运行时环境 Node.js、Deno、Bun 的选择。
新的竞争者之所以能参与竞争，一定是有其擅长的优点的，但是这些都是开源项目，除非一个项目已经不再维护了或者有很多历史包袱带来的掣肘，否则很多优势都只是暂时的。
默认的，可能不是最好的，但往往都是最省心的。