@caicaiwoshishui 市场大很难定义。个人感觉，做硬件的，达到你描述的场景，roi 太低了，真做成你这样，要定什么价格，卖多少钱，又能卖几台呢？我咋感觉市场挺小的

@tool2d 自愧不如，这个主要还是看公司，其实只要能校招进一线公司字节快手阿里美团，最普通的前端也是 25k ，大家真没几个做你说的这种高要求的事儿的

你就算看官方文档，都整明白了，也改变不了目前找不到工作的现状吧。这已经不是五六年前了，没经验的做做 demo 就能转前端的日子早过去了

@yaphets666 我的重点在于，多方合作，逻辑复杂，我这种情况根本是不可能融合到一个系统中的，融合到一个系统只会越来越难维护。换一个负责人就再也不会知道前面的逻辑到底是什么情况了

@yaphets666 这不是你说的情况，老项目其实只是其中很小一部分，小于 15%。需要做的主要是接新项目

@RealJacob @yaphets666

btw ，在我的场景里，20 个业务方还是往少了说，感觉算上写老系统的 rd 的话，历史上前前后后需要参与的 rd 应该是大于 100 人的，这里仅说 rd ，不算 pm 、qa 等。

@yaphets666 只是举个例子，可能略有夸张了。但我确实实际遇到过类似的情况，我就是那个基座。一个需要兼容老系统，新系统，n 多业务方的系统。
你要说 iframe 能做吧，也能，但需要砍掉非常多需求。目前的情况个人感觉是一个微前端不错的实践，我觉得是有用的

@Envov
1. 和技术栈无关，那就是各个微前端方案要解决的问题。你可以理解为 iframe 也是一种微前端，主应用和子应用是技术栈无关的
2. 微前端加载和发包的区别，无需主应用发版。生产环境的子应用在经过测试后，可以直接发，不通过主应用。而发包不行。而发包也比较难避免“技术栈无关”这件事，react 项目怎么用 vue 包，反之亦然。（当然是有解决方案的，但也是有成本的，并且需要对当前项目有侵入性改动的）
3. 我理解子应用不影响主应用修复漏洞只是其中一个小的场景，还是有其他场景会用得到的

@yaphets666 你这不就是另一个需求了么，事实上没办法所有情况都有一个基座去做“一套”系统，如果只有两个业务方可能 ok ，那如果有二十个业务方需要协同开发呢？如何做到一个系统里？每个系统可能又是非常复杂庞大的，逻辑也都是不一样的，做到一起的话后续的维护如何维护？很显然是没法像你想的那样简单

@yaphets666 这个 sso 有啥关系呢？做了 sso 以后如何把多系统放到同一个页面中呢？

@yaphets666 当然，这些场景肯定也会有别的解决方案，但微前端肯定也属于其中一个，加上接入改造的成本其实并不太高，所以会有需求

@yaphets666
个人感觉，部分 iframe 能做的，但要规避 iframe 的一些缺点的，会有一定的需求。想了两个场景，
比如一些需要多业务方协作的「复杂」项目。例如一个复杂表单，同时需要填写财务报销的信息，和休假的信息，（举个例子，实际是否有这种场景另说），且需要做一些全局的弹窗样式，这样 iframe 不好处理的。这个场景可能涉及三方协调开发，1. 表单基座的研发 2. 财务系统的研发 3. hr 系统的研发。
再一个，比如想做一个浮动的广告展位，可能有专门的业务方去开发这个广告，独立于基座主项目开发上线，没有固定的区域和大小去做 iframe 。