利用Web Components渐进式改造传统项目

一次传统 MVC 项目的现代化改造实践：从混乱到可持续发展的前端体系

在最近的一个项目中，我对一个运行了十余年的传统 MVC 网站进行了现代化改造。该项目前后端完全不分离，也没有任何现代化构建工具链。由于经历了长期迭代和多人维护，代码质量参差不齐，稳定性和可维护性都已接近极限。

在无法进行全面重构的前提下，我选择了渐进式改造的方式，对项目的结构和前端体系进行升级，并以此构建出一套可持续演进的技术方案。以下为本次实践的整理

项目现状及主要问题

传统 MVC 项目在长期迭代后，往往会出现结构老化、逻辑分散等典型问题，本项目也不例外，主要问题包括：

• 前后端不分离，无任何工具链，依靠Visual Studio 开发平台
• 前端样式管理混乱，公共样式过多，之前的样式命名不规范，且存在很多全局样式。新开页面很容易受到全局样式的影响
• 存在大量的dom 操作，jq语法，js语法，且选择器依靠层级class, 无法定位具体问题
• 大量的业务和样式进行复制粘贴，互相受到影响，核心的计价业务有N个复制的独立js，且每个都是15000+。
• 无任何组件化和模块化，项目历经多人，全靠复制粘贴。
• 页面细节表现很差，如按钮等基础组件不统一，对于已经开发的页面，不小心改了公共样式，也会导致管理混乱。
• 核心代码改动，心智负担太大，多次执行操作，茴香豆吃了五颗，你以为只吃了一颗。

改造方案设计：渐进式演进，而非推倒重来

综合评估后，我将改造的目标定义为：

在保持现有业务稳定的前提下，逐步引入现代化技术栈，为未来的可持续发展（如整体迁移到 Nuxt）奠定基础。

基于这个目标，本次改造从以下几个方向展开：

技术思路与方案

思路

• 组件化，开发一套Web Components组件，来实现复用
• 对于核心计价业务逻辑（之前的js代码15000+），采用vue3开发,编译为Web Components
• 引入全局的theme.css,引入CSS Variables机制
• 推进BEM开发规范。

Web Components作为一个web 标准，虽然不火，但确是一个改造传统项目的不二选择

• 样式隔离和行为封装
• 原生标准，无依赖
• 与现有技术栈完美融合，可逐步替换原有业务
• 组件化开发，可维护性大大提高，沉淀一批优质组件。
• 向前向后兼容，构建组件库的时候，使用monorepo 架构，沉淀的组件不仅可以由于老的项目，也能用于新的技术栈。

基础层：Vite + Lit 3 构建 UI 基础组件库

基础组件库采用：

Vite：提供现代化开发体验和极快的构建速度

Lit 3：Google 开源、轻量、专注于 Web Components 的库

优势：

开发成本低，学习曲线平缓

封装的组件可以直接用于传统 MVC 页面

组件具有强隔离性，避免样式冲突

构建出的组件库可复用、可扩展

业务层：Vite + Vue 3 + Arco 组件库

对于计价等复杂业务模块，仅依靠 Web Components 编写原生逻辑的成本太高，组件间频繁交互复杂，因此业务组件层采用 Vue 3 构建：
使用 Vue 3 的组合式 API 提升可维护性
使用 Arco Design 提供丰富且一致的 UI
通过 customElement API 编译为 Web Components，直接注入老项目
支持局部重构，不影响其他页面
这种方式结合了 Vue 的开发效率和 Web Components 的兼容性，是传统项目中“高复杂业务模块”的最佳平衡点。

打包

使用Lit 打包了20+组件，压缩后大小为40K

使用Vue3+Arco，打包了10+组件，大小为130K,（同时包含了vue3）

总结

传统项目基本上失去了维护的意义，但是由于是线上业务，重构不一定具备条件，渐进式的改造，同时又能沉淀一套自己的组件库方案，为老项目注入新的活力：

• 沉淀了一批优质组件，摆脱了复用粘贴的噩梦循环。
• 组件化开发，为整个网站带来了一致性的交互体验。
• 维护性增加，元素隔离，样式隔离的情况下，上下文大大减少，ai开发友好。