公司一般也不在意那点空间……
实在在意的话，只有在某个地方记一下，然后定期清理……

是否商业化，和“企业级”没有什么关系。
“企业级”只是描述这个框架经过了大量企业真实业务验证的，是有能力解决大型企业、复杂业务问题的，而不代表一定会有商业化的成分。
商业支持完善，那叫商用框架，不叫企业级框架。
就像同样是企业软件，既有免费的，也有商业化的。
“商业化”和“企业级”没有必然关系。“企业级”也可以是非商业化的，比如 Apache 的很多开源项目都可以称为“企业级”。商业化的也不一定都是企业级的。

接上文，“企业级”的框架，应该是这类经过了复杂业务验证的框架。相比起直接用各类零零碎碎的东西，它能带来优点：
1.规范化和一致性。这类框架一定是自己企业内部经过了一段时间实践的，会在各方面进行一些规范约束，团队协作体验会比较好。
2.开箱即用能力。将一些更底层的内容，诸如怎么连 XXX 、怎么在其他模块中使用等常见的东西，都做了一定程度上的封装。这样一来使用方便，二来一定会有一些最佳实践在里面，性能和稳定性都有一定保障。
3.可扩展性。在有规范约束的情况下保持可扩展性，这个是不太好实践的。一定是经过大量业务验证，不断迭代才会有的。
4.稳定和性能，虽然经过了包装，跑跑 benchmark 啥的性能一般会比拆开用差，但实际业务的表现就不好说了。即使差一些，也是在可接受范围内的。

这年头，只要是用来支撑企业自己的应用的，都自称“企业级”。
但我觉得大部分“企业级”都只是虚张声势。真正的企业级，应该是意味着在企业内部业务得到了足够的实践，能够满足复杂业务对于功能性、稳定性、扩展性、性能的要求。
举个例子，我自己开了一家小公司，然后我为自己的公司写了个框架，它确实支撑起这家小公司的业务了，有些人就沾沾自喜的称之为“企业级”框架。但我觉得它并不能算作“企业级”，因为业务太少、太简单了。
但如果换一下，比如蚂蚁金服做了个框架，在内部已经有几十个上百个项目使用了，业务也足够复杂。那它就可以被称之为“企业级”了。(PS：为什么我拿蚂蚁举例子？因为很多公司的业务都远远达不到蚂蚁的复杂度)

1.压缩体积，减小带宽。
2.混淆代码，一定程度上防止破解。
3.可运行，比如 JSX/Vue 的语法一般是不能或者不推荐直接运行的。
4.兼容性，打包的时候会进行一些向下兼容，比如 async 、const 之类的会转成低版本浏览器兼容的语法。

只能说具体情况具体分析了，没有最好的，只有最合适的。
举个例子，语雀就是一个庞大的 nodejs 的应用，所以 nodejs 实际上也可以写大型应用，并且相应的架构、团队合作也有比较成熟的方案（例如蚂蚁金服开源的 eggjs ）
语雀面临快速的迭代，并且目前为止，因为良好的基础设施，没有明显的性能瓶颈，所以 nodejs 是语雀目前为止最合适的选择。
后续会不会换成 Java ？这个还真不好说。可能有一天 node 成了语雀的性能瓶颈后会换吧。
相应的，你可以评估一下，你们团队的现状是什么样的，转投其他语言成本有多大，能带来什么（不止是技术上的，还要考虑到，业务能不能不耽误，总不能说因为你们要重构就一两个月不更新新功能吧）
另外不推荐不熟悉的语言，包括 Go 、PHP 、.NET 。也不推荐动不动就搞什么微服务啥的。不是他们不好，是因为你们团队没人足够熟悉，贸然换上它们会踩很多坑，而且很可能会出现各种“疑难杂症”，带来的收益也不一定会有想象中大。

@CRH 如果是这样的话，强制更新也是可行的，但是还是要考虑回滚、更新失败的降级措施（至少保证旧版本可以用）
总的来说，在服务端进行灰度比较可控一些，如果是推送到端上再发现问题，回滚起来很麻烦（比方说你们推送了一个新版本，白天开始用之后才发现后端的新代码没考虑到一些 case，这个时候靠强制推送来回滚比较麻烦）

@roth 绿码就是公安部推送的，这个是项目组的人亲自说的，至于会不会是披着公安部的皮那我们就不知道了

