企业官网建设流程全解析

前端架构这四个字，在技术社区里一直是个有点尴尬的存在。你去问后端同学，微服务、DDD、高可用、领域模型，能聊一下午。但你问前端同学“你们项目架构怎么样”，很多人的第一反应是：我就写写页面，调调接口，绑绑数据，哪有架构可谈？这种心虚我太理解了，因为我自己也经历过那个阶段，觉得前端就是浏览器的“装修工”，跟架构这种词八竿子打不着。

但做了这么多年前端，带过小团队，也接手过几万行代码的遗留系统，我的回答变了：前端不仅有架构，而且有没有架构、架构好不好，恰恰是区分“写页面”和“做产品”的分水岭。前端架构不是有没有的问题，而是你有没有意识到，你已经在做架构决策了——只不过有些决策是显式的，有些是隐式的、随机的、跟手感走的。这篇文章我想把这层窗户纸捅破，聊聊前端架构到底是什么、为什么很多人觉得它不存在、以及一个普通前端团队该怎么从零把架构立起来。

1. 为什么总有声音说“前端没有架构”

1.1 前端的“低门槛”让架构隐身了

前端这个领域，起步门槛确实低。一个 HTML 文件里引一个 script 标签，写几行 jQuery，页面就能动。早期的前端页面，说白了就是“静态页面 + 少量脚本”，交互简单到根本不需要设计什么结构。那时候前端工程师的核心竞争力是“还原设计稿像不像”“动画顺不顺”，跟架构确实没什么关系。

更关键的是，浏览器作为运行时，帮前端吸收了太多复杂度。服务端要考虑并发、事务、数据一致性、容灾，这些压力天然会逼着后端去分层、去抽象，不然系统根本跑不稳。但前端呢？页面崩了刷新一下，接口挂了控制台看一眼，看起来问题都不大。这种“能跑就行”的错觉，让很多前端团队长期停留在“写代码”而不是“设计代码”的层面。架构这个东西，在浏览器里是隐身的，用户看到的是页面，而不是页面背后的模块边界和数据流。

1.2 架构是慢变量，痛的时候才被看见

还有一层原因，架构带来的问题不是立刻爆发的。它像骨骼，平时看不见摸不着，但你弯腰、负重、跑起来的时候，骨骼好不好就决定了你能撑多久。代码量小的时候，没有架构完全没问题，甚至更高效——你不分层、不抽象、直接写，反而是最快的。但当项目从几个页面长到几十个页面，从一个人开发变成五个人协作，从三个月不换需求变成每周迭代，原来那些“方便”就会变成“债”。

我见过一个内部后台系统，一开始就一个页面，后来业务越加越多，几十个模块共用一套登录和权限逻辑。但代码没有统一约束，每个页面自己判断登录态，自己写权限拦截，改了三十个文件还没改全。你说这个项目有架构吗？它当然有过架构决策——只不过那些决策是“每个人按自己习惯写”的隐式决策，拼在一起就是一团乱麻。所以不是前端没有架构，而是很多项目用“时间”和“人力”为没有架构买了单。

1.3 没有架构，本身就是一种架构

这句话我希望每个前端都记在心里：你不做架构决策，不意味着你没有架构，你只是选择了一种“无架构”的架构——代价是项目越大，维护成本越失控。

架构的本质，是一组关于代码如何组织、数据如何流动、模块如何依赖的决策总和。你决定不约定目录结构，是一种决策；你决定不引入状态管理，是一种决策；你决定不写规范和文档，也是一种决策。这些决策不是没有发生，而是发生得太随机、太碎片化，最后以“技术债”的形式堆在项目里。所以前端架构不是一个“有没有资格谈”的问题，而是一个“你已经在谈，只是谈得好不好”的问题。意识到这一点，是前端从执行者走向设计者的第一步。

2. 前端架构到底是什么：不是宏大名词，而是取舍的组合

2.1 能跑的项目和能维护的系统，差在哪里

很多前端对“架构”的第一反应是：微前端、DDD、设计模式、架构图，听起来又大又虚。这是对架构最大的误解。架构不需要宏大叙事，它解决的是一个非常朴素的问题：当项目变大、人变多、需求变快的时候，怎么让代码还能被理解和修改。

我给你一个具体的对比。同一个功能，在两种项目里的演进路径完全不同。一种项目，页面逻辑写在一个巨型组件里，接口请求直接散落在各处，工具函数每个模块自己拷一份。刚开始功能简单，两周就能上线。但半年后，需求开始频繁变化：加一个权限判断，要改七八个地方；换一个接口字段，全局搜索替换还得小心翼翼。另一种项目，数据请求统一走 service 层，页面只关心展示和交互，权限逻辑收敛到一个模块里。改权限源头，只需要动一处。前者是“能跑的项目”，后者是“能维护的系统”。这两者之间的差距，就是架构。

