【混合开发】到【大前端】到【大前端++】
大纲
定义
大前端++；加什么？
根据多年开发实战经历，暂时的定义是加原生系统高性能部分，加硬件模块
当前搞开发的环境，尤其是前端开发工程师，面对的实际业务环境已经不是单纯的网页和网站和浏览器或者某类浏览器了。而是多终端，多系统，多平台，多分辨率，多场景等等复杂的业务开发环境。这个对前端开发工程师的要求就不能局限在前端技术方面了，多年的实战经验可以很清楚的感知到，业务需求在前端开发完成，测试完成，部分研发环境的投产完成后，进行业务规模爬坡的时候就碰到了实施现场的各种意外情况了，比如网络环境问题、硬件厂商缺陷问题、多种系统问题、多个系统版本问题、多系统多种浏览器内核问题、浏览器版本问题、应用的兼容性问题等等；
又因为每个硬件设备成本都是居高不下的，所以很难统一硬件厂商和硬件性能，也无法统一系统以及系统版本。这就对前端交互设计和前端工程师解决问题的能力要求特别高。综合技术素质要求就更高了，但根据目前的技术、业务等只要用户终端规模增长，可以预见这些场景情况问题会层出不穷。直到产品和服务的尽头。
企业基本培养不出这样的人才，因为开发工程师的流动性大都是两年一跳，两年时间也许只是刚好熟悉某个部分的业务开发而已，而目前的就业环境企业也没这个投入去培养人。所以这就导致了服务后台+大前端+原生系统+终端硬件的业务模型碰到的问题都会导致业务规模增长困难，很多问题在投入不足的情况下就无法解决，找不到对应的解决方向和解决目标，也没办法承受从头再重构整个业务应用的投入。于是就会走入等死的路上无药可救。
而就多年实战的经历也印证了很多大公司的服务后台+大前端+原生系统+终端硬件业务结构被场景情况（后续简写为场况）问题拖累到项目消减预算或者干脆就取消了。
问题定位清清楚楚，估计都知道问题在哪？
但解决问题的路径几乎都特别难下决定，投入方不可能在既有规模不达标的情况下追加更多投入，产品研发方不可能在投入既定的情况下停止业务研发而专门搞技术基础建设，更不可能在没有营收的情况下大规模变革技术结构重新换一批工程师，代价太大，代价大是一方面，更多的考量是要是重构技术基础建设之后业务规模还是增长不起来，上上下下都没法承受了！
这就是服务后台+大前端+原生系统+终端硬件无法翻越的大山，规模增长导致场况问题非常多，追加投入能否解决问题未知，不追加投入又无法解决场况问题，规模增长又导致问题规模变大变多。这个问题也是项目增长中避免不了的问题。
理想的解决办法就是保留既定的大前端业务不变，在场况问题上进行大前端+原生+硬件的各种适配方案。但这个也是最难的地方，因为没有这方面的技术人才。是的，没有哪个技术人才去学这么多开发技术，即没有必要，也没有收益。比起学这么多技术解决现有的规模场况问题，用成熟的技术跳槽到另外一家公司拉高待遇可能性价比更高。
这也是项目业务规模增长的致命矛盾点，规模起来带来的规模增长问题需要改变既有的技术栈结构，改变既有的技术栈结构需要更新当前开发团队技术开发人员，就算追加这些技术投入也无法保证规模问题能解决，规模增长后又有新的规模增长问题，好吧！无限循环套娃了。如果项目规模总是能稳住正向营收，那一切都不是问题，但问题是正向营收的稳定性是不可持续的。这个是市场规律！
所以如何选用合适的技术栈框架结构就成为了所有人头疼的地方了！
经过多年的项目实战我个人推荐的技术栈方向是前期Electron+vue+多终端+多平台解决业务快速验证的0到1的问题，这个技术栈向上兼容
在规模增长后导致的场况问题开始之后变更技术栈为Flutter+vue+多终端+多平台解决业务增长后导致的原生、硬件等问题，这个技术栈向下兼容
如此就能在既定前期开发人员既定的情况下，追加一位或者多位Flutter开发人员即可，其他人员基本不变，刚开始追加一位即可，根据场况问题规模在衡量追加人员投入！
如此也就完成了大前端到大前端++的技术栈人员升级，也兼顾了硬件系统的上限和下限。
推荐理由
postman在国内使用已经越来越困难： 1、登录问题严重 2、Mock功能服务基本没法使用 3、版本更新功能已很匮乏 4、某些外力因素导致postman以后能否使用风险较大 5、postman会导致电脑卡顿，而且使用的功能越多越慢，尤其是win电脑，太让人郁闷了 出于以上考虑因此笔者自己开发了一款api调试开发工具SmartApi，满足基本日常开发调试api需求
SmartApi win版本不大于1M；运行消耗性能极低 macos 版本不大于100M；运行消耗性能极低
非常适合开发设备或性能有限的开发环境