我能用 Nodejs 来做后端吗？
在春节放假前夕，业务似乎没有那么忙了。在空余时间里，又思考了下：后端方案选型。当然，作为一个 FEer，我没有使用过除了 Node.js 以外的其他方案做过后端开发，对于其他语言的思考，也只能通过网络搜索、相关帖子等信息，结合多方的探讨，来获取我需要的答案。本文也是通过结合网络上大家的讨论及自己的思考，总结出来的。
由于后端方案也是技术方案，因此下文将讨论：技术方案选型。
通常来说，技术方案选型包括了：开发语言是什么？选用的框架是什么？周边设施完善度？
那么技术方案如何选型呢？
技术本身
技术本身是具有时代色彩的，一个时代的标志性技术，往往在下一个时代已经无人问津。我们可选的技术，一般是满足这些条件的：
- 稳定性足够高；
- 已被大规模验证（非硬性条件）；
- 有活跃的社区；
- 有明确的发展规划；
- 具有自己的优势。
拿 jQuery 举例，它的存在，是那个时代的互联网环境决定的：浏览器争霸，没有同一的接口规范，导致了跨浏览器兼容方案的需要。而现在，Chrome 基本一统天下，其他主流浏览器也都在相同的规范下，表现越来越一致，这个时候，jQuery 就没有用武之地了。
技术本身需要是稳定的，换句话说，技术的生命周期必须显著长于项目的生命周期，否则你项目还没开发完，技术就不被维护了，这个时候该怎么办？ 我们怎么看一个技术是否稳定呢？常规来说，如果一个技术是周期性发布新版本，且带上了上一版本衍生的问题的修复或者新特性，并且是向后兼容的（不包括一些重大更新），那么可以说它是稳定的。
技术本身需要被大规模验证，这也可以当做稳定性的佐证。有了大公司的技术背书，用起来时才不会担惊受怕。不过这不是硬性条件。很多小公司或者一些大公司的某些部门，可能会比较激进地尝试新技术，自己作为该技术的先驱，比如：闲鱼的 flutter 团队，做的就比较早，在当时 flutter 还非常不完善的时候，就入场了。不过闲鱼的 flutter 现在确实是业内比较领先的。
技术需要有活跃的社区。有了社区，才能促进交流，才能不断升级迭代出更好的技术产品出来。没有社区，当你有问题时，你短时间内无法定位、解决问题，这对开发是致命的。
技术需要有前瞻的设想。没有想法的技术，是死的。拿 React 举例，React 每一个小版本都会解决一些遗留的问题；每一个大版本会提出新的设想，以及产生这些设想的原因。比如 React v16 的 Fiber 结构、函数式状态组件（hooks）等，它是根据开发者在日常工作中使用 React 时遇到的痛点而提出的，它的目的是让开发者更好地使用 React，更好地服务于用户。
技术需要有自己的优势。每一种技术都有它特定的使用场景的，没有银弹。优势往往与业务直接相关。比如，Node.js 的优势就是高 I/O，在 RESTFul 这种场景下，Node.js 仅仅是获取资源并返回给前端，这时是非常高效的。如果说是计算密集型的，那么 Node.js 就可以说 bye bye 了，可以考虑 Go、C/C++ 等方案。
业务
技术选型跟业务是非常相关的。
处于初创期的公司，往往是非常灵活的：它需要快速上线、快速验证结果。此时对技术方案没有特定的要求，只需要它足够高效，毕竟快速验证的过程中，可能是朝令夕改的，技术必须适应业务的节奏。
当业务稳定后，选型就需要是 “稳定” 的。当业务稳定了，技术却不够稳定，技术便会成为发展的短板。此时你会需要去修正技术方案：是推倒重做还是逐步切换？这个取决于业务。
当进入维护期时，是妥协的时候。这时的选型方案已经基本定型。代码只会越来越多，越来越乱，基本上一两年就会有一次重构。此时是重新设计技术方案，还是在已有的方案上做部分迁移，这也依赖于业务这个环境。
引用作者：
正因为技术选型和业务相关，我们能够观察到一些很明显的现象：新技术往往被早期创业团队或大公司的新兴业务使用；中大型公司的核心业务则更倾向于用一些稳定了几年的技术；一个公司如果长期使用一种技术，就会倾向于一直使用下去，甚至连版本都不更新的使用下去。这现象背后都是有道理的。
人
技术选型，最后决定的是人。
团队中可能会出现很多个声音，发出这些声音的可能是一些基层同学，也可能是与业务无关的其他同学。他们的建议可以当做参考，但决不能以多数服从少数的方法来决定最后的选择。毕竟每个人的思考出发点不同，思考的高度、目标不同，因此需要一个有绝对决定权的人。
技术的选择，本身是依托于业务的。从大的角度来说，技术应该是服务于业务的，而不是想用什么技术就用什么，因此本身需要决策人的经验。只有丰富的经验，才能在确切的业务场景中选择出最适合的技术方案。
其他
在看了一些别人的分享后，某些东西还是让我受益匪浅。
- 技术选型要慎重。再怎么谨慎都不为过。了解的例子是：由于选型不慎重，使用了当下很火的技术，在测试时确实达到了自己的要求，但当下用户大环境，设备性能普遍低下，导致上线后，性能成为瓶颈，最后不得不改为 C++ 实现。引用作者：
当时我还不是很理解，为什么公司不能更早一点止损，后来我慢慢发现，这真的是当局者迷，当一个决策作出之后大家就天然的希望能通过努力来解决眼前的问题，结果反而越陷越深。这也意味着最初选型的时候得十分谨慎，特别是选型影响面巨大时保守点会更好。
- 大公司往往更注重稳定性。比如一个技术出现后，如果有尝试的场景，会采用灰度验证或者实验，只会一步步放量，而且这个验证流程足够长。这里面的思考就是对于一个新技术的天然不信任，在技术接受程度还不够高且公司内没有人能吃透这个技术的情况下，不愿意让自己的业务做第一个吃螃蟹的人。
- 技术选型依赖于经验，经验又来源于知识索引的建设，这依赖于平时的总结和不断的新知识输入，技术是一辈子的事，必须得投入大量时间维持状态。学无止尽。
回答
所以，标题：我能用 Nodejs 来做后端吗？，这个其实很好回答：能。只要你的业务场景刚好是 Nodejs 的优势范围，那么就随意～但另一个问题是：Nodejs 能很好的服务于你的业务吗？
参考
- 技术选型那些事，文字较多，缺少分段，但整体质量不错