2.2 前端架构的六个核心维度

如果用一个框架来理解前端架构，我会把它拆成六个维度，缺哪个都会在某个阶段出问题。

目录与分层：项目一级目录怎么组织，业务模块之间是“平铺”还是“按领域聚合”，公共代码放哪里。这一层决定了代码的“地理结构”，也决定了新人上手时能不能快速找到改的地方。

状态管理：数据从哪里来、存在哪里、如何流转。是组件本地状态、服务端缓存状态，还是全局共享状态，分别应该用什么机制管理。这一层决定了页面之间的数据一致性。

组件设计：组件怎么拆分、怎么复用，通用组件和业务组件怎么区分，谁允许依赖谁。组件边界不清，是“牵一发动全身”的核心来源。

工程化：构建、依赖管理、环境配置、发布和回滚方案。前端架构如果只看浏览器运行时，会漏掉一大半——真正的复杂度很多在“代码怎么变成线上产物”这条链路上。

规范与约束：代码风格、命名约定、提交规范、code review 机制。这部分看起来“软”，其实是架构能落地的保障。没有约束的架构图，画得再漂亮也是墙纸。

非功能需求：性能预算、可访问性、埋点、监控、灰度发布、安全。这些不会直接出现在需求文档里，但恰恰是系统长期健康运行的底座。

2.3 架构的本质是约束与取舍

这个可能是全文我想强调的最后一件事：架构不是功能，不是越丰富越好，而是对当前阶段“刚刚好”的约束。约束太少，项目会乱；约束太多，团队会慢。

举个例子。一个只有三五个页面的营销落地页，表单提交用组件内部状态就完全够用，非要去上一套全局状态管理工具，反而白增加心智负担。反过来，一个几十个模块的中后台系统，每个页面自己管理登录态、自己请求权限数据，跨页面状态互相不通，这个时候就必须在状态管理层做统一设计。所以前端架构的核心能力，其实是“判断什么时候该加约束、加多重的约束”的能力。这个判断力，不是靠学的，是靠踩坑踩出来的。

3. 前端架构的分层与演进：从“能跑”到“健壮”

3.1 前端架构的演进时间线

前端不是一开始就有架构可谈的。早期的网页，HTML 负责内容、CSS 负责样式、JavaScript 负责一点交互，三者混在一起，页面和页面之间基本独立，谈不上架构。后来前后端分离，前端开始管理路由和视图状态，工程化工具出现，才有了“代码结构”这个概念的萌芽。

再往后，单页应用普及，一个项目里的页面越来越多，前端开始面临和传统后端类似的复杂度问题：模块怎么划分、状态怎么共享、数据怎么流动。于是组件化、状态管理、路由守卫、权限拦截这些能力逐渐成了标配。再到现在，中后台系统动辄几十上百个模块，微前端、模块联邦、低代码平台成为讨论热点。你会发现，前端架构的演进，本质上是对“系统复杂度”的追认——不是设计出来的，是被需求逼出来的。

3.2 一套可复用的前端分层模型

我见过很多前端项目，最大的问题不是没有分层，而是分层太模糊：所有代码都堆在 pages 下面，业务逻辑写在组件里，工具函数和业务请求混在一起。这里我建议一个非常朴素、但长期验证有效的三层模型，可以覆盖绝大多数中后台前端项目。

最底层是基础设施层，放与业务无关的通用能力：网络请求封装、埋点上报、日志记录、通用工具函数。这一层是“地基”，不依赖任何业务模块。往上一层是业务基础层，放多个业务模块都会用到的公共能力：登录态、权限计算、当前用户信息、统一布局、通用业务组件。这一层依赖底层，但不依赖具体页面。最顶层是业务模块层，也就是具体的页面和功能模块。这一层直接面向需求，通过调用下面两层的能力来组装功能。

这个三层模型最大的价值，是把依赖方向固定下来：从上往下依赖，不允许业务模块之间互相直接调用。比如 A 模块需要 B 模块的一个能力，正确做法是把这能力下沉到业务基础层，两个模块都依赖它，而不是 A 直接 import B。你可能觉得这规矩太死板，但实践里无数问题就出在“都是一家人，import 一下怎么了”——import 多了，模块边界就没了，最后改一个模块，全局报错。

3.3 从零到一搭一套轻架构

很多人会说，我们项目已经成型了，现在谈架构是不是晚了？我的经验是，架构重构永远不晚，但别想着一口气重来，从“轻架构”开始就能见效。我建议按这个顺序推进。