@roth 规则是上面定的还是公安部自己定的，有没有和其他部委联合，规则是不是公开的，那我们也不知道，毕竟 zf 自己也是有保密信息的。我知道的是，支付宝的绿码数据是公安部推送的，和支付宝没有半毛钱关系。
不要小看公安部，公安部是有自己的大数据系统的，做这个系统难度不大。
健康码系统肯定会有你最近的行踪，但详细到什么程度只有核心人员知道。哪怕是公安部自己，正常情况下一般人也是看不到具体数据的。至于让基层拉网排查，我觉得只是没必要动用太多数据，毕竟是个小事，层层审批很麻烦的，除非这个红码人员是逃犯……

举个例子，为什么说强制更新尽量少用。
你们的客户公司，老板正在出差，网络状况不太好。这个时候，他需要审核一点资料啥的。然后他点开了 App，很不巧，他被灰度到了，如果不更新就不能使用。然而他的网络情况让他下了好几遍新版本也没有下载成功。
很显然，他不一定要新版才能完成的工作，却因为强制升级而不能完成了。
对于 to B 来说，需要更多考虑用户体验，而不需要额外的营销手段留住客户。所以需要尽可能考虑 B 端客户的各种情况，能让客户正常使用是最重要的。
比如弱网，异地 /跨国漫游……这类 to C 产品不用太关心的因素。

首先，虽然说有强制升级 App 的能力，但这个给用户的体验太差了，没有必要还是不要使用最好。
楼主的方式改造是可行的，但是需要考虑一些问题，一是强制升级体验会很差，二是如果不强制升级，就有维护多个版本的成本。
说说我们的大概做法：如果接口更改是向下兼容的，只是加了一些字段什么的，一般不会改 URL 。因为迭代频繁的时候，每次都改 URL 成本太高。这种情况下，一般是正式一批服务器，灰度一批服务器，根据特定条件(比如 ID 范围、按所属企业啥的)，统一代理把它转发到正式 /灰度服务器。如果出现问题，只需要把转发重新改回线上就可以快速回滚。
如果是不向下兼容的，那一般会发布为一个新的接口，可以加上版本标志什么的。这个时候灰度其实就不需要后端做什么了，只需要客户端分批升级就行。

我想纠正一些东西：
1.首先，你是绿码还是红码，和支付宝半毛钱关系都没有，这个数据来源于公安部的系统。所以，具体用了什么数据，算法是啥样的，都是公安部自己的系统决定。
2.为什么是一个二维码，而不是其他东西：因为二维码是唯一一个可以低成本、快速铺开、有一定信息承载能力的形式。换成其他形式，比如纯文字是不能承载更多信息的，比如直接绑定身份证，那么没办法给所有小区、商店都配备设备。
3.显示码的时候会不会上传你的位置信息？你觉得公安部会没有你的手机信号定位吗……哪还需要这个？
4.为什么微信需要每次验证，支付宝不需要？因为是阿里做的，只打通了阿里的免登体系。你在微信里使用，其实也是阿里的服务，并不代表你用微信就不会存储你的信息。
5.为什么有些地方会单独出个 App ？这个和支付宝就没啥关系了，地方 zf 想这样玩，支付宝能怎么办？

其实这些都不是重点。
重点是开多少钱。

@assassin1993zj 特地上来给你点赞

@xuyuheng0905 钉钉移动端是 Native 实现核心功能，C++底层库（大部分代码是写了两遍的……）很多非核心功能都是小程序形式接入的

@xuyuheng0905 钉钉用的是 CEF……底层逻辑是两套……UI 是混合 Native 和 H5 的……

Go 不确定，和 Java 分庭抗礼短期内不太可能。另外 Go 面临的竞争对手不少，Go 本身也还不错，所以未来不好说。
Python+，算法还在发展，Python 是钦点的，没办法。
Node++，“大前端”是大趋势，没啥可选的。
另外 Java 目前当然是绝对的霸主。容器化等技术虽然尽可能做到底层不敏感、抹平差距，但是生态和技术积累是没那么容易建立起来的。
设计好的语言多了去了，为什么最后留下的是整天被人吐槽的 PHP、JS、Java ？语言设计的再好没有用，需要看它能不能解决实际问题。