一、架构思维入门：什么是前端架构、为什么需要分层、分层架构的演进历史
好，咱们开始第一课。很多同学一听到「架构」两个字，就觉得那是架构师才该操心的事。其实不然。你写的第一行代码，就已经在参与架构决策了——只是你可能没意识到。
今天这堂课，我想跟你聊聊三件事：前端架构到底是什么、为什么非要分层、以及这个行业是怎么从一团乱麻走到今天的。嗯，内容不少，但我会尽量讲得接地气一些。
1.1 什么是前端架构？
先别急着背定义。我换个说法：前端架构，就是你在写代码之前，先想清楚「这堆东西该怎么组织」。
说白了，它解决的是三个问题：
- 代码放哪儿——文件怎么分、模块怎么拆
- 代码怎么跑——数据怎么流动、组件怎么通信
- 代码怎么变——加个功能要改几处？会不会牵一发动全身？
我个人习惯把架构比作「盖楼时的脚手架」。你盖个平房，随便搭几根木头就行。但你要盖摩天大楼，没有结构工程师画图纸，那肯定塌。前端也一样——项目小的时候，怎么折腾都行；项目一旦上了规模，没有架构思维，代码就是灾难。
核心观点： 架构不是「做不做」的问题，而是「什么时候做」的问题。越早想清楚，后面越省心。
1.2 为什么需要分层？
你想想看，为什么我们写代码要分层？
我在项目中遇到过这样一个场景：一个老项目，所有逻辑都写在 Vue 的 methods 里。请求数据、处理业务、更新视图，全混在一起。后来要改一个支付流程，我找了整整两天才找到那个关键的 if 判断——它藏在一个 800 行的函数里。
这就是不分层的后果。分层的目的，就是让每一层只关心一件事。
具体来说，分层能带来三个好处：
- 职责清晰——视图只管渲染，业务逻辑只管处理数据，API 只管发请求。谁也别越界。
- 可替换性——今天用 Vue，明天想换 React？只要视图层和业务层之间接口不变，换框架就像换皮肤。
- 可测试性——业务逻辑抽出来，不用跑浏览器就能测。我后来重构那个老项目时，光单元测试就补了 200 多个，心里踏实多了。
一个小技巧： 判断你的代码是否该分层了，有个简单标准——当你发现一个文件超过 300 行，或者一个函数超过 50 行，就该考虑拆了。
1.3 分层架构的演进历史
好，咱们来聊聊历史。这部分我尽量不写成编年史，而是讲几个「坑」——因为每一个架构模式的诞生，都是被坑出来的。
阶段一：面条代码时代（2005-2010）
那时候前端还叫「网页制作」。HTML、CSS、JavaScript 全写在一个文件里。jQuery 一把梭，$() 满天飞。
<!-- 典型的"面条代码" -->
<html>
<head>
<script>
$(function() {
$('#btn').click(function() {
$.get('/api/data', function(res) {
$('#result').html('<li>' + res.name + '</li>');
});
});
});
</script>
</head>
<body>
<button id="btn">加载数据</button>
<ul id="result"></ul>
</body>
</html>这段代码有什么问题？所有东西都搅在一起。HTML 结构、事件绑定、数据请求、DOM 操作，全在一个 script 标签里。加个功能？你得从头读到尾，生怕改错哪一行。
我曾经接手过一个这样的项目，光首页就有 4000 行。改一个按钮颜色，结果把整个页面的样式搞崩了——因为样式和逻辑混在一起，一个选择器改了全局。
避坑指南： 如果你现在还在用「一个文件搞定一切」的方式写项目，赶紧停手。这不是效率，这是给自己埋雷。
阶段二：MVC/MVVM 与组件化（2011-2017）
后来大家发现，这样不行。于是开始借鉴后端的分层思想——MVC 模式被引入前端。
Backbone.js 是早期的代表。它把代码分成了 Model（数据）、View（视图）、Controller（控制器）。虽然现在看来很笨重，但至少有了「层」的概念。
再后来，Angular、React、Vue 相继出现，带来了真正的组件化。组件化是什么？就是把一个页面拆成一个个独立的小块，每个块有自己的 HTML、CSS、JS。
// 一个典型的 Vue 组件
<template>
<div class="user-card">
<h3>{{ user.name }}</h3>
<p>{{ user.email }}</p>
</div>
</template>
<script>
export default {
props: ['user'],
// 组件内部只关心自己的渲染逻辑
}
</script>
<style scoped>
.user-card { border: 1px solid #ddd; padding: 16px; }
</style>组件化的好处很明显：复用、隔离、可维护。但注意，组件化不等于分层。很多团队把组件化理解成了「把页面切成小块」，结果业务逻辑还是散落在各个组件里。
我记得有个项目，一个「用户登录」的功能，逻辑分散在三个组件里：A 组件调接口、B 组件存 token、C 组件跳转路由。后来要改登录流程，三个人改了三天，还改出了 bug。
关键认知： 组件化解决的是「视图复用」问题，而分层解决的是「逻辑组织」问题。两者缺一不可。
阶段三：微前端时代（2018-至今）
项目越来越大，团队越来越多。一个单体前端应用，可能同时有 5 个团队在开发。这时候问题来了：
- 技术栈不统一——有的用 React，有的用 Vue
- 发布节奏不一致——A 团队每天发版，B 团队两周发一次
- 代码冲突频繁——改同一个路由文件，合并能合到崩溃
于是，微前端出现了。它的核心思想很简单：把一个大应用拆成多个独立的小应用，每个小应用可以独立开发、独立部署、独立运行。
我参与过一个大型后台系统的微前端改造。原来是一个单体项目，编译一次要 8 分钟。拆成 6 个子应用后，每个子应用编译不到 1 分钟。而且不同团队可以用不同的框架——A 团队用 React，B 团队用 Vue，互不干扰。
// 微前端主应用配置（以 qiankun 为例）
import { registerMicroApps, start } from 'qiankun';
registerMicroApps([
{
name: 'user-module',
entry: '//localhost:3001',
container: '#sub-app-container',
activeRule: '/user',
},
{
name: 'order-module',
entry: '//localhost:3002',
container: '#sub-app-container',
activeRule: '/order',
},
]);
start();但微前端也不是银弹。它带来了新的复杂度：通信机制、样式隔离、公共依赖管理、性能开销。如果你团队只有 3 个人，项目也不大，强行上微前端就是杀鸡用牛刀。
我的建议： 微前端适合「多团队协作的大型项目」。小项目老老实实用组件化 + 分层就够了。别为了技术而技术。
1.4 小结：从混乱到有序
回顾这段历史，你会发现一个规律：每一次架构演进，都是在解决上一个阶段留下的坑。
| 阶段 | 核心问题 | 解决方案 | 遗留问题 |
|---|---|---|---|
| 面条代码 | 代码混在一起，难以维护 | MVC 分层 | 分层不够细，视图逻辑仍耦合 |
| 组件化 | 视图复用困难 | 组件化 + MVVM | 业务逻辑散落在组件中 |
| 微前端 | 多团队协作冲突 | 应用级拆分 | 通信与性能开销 |
嗯，到这里第一课就差不多了。我想让你记住一句话：架构不是设计出来的，是演进出来的。别想着一步到位，也别觉得「现在够用就行」。保持对代码结构的敏感，该重构时就重构——这才是架构思维的核心。
下一课，咱们会深入聊聊具体怎么分层，以及每一层该放什么、不该放什么。到时候见。