第一步，画边界地图。找一两个小时，把项目里主要的模块和它们之间的 import 关系画出来。你不用画得很精确，重点是找出“不该有的依赖”：比如页面直接调用了另一个页面的组件，或者工具函数被三个模块各拷了一份。这些就是架构问题的起点。

第二步，定目录约定。跟团队一起，把“什么代码放哪里”写清楚。这个不需要很复杂，一张 A4 纸就够：新增页面放哪个目录、公共组件放哪个目录、接口请求放哪个目录、工具函数放哪个目录。有约定比约定什么更重要。

第三步，定数据流规则。明确一个项目里，页面能不能直接发请求。我建议至少引入一个 service 层，所有接口请求统一收敛到 service 模块里。这样接口改动时只动一个文件，而且每个接口的调用方可以通过代码引用关系数出来。

第四步，定组件边界。通用组件（按钮、表格、弹窗、日期选择）和业务组件（订单卡片、用户列表、权限树）严格分目录。业务组件不得出现在通用组件目录里，通用组件也不得依赖任何业务数据。

第五步，统一工程化。把 lint 规则、格式化配置、提交信息规范统一起来，这套东西配置成本不高，但能让全员代码风格对齐。没有统一的代码风格，架构文档写得再好，代码里还是各写各的。

第六步，沉淀并评审。把上面这些约定写进 README 或项目文档，然后坚持代码评审。评审不是找茬，而是维护边界。前几次会慢，但坚持两个月，团队的代码会肉眼可见地变整齐。

4. 判断你的项目需要多少架构：别多也别少

4.1 四个变量决定架构投入

前端架构不是越多越好，也不是没有越自由。决定投入多少，核心看四个变量。

团队规模。一个人开发一个小项目，你心里有数，代码乱一点也能找到。团队到了三个人以上，就需要显式的约定，因为“别人的代码”对你来说是陌生的，没有规范就互相看不懂。

需求变更频率。如果项目上线后基本不动，架构投入可以很低；如果每周迭代一个版本，需求反复调整，没有架构的代码会很快腐化，因为改动的触点太多。

系统生命周期。一个只跑三个月的活动页，不需要架构；一个要维护三五年的核心系统，架构投入必须跟上。资损类、交易类、权限类系统尤其如此——出问题不只是代码层面的事。

协作面。模块之间是孤立的还是强耦合，是否有多个团队维护同一套代码。协作越广，越需要模块边界和契约清晰。

4.2 不同阶段的架构投入对照表

我整理了一张对照表，方便你判断自己项目该配多少“架构预算”。

值得提醒的是，很多团队在做架构投入时搞反了方向：小项目上了大架子，用微前端拆了三个本来很小的模块，结果光维护工程就花了大量时间；大项目反而没有约束，所有代码堆在一起，等意识到的时候已经不敢动了。架构投入一定要跟着问题走，没有那个问题，就别上那个方案。

4.3 过度架构的识别和减法

架构不是安全词，过度架构同样会拖垮团队。我见过一种典型情况：架构文档写了几十页，抽象了一层又一层，一个普通需求改动时要穿透五个抽象层，新人入职两个月还在迷路。这种架构的问题在于，它不是在解决真实痛点，而是在“表演设计”。

识别过度架构，有几个信号很直接：新增一个字段需要改动超过三个文件；一个简单的展示逻辑被拆成了六七个类；架构评审会上，架构师说“这样设计未来可以支持某个场景”——但那个场景可能永远不会来。碰到这种情况，我建议果断做减法：把不解决当前痛点的抽象删掉，把没有实际调用方的中间层合并掉，把明知没人看的架构文档精简成一页真实的约束清单。架构的价值在于降低维护成本，如果它在增加维护成本，那不管听起来多专业，都要砍。

5. 前端架构的常见误区与踩坑实录

5.1 误区一：架构是架构师的事，别人只管执行

前端架构要想真正落地，最大的阻力往往不是技术问题，而是“共识问题”。如果架构只是某个人设计好后宣布大家照做，那大概率会失败——因为团队成员不理解为什么这么设计，遇到实际情况就会绕开规范走“捷径”。我见过一个团队，架构师定了一套很严谨的分层规范，结果三个月后检查代码，一半新代码都没按规范写，原因是大家觉得“麻烦”“不理解”。

好的架构一定是团队共同参与出来的。哪怕是目录放哪这种小事，也要让大家一起讨论、一起定。一个人说了算的架构，执行全靠自觉；大家共识出来的架构，执行靠惯性。这也是为什么代码评审那么重要——它不只是在查 bug，更是在维护团队的架构共识。

