15 年老旧项目“重生记”：一个渐进式的微前端框架实现心得一个渐进式的对老系统无痛的改进型的微前端框架，我在一个15年的

前言

各位掘金上的大佬们你们好，我是一个工作了一年半的大学生。

上一篇文章是一个miniHMR热更新部署插件的实现，而过去半年了，我又在其中研究出了一些新的理论。

我想把他记录下来，作为我的工作经验印证。

背景

我入职了一家PHP公司，这个公司代码是2010年开始写的，大家可以想象，代码的设计思想和技术栈都不能与现在的技术栈和设计思想媲美，甚至很多代码规范做的都是很不足的。

而这家公司的前端，简直是远古时代。

通过一套前端js框架库进行搭建的，而这套js框架是倾向于传统HTML+JS这种形式，并非Vue React这种更复杂的框架库。

所以现在就有个大问题：

如何实现，如何解决超级复杂的前端组件？

为什么会有这个问题，我给大家说一下，现在的情况是，由于这个js框架是倾向于HTML+JS单文件模式，没有模块化，甚至可以视为就是纯js，那情况就很糟糕了，就会带来：

1、作用域混乱 2、样式干扰 3、window上的对象多的不得了 4、各种dom也无法良好的管理

需求

现在的任务是实现一个极度复杂的表单拖拽设计器，核心需求包括：

可视化交互：流畅的拖拽、放置与排序。
动态渲染：基于 JSON 配置实时生成表单组件。
规则约束：针对不同组件设置复杂的校验逻辑与联动限制。
样式自定义：支持高度灵活的组件外观配置。
预览与打包：实现一键预览及 Schema 数据导出。

在公司现有的老旧框架下，这个功能几乎是“无解”的。

该框架本质上是一套纯手写的远古逻辑，别说现代化的开发体验，连 npm 生态都无法直接接入（即便通过 Vite 打包成 UMD 格式也极其割裂）。

在 2025 年 10 月，我曾尝试硬着头皮用原框架推行，但仅坚持了两天就彻底放弃。原因非常现实：太累了，且看不到终点。

仅仅是处理最基础的拖拽和渲染，代码量就已呈爆炸式增长。更离谱的是，该框架的布局系统极度封闭，只允许使用预设的几种死板布局。如果你想微调 UI，不仅要手写大量的冗余 CSS，甚至还需要去改动框架的底层源码。

面对这种“第一步就得改源码”的死局，我意识到，如果继续在这个泥潭里挣扎，后续的细节实现将变成无底洞。为了不被低效的代码吞没。

灵感

面对旧框架这块“硬骨头”，我一直在思考：有没有一种方案，既能让我彻底摆脱陈旧开发模式的束缚，又能让新代码在原系统的壳子里无缝跑起来，而且不破坏老系统的任何东西？

苦思冥想中，我想起了学生时代曾因“偷懒”而错过的知识点——微服务（Microservices） 。

记得读书那会儿 Spring 生态正如日中天，我学了 Boot，却对 Cloud 敬而远之。原因很单纯：我更喜欢于前端。前端那种“所见即所得”的正反馈远比后端逻辑来得快，于是我一头扎进了 Vue3、Pinia、源码原理以及 GIS 技术。

正是这段关于“微服务”的记忆，让我联想到了前端领域的一个现代概念——微前端。

虽然我连 qiankun 之类的框架源码都没下载过，仅仅是在掘金上翻阅了几篇技术贴，但我敏锐地察觉到：这套方案简直是为我当下的困境量身定制的。

之所以选择这条路，我的核心考量有四点：

技术栈重启：我终于可以拥抱 Vue/React 这些现代框架了。这是我读书时的“基本功”，不仅写起来顺手，社区文档也极其丰富。
生态降维打击：可以自由调用 npm 库。既然能直接拿成熟的开源组件来用，何必再去手搓那些原始代码？
iframe 的奇效：我发现通过打出一个 iframe 包，可以像“挂件”一样直接嵌进现有系统。更棒的是，它们之间还能实现双向调用，完美平衡了独立性与联动性。
AI IDE 的神助攻：今年我深度体验了 AI 辅助开发，效率简直呈指数级增长。很多时候，我只需要定义好逻辑，剩下的代码 AI 都能帮我生成，手写量锐减，开发体验直接翻倍。

技术方案

路径图

在这套方案的路线图中，我通过三位一体的工具链，构建了一个极其高效的闭环：

本地编写与打包：基于 Vite 驱动。通过运行 npm run build:watch，使前端源代码处于持续构建状态，实时更新输出到 dist 目录。
同步上传：核心在于我此前开发的 miniHMR。它负责监听本地 dist 构建目录，一旦检测到文件变动，立即将其同步推送到线上服务器。
线上即时测试：由我新研制的渐进式微前端框架 Micro-XXX 承载。

关于工作流的补充说明： 开发人员借助 AI IDE 快速生成逻辑代码。由于 Vite 处于监听模式，代码变更会被瞬间捕获并打包。通过 miniHMR 的“空中传输”，开发者可以实现“本地改动，线上即显”的循环往复。针对协同开发，我们建立了标准规范：线上环境作为统一的测试基准，每日开发完成后将源码推送至代码云，确保团队成员能随时拉取最新的工程上下文。

以前的问题

针对前文提到的老系统“四大公害”，我利用微前端架构进行了物理隔离级别的降维打击：

作用域混乱：我采用 iframe 作为微前端模块的容器，并打造了一个中间层 JS 。所有微前端模块都由该 JS 托管，原生模块与新模块之间严禁直接通信。获取状态的链路被规范化为：中间层JS.getState() -> 获取微应用数据。这种“代理模式”彻底杜绝了以往全局变量打架的乱象。
样式干扰：这是 iframe 的天然优势。内部样式与外部环境物理隔绝，从原理上直接消灭了 CSS 污染。
Window 对象膨胀：由于新模块运行在独立的沙箱环境中，它们不再向父系统的 window 丢弃任何垃圾。所有的交互都被收敛到托管 JS 中，外部无法越权访问。
DOM 管理失控：由于引入了 Vue 3，我们从繁琐的命令式 DOM 操作进化到了声明式的虚拟 DOM 时代，复杂的交互逻辑变得清晰且可维护。

微前端的问题

成熟的微前端框架（如 qiankun、wujie）也有其固有的局限性。在 Micro-XXX 中，我根据业务场景进行了取舍与优化：

布局约束：父容器的旧框架往往会限制子应用。我通过中间层 JS 动态注入样式处理逻辑，赋予子应用自适应能力，确保其能完美适配各种容器尺寸。
性能开销：这是用“开发舒适度”换取“运行时消耗”的权衡。但得益于 Vite 的分包策略与按需引入，即使是超级复杂的功能，最终产物也能压缩在 500k 左右，实际体验与原生 JS 无异。
语义化：对于 B 端业务系统，我们追求的是稳定性与交互效率，而非 SEO。因此，我选择了更实用的开发逻辑，而非为了语义化而语义化。
URL 不同步：公司的系统本质是单页面入口（如 index.php），强行同步路由反而会导致页面 404。既然父容器不需要路由同步，我便将其彻底解耦，避免了复杂的路由仲裁。
上下文隔离（内存不共享） ：我通过中间层 JS 封装了 postMessage 通信协议，实现了跨环境的高效数据交换。
加载缓慢：我参考了 Vue keep-alive 的思想，在父容器中对 iframe 节点进行了缓存配置。只需在首次进入时加载一次，只要不主动销毁 DOM，子应用就能保持“常驻”状态，实现秒开效果。