前后算是有2年旁边的极限拉扯，设计，落地履历,极限拉扯的是业务运用,设计是为了避免拉扯，落地履历是，我本可以轻轻松松的知足公司、业务面临的问题，结果实践了一圈，要么纯前端办理方案，要么纯后端方案，“管杀不管埋，管生不管养”，人悬在半空，其余一只脚落地要等到猴年马月。
容我正个三不雅观先技能的终极目的是做事于客户，只有客户满意，公司能赚到钱，业务能发展，能生存下去，我们才能生存，“皮之不存，毛将焉附”的道理都懂，近几年的论调和画风常常是, ”给多少钱做多少事儿，大不了再换一家“ ,即便近几年996,Icu的抵牾空前绝后，压力和难处也各不相同，但换种设想，主体在我，技能在我，我们只是在变强的道路上，顺手办理了生存问题，希望在我,这不是阿Q精神,对自己充满希望,人才会有希望。
Q：要办理什么问题？A： 关于微前端、npm私域包、和业务偏离的抵牾问题
Q:我立论的依据是什么？
A: 一个业务，一个公司，运营好几年，看着平地楼起，仍旧然并卵,我不是谈成功，我在谈失落败。
Q:有详细实践和场景么？
A:传统项目的缝合、老项目的改造、npm私有包、微前端、联邦模块、分离支配的实践，之以是现在说，是之前的实践和探索，终极我选择了分离支配的实践，也将重点来讲这部分
Q:抵牾是什么？
A: 前后端没有分离之前，基本会整体权衡,处理块放那边更省力更合理即放在那边，是互助关系，现在是”两看相轻，相互甩锅“,属于抢占关系，随着真个变多，交互性的哀求变强，职能变的更明确，前端认为自己用也可以整做事端，做事端就增编削查，现在时期变了”LZ不可能像开始那样被你吆五喝六了“，很多做事端还是秉持着前端便是绑我的数据，还敢跟我争话语权，这也便是很多沟通本钱增加的主成分，由于技能面的局限，自以为是的否定别人，但实质上，如果独立做一些运用就创造，离了对方，啥也不是，码界爱情故事，相爱相杀
Q:结果导向？
A:互助的可能没有了，那我眼不见心不烦，自己搞自己的，不依托你总行了吧，像之前微前真个提法，觉得高大上，可始终存在争议，办理不了我的业务问题，只能说，大萝卜埋小坑，连带挖地带松土,为理解决iframe的一些问题，组件引用，前端多技能栈差异化引用等问题，附带带来了一系列的办理方案，然而，这是小公司无法承受之重，做事端老哥劳心劳力搭架子，但这两年技能变革之快，每每由于UI太丑，没了竞争力.
从公司，业务的诉求开始♂️1.项目的运作办法以知足客户需求为准则，分外需求较多，更多考量以项目出发、技能选型实现思路各类方面存在差异化；♂️2.因项目需求的频繁变更及dead-line的哀求，很多功能没法按照组件化的办法方法去约束、没法有效的剥离业务组件，同时也没有专门的内部团队去构建沉淀，造成的直靠近况便是重复开拓，共用效率没法得到有效掌握、同一个业务百家争鸣，不同的外在相同的内里；♂️3.研发以及项目异地化，项目间的技能沟通协以及内部积累仅仅局限团队内部，每每因写法、规范、习气的不同以及研发职员的变更交替导致涌现一套系统多种风格，一个公司几种技能体系，基本无法协作的现状；♂️4.没有内部的技能沉淀，内部的推陈出新良性进化每每须要很大的研发韶光本钱耗费，造成的现状是业务线与技能线不在同一起跑线，却要保持步调同等，通过压缩技能实现周期对推陈涌现的韶光本钱进行掌握，每每会造成恶性结果；
以上基本上是传统小公司一贯无法超过阶层的现状，利润和本钱完备卡去世，一个业务做几十遍也无法提精髓精辟髓，公司层级啥也没有，
老板想要的业务组合是这样的，拼上就行：
但是结果每每是，动一根线，我可能就挂了
老板想要的对外输出是这样的：
实际的输出是：
先全体盛行私域包开胃
我们得搞根本培植，定标准，做架构，啦啦啦一堆，老板大臂一挥，我们要组件化，开整
私域包搞一波基建搞一波陡然创造，这个变更的体量，是要逼着所有人升级换代啊，以谁提出，谁完成的论调，这事情量有点儿大当你费心费力搞完了基建，创造依然无法约束大家的行为习气，好吧，支持力、约束力、实行力及员工普遍能力知足不了，平台层限定了你的发挥，换个试试再试个微前端qiankun缝合额，看着很高真个样子，也是缝合不同系统，不同技能架，支持老系统
微前端架构具备以下几个核心代价：技能栈无关 主框架不限定接入运用的技能栈，微运器具备完备自主权独立开拓、独立支配 微运用仓库独立，前后端可独立开拓，支配完成后主框架自动完成同步更新增量升级在面对各种繁芜场景时，我们常日很难对一个已经存在的系统做全量的技能栈升级或重构，而微前端是一种非常好的履行渐进式重构的手段和策略独立运行时 每个微运用之间状态隔离，运行时状态不共享微前端架构旨在办理单体运用在一个相对长的韶光跨度下，由于参与的职员、团队的增多、变迁，从一个普通运用演化成一个巨石运用后，随之而来的运用不可掩护的问题。这类问题在企业级 Web 运用中尤其常见
看着挺迷茫的，不过彷佛能办理传统iframe嵌套带来的发布，组件交互问题，啥也不说了，我先演出个胸口碎大石
带来的配置性灾害，新的样式污染，不断的填坑，问题彷佛看别人反馈了一堆，带来的震荡效果，没感想熏染到
我连数据都没统一呢，还不如我的渐进式改造来的实在，又是不得当的场景
我懵了，容我再强化抵牾缝合担保的基本准则，以业务划分为轴，谁的业务归谁，即【页面+做事】是一体化的。业务是可以被引用，集成，组件化的，大略理解便是，我想让iframe已有功能的根本上组件化掌握，继续改造的，以及做事的可更换行。缝合项目可以工程化，不会由于忘却调度某一个链接而环境混乱，因程序发布导致的问题。我的所有业务都可以组合，（配置化菜单，整体风格掌握，总控开关）最主要的是，“4两拨千金”，毕竟做设计和架构，实质便是供应做事，让每个人都轻松，都能获利，才是事情能做成的实质容我再履行联邦模块看到很多人认为webpack5联邦模块的这个能力便是微前端，对此不置可否
以下是之前验证的内容，是要轻量很多，知足一些哀求【组件+做事】归属，样式，继续等机制，但问题也很大，如果你详细升级过一些框架和webpack的版本，那就一定体会过那种痛楚，更不要说，你的设计哀求其他运用去做升级，以是引用者必须升级webpack版本这关，很难具有普适性， （详细干系升级过程之前写过，会在文末补充目录，感兴趣的小伙伴可以去看）
换个思路，是不是可以单端升级，把影响范围降到最低，以cdn的办法进行引用,实质webpack的引用端是否可以以cdn的办法放在做事端供应出来结合npm私域包的办法，现在的问题是怎么办理工程化的配置及批量发布的问题
办理工程化发布总控问题lerna 发布及环境的总体配置
"scripts": { "build:prod": " lerna exec -- cross-env VUE_APP_BASE_Portal='' VUE_APP_BASE_Gaway='' npm run build:prod -- --dest=../dist/^%LERNA_PACKAGE_NAME^% ", "build:stage": " lerna exec -- cross-env VUE_APP_BASE_Portal='' VUE_APP_BASE_Gaway='' npm run build:stage -- --dest=../dist/^%LERNA_PACKAGE_NAME^%", "bootstrap": "lerna bootstrap ", "rm": "lerna exec -- rimraf node_modules" },
达成批量发布，引用全局配置的目的
编译组件，主运用编译，2选一，一起发或者只发布主运用
"scripts": { "build:prod": "npm run lib&vue-cli-service build ", "build:stage": "npm run lib&vue-cli-service build "lib": "webpack --config build/webpack.lib.js ", },
子项目动态引入环境切换,public/index.html
<!-- 统一认证登录验证 --> <script src="<%=process.env.VUE_APP_BASE_Portal%>/lib/sso.js"></script> </script>办理组件总线的问题
图画的不是太明了，勉强看1.以引用链的形式进行交互，解耦支配2.担保组件输出的集中，统一，其他项目组件以引用支配形式，供应给总控组件进行管理，供应继续，引用，扩展的标准3.目前关于联邦模块动态调用放在一端进行调用还未验证，但事理基本上由双端约定变为单端，紧张对核心Init,get输出container进行扩展，问题不大
关于当前实践以上的问题，是我这段考试测验的终极比较符合我心意的组合，如果你有多个别系，须要统一领悟成菜单，样式，运用，共享机制为一套体系的须要，末了一套，我认为是我目前实践中，耗费最小，且最随意马虎达成目标的方案，韶光和篇幅关系，这次就聊到这，算是其余一个思路的探索吧
往期回顾多平台博客工具推举全栈闭幕者-把nuxt扔进垃圾桶、Blazor与seo的化学反应ol与Vue室内定位模式设计二十余年如一梦，此身虽在堪惊。闲登小阁看新晴。古今多少事，渔唱起三更Tauri操作实战（1）-环境准备代码天生代码webpack5 针对vue vue-cli-service 升级指南（三）webpack5 针对vue vue-cli-service 升级指南（二）webpack5 针对vue vue-cli-service 升级指南（一） 感谢如果末了看到这里，那感谢各位掘友耗费韶光看我在这里絮叨，加油，连续坚持
