摘要：一边是需求的猛烈变动，一边是开发成本的居高不下。能否聪明的选择技术栈甚至生死攸关。

注：本文主要针对以数据展现查询为主的常规业务型的公司，不适用于非常规界面的项目，如游戏、视频工具等。

之前做JobDeer时，我们的整个技术团队大部分时间只有一个人，最多时也就两个工程师，一直运作得不错。除了功能上的节制，技术栈方案的选择也有很大的原因。最近新技术又起来了不少，我也更新一下之前用到的技术栈方案，这里和大家分享下。

初创期：PHP + Responsive Web

初创期是一个业务需求猛烈变动的时期，在这个阶段，任何非业务逻辑相关的开发都是极大的犯罪浪费。所以我个人觉得这时候最佳的方案就是可以自动适配电脑和手机的Web全平台方案。

这点大部分人都知道，但其实要把开发时间和成本压到最低，有很多技巧，这里给一个思路：

依托微信做账号系统

首先，直接使用微信作为用户体系（微博更适合用来分享、可能的话预存下手机号，以后做自有用户激活用）。

这样有几个好处：

不用做用户注册、用户找回密码这种和业务无关的流程

直接就具备了移动端一键支付的能力

PC上可以直接微信扫码登入

简洁的卡片化设计同时兼容大小屏

然后，全站页面通过Responsive设计，同时兼容 PC、手机浏览器、微信内嵌浏览器。

为了达到这个目标，PC端的设计要简单，尽量卡片化。微信内嵌时的导航、分享都和手机浏览器不同，需要识别设备做优化。虽然这样在产品设计时会比较慢点，但做好之后整个产品结构会非常统一，流程会非常清晰。顺便提下，原型工具Axure RP7是直接支持Responsive原型的，很好用。

保留接口，Web前后端分离

最后，Web框架的选型上，React优先；Vue、Angular其次；最低也建议要保持接口和前端代码的分离。

就是说，PHP最好只用来构建Rest接口，不要渲染页面，全部页面全部用JS来渲染。你要问写接口用Go和NodeJS行不行，当然行，不过我觉得能完成同等工作的人里边，PHP的最容易招到、也相对便宜。

这部分有一个安全大坑。某些PHP程序员并不熟悉写纯接口，经常把敏感字段返回了。要多盯下。

初创期建议不要过早启动客户端方案，除非对客户端的原生功能非常依赖。原因比较现实，那就是客户端团队是非常贵的，光是一个iOS一个Android就三五万一个月了。而更贵的是APP的安装成本，如果从Web导流到微信公众号的转化率是60%，那么到APP的转化通常在20%以下。

进阶期：ReactJS + React Native

当业务定型以后，你就会发现嵌到别人APP里边还是很憋屈的，而且微信的JS SDK的BUG经常让人无语。另一方面，对融完了一两轮的公司来说，过分依赖微信还是有风险的。需要把各个外围平台上的用户聚集到一个完全属于自己的地方，这时候我们就可以开始做APP了。

坦率的讲，要做一个90分以上体验的APP，原生方案是最靠谱的。但如果你的APP只是列表分页之类的简单结构，Hybrid（混合APP）看起来会是一个更好的方案。

之前我们的Hybrid方案用的是内嵌Html的PhoneGap+ionic，但我并不推荐大家去用这东西。

两个原因，一是在一些比较老机器上，会出现内存不足这种没法绕过的问题，导致经常性崩溃；二是JS在各个设备上的兼容性会让你调到想杀人，别问我怎么知道的。

所以这里推荐的是ReactNative的JS渲染原生控件的方案。虽然里边标签和CSS的语法都很奇葩，但是人家不卡啊，但是人家不卡啊，但是人家不卡啊。

加上如果之前的前端用的本身就是React的话，这时候可以重用不少业务逻辑。现在ReactNative已经可以同时支持iOS和Android，LeanCloud也对其做了不少支持，但在Android上的推送依然需要自己来实现。

之后可能依然会需要iOS和Android的人来开发原生组件，以实现业务逻辑特有的功能。但由于开发的工作量一般较小、而且可以通过组件机制去耦合，所以非常适合直接外包出去—— 好像又能省不少钱。

小结

粗略估计，这个方案应该足够支撑大部分的APP运营到百万用户了。ReactNative这块我只测试了一些Demo，但坑国内大公司已经踩了不少，不放心的同学可以抓来看看。

最后再说一边，初创期方案里边，从技术角度看，PHP换成别的语言是可行的，但用PHP人力成本更低。

当然你能找到一个ReactJS和NodeJS都非常资深的人，那么恭喜你一两年都都不用担心技术方问题了。所以NB点的前端动不动年薪60~80万，那是有道理的……