5.2 误区二：架构要一步到位

年轻的时候我也犯过这个毛病，总想设计一套“完美的架构”，把所有未来可能的变化都纳入考虑。结果呢？抽象越来越重，理解越来越难，最后那套“完美架构”被团队偷偷换掉。架构不是设计出来的，是演进出来的。

更务实的思路是：先找到当前项目最大的一个痛点，针对它做最小的架构调整。比如现在最痛的是接口地址散落各处，那就先统一出一个 service 层；最痛的是权限逻辑到处重复，那就先把权限抽成一个公共模块。一个痛点解决了，团队尝到甜头了，再推进下一个。架构是散步，不是跳崖，一步步来才走得远。

5.3 误区三：架构等于引入某个框架或工具

每每有人问我“我们项目要不要上微前端”，我基本都会反问一句：你要解决什么问题？很多时候，对方回答不出来的。微前端解决的是“多团队独立开发和发布”的问题，如果你的团队只有五六个人，一个工程就能搞定，那上微前端就是在给自己找麻烦——工程复杂度、资源加载、样式隔离、通信成本，每一项都是实打实的代价。

架构的重心永远在人、规范和边界，不在技术选型。工具是手段，不是目的。不要因为一个工具“听起来专业”就引入项目，要看它是否在解决你团队当前真实存在的痛点。

5.4 踩坑实例：一次全局状态管理的重构

讲一个我实际经历过的案例。某团队做中后台系统，一开始为了省事，把所有数据都塞进全局状态管理器，组件本地反而没有状态。刚开始觉得挺方便，什么数据都能从全局拿。但随着数据量变大，问题开始冒出来：本地筛选的结果也存全局，一个表格字段涨到两百多个，多个页面同时操作同一份数据，状态错乱得让人崩溃，排查一次问题要全局搜索半天。

后来做了一次重构，核心动作很简单：确立“本地状态和全局状态分离”的原则——一个数据只有被多个页面共享时，才放进全局状态管理器；否则一律用组件本地状态。就这一个约定，项目的问题解决了一大半。这个案例想说明的是，边界比工具重要。工具本身没有对错，错的是没有边界地使用工具。

6. 前端架构对个人的意义：架构思维是进阶的分水岭

6.1 会写页面和会设计系统的差别

我带人的时候，经常观察一个新同学从“能干活”到“有设计感”的转变。能干活的人，拿到需求就开始写代码，他关心的是“这个功能怎么实现”；有设计感的人，会在写之前停一下，想“这段代码放哪里合适”“这个需求未来可能会怎么变化”“有没有别的地方应该复用这里的逻辑”。

这个差别，就是架构思维。它不是一个需要专门去学的高深技能，而是一种对边界和变化的判断力——知道什么东西该放在一起，什么东西该分开；知道哪些代码会稳定下来，哪些代码会频繁变动。这种判断力，恰恰是前端工程师职业生涯中最值钱的积累。

6.2 如何在日常工作中刻意练习架构能力

架构思维可以练，日常就有很多练习机会。

接手一个老项目，第一件事别急着改代码，先画一遍依赖关系图，搞清楚模块之间的“实际关系”和“应该有的关系”差在哪里。每次重构代码，问自己一句“为什么放这里”，而不是“把这里改完就行”。写新功能之前，多想一步“如果需求变了我怎么改”——这一步能帮你决定代码结构是写死还是抽象。多关注跨页面、跨模块、跨团队协作的地方，前端架构的复杂度，永远在边界上。

6.3 对新人的一句实在话

如果你是刚开始做前端没几年的同学，别被“架构”这个词吓到。它真的不是什么高深的东西。从整理项目目录开始，从给项目写一个清楚的 README 开始，从遵守统一的代码规范开始，你已经是在建立架构意识了。架构不是一个金光闪闪的终点，而是日常写代码时对“秩序”的那一点点坚持。

我个人做前端这些年，最大的体会是：所谓架构，从来不是某个人画出来的一张漂亮设计图，而是团队里每个人每一行代码形成的合力。它是在无数个“这里随便写一下”和“这里还是认真放好”的瞬间里，一点点长出来的。前端当然有架构可谈，而且正因为浏览器把所有复杂度都藏了起来，前端工程师才更需要主动去建立边界——你不在代码里划出边界，需求就会以最混乱的方式把你淹没。

最后给你一个明天就能用的建议：打开你正在维护的项目，找一找有没有“躺错位置”的代码——比如一个工具函数被七八个文件各拷了一份，或者一个页面组件里塞了三个不属于它的职责。把那一个点改好，就是你架构之路的第一个脚印。