企业官网建设流程全解析

2026年的前端生态，变化速度比前两年更快了。上个月在团队内部做技术分享时，我把这一年接触到的关键知识点重新梳理了一遍，发现最值得记录的并不是某个源码细节，而是几个影响工作方式的趋势和排错思路。这一期总结，我挑了四个方向来聊：MCP skills怎么真正落地到前端项目里、前端项目运行时报“network unavailable”该怎么定位、性能优化里新指标和新开销要怎么看，以及工程化选型时微前端、模块联邦、Monorepo之间到底怎么取舍。

如果你正在学web前端，或者做了一两年但感觉知识碎片化，这一篇应该能帮你把很多零散信息串起来。我写的所有东西都来自实际项目里的真实场景，包括踩过的坑和最终找到的解法，不是教科书式的定义堆砌。

1. MCP skills：2026年前端开发绕不开的协作方式

1.1 MCP解决了前端开发中的什么问题

MCP全称Model Context Protocol，模型上下文协议。说人话，它是AI编程助手和外部工具之间的“通用插座”。以前想让AI读取项目文件、操作浏览器、查接口文档，每个工具都要用各自的接口，而且只能在某个特定IDE里用。MCP出现之后，只要工具支持MCP协议，就能用统一方式把能力暴露给AI模型。

跟前端开发的直接关系是什么？我举几个场景：

• 你想让AI理解整个项目结构，而不是手动把十几个文件贴进对话里。MCP文件服务器可以让AI直接读取项目目录，知道src下有哪些页面、组件、路由配置。
• 你想让AI自己启动项目、运行lint、执行测试。MCP命令服务器能帮它执行终端命令，并把输出返回给模型。
• 你想让AI帮忙排查浏览器报错。通过Playwright的MCP，AI可以自动打开页面、点击元素、读取console日志。
• 你希望AI按照Figma设计稿标注生成代码。Figma官方MCP可以直接把设计稿的结构、字号、颜色、间距传给AI。

一句话概括：MCP解决的，是AI从“只能看对话里贴的代码”进化到“自己去看项目、跑项目、调试项目”的衔接问题。

1.2 一套可落地的MCP配置示例

很多同学看到“MCP”觉得是个很玄的概念，其实落地起来很简单。以我常用的Cline和Claude Desktop为例，配置是一个JSON文件，指向几个MCP server即可。

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects/my-web-app/src" ] }, "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }, "git": { "command": "npx", "args": ["-y", "mcp-server-git"] } } }

这里我加了三个MCP server：filesystem负责读项目源码目录，playwright负责浏览器操作，git负责查log和diff。配置保存后，在AI工具里重新加载MCP列表，工具列表里就能看到这些技能。

实际使用中，我会让AI先通过filesystem扫描项目目录，了解大致的模块划分；再让它用git看看最近的提交记录，搞清楚最近改了什么；如果涉及页面交互问题，就让它用playwright起个浏览器实际复现。

1.3 我用MCP定位线上问题的实际效果

前一阵，团队一个React项目的表格组件出现了“点击刷新按钮后loading一直不消失”的问题。以前遇到这种问题，流程是：我手动翻代码，找loading的状态定义在哪个组件，再追setLoading的调用链路，一步步看哪里被覆盖了。

这次我直接把问题抛给配置好MCP的AI，让它自己查。它先通过filesystem扫描到表格组件文件，定位到loading state定义在父组件，然后通过代码搜索找到两个地方调用了setLoading：一个在请求开始前设为true，一个在请求结束的then里设为false。问题出在有个分支提前return，导致loading没有被复位。整个过程AI大概花了三分钟，它自己翻文件、自己搜索、自己给出结论。

这个效果并不是AI替我做了决策，而是它节省了最消耗精力的“翻代码找线索”的时间。对我这种经常接手历史项目的人来说，MCP相当于一个能快速阅读整个代码库的实习生，把定位问题的效率提高了不少。

1.4 MCP的坑：配置乱、权限散、幻觉多

MCP好用，但不等于完美。我踩过的坑主要有几个。

第一，MCP server启动失败。npx每次都会去拉取最新包，在公司内网或网络波动情况下，很容易卡在下载阶段。建议在MCP配置里固定版本号，或者把常用server装在本地用绝对路径启动，不要每次都用npx临时拉取。

第二，权限控制容易被忽视。filesystem MCP只给你指定的目录读权限，如果你只给了一个src目录，AI想看配置文件时什么都读不到，会错误地“猜测”配置内容。所以配置权限范围时，要综合评估：既要控制敏感文件访问，又要让AI能获得足够上下文。

第三，AI幻觉在MCP场景下同样存在。MCP返回的内容会被模型当成“事实依据”，但模型依然可能在整合信息时产生错误推断。有一次AI根据它翻到的部分代码，自信地判断某个状态没有被初始化，实际上初始化逻辑在另一个子模块里，它没读到。所以AI给的结论，最终还是要人工验证一遍。

2. 一次前端项目运行报“network unavailable”的定位全过程

2.1 先分清报错出现在哪个环节

“network unavailable”这个报错，相信在前端开发中并不少见。但它出现在不同环节，含义完全不同。

浏览器地址栏访问http://localhost:5173时，页面显示网络不可用，这是网络层面的问题，说明浏览器根本无法和本地服务建立连接。而页面能打开，但是某个接口请求出现ERR_NETWORK_CHANGED或者超时，那就是请求链路的问题。还有一种是终端执行npm install时报network unavailable，那是包管理器下载依赖时无法访问源站的问题。

我以前容易犯的错，是一看到“network”就怀疑是网络大环境问题，先折腾路由器、DNS之类的外围设置，搞了半天发现其实问题就在自己电脑上。正确的做法是，先用一个标准问题逼自己定位：这个请求到底是从哪里失败的？

2.2 按链路排查：从本地服务到浏览器请求

我总结了一条相对固定的排查链路，按顺序走一遍，大部分问题都能定位。

第一步，确认dev server还活着。终端里按下Ctrl+C重启，或者看下端口监听。

# macOS/Linux lsof -i :5173 # Windows netstat -ano | findstr :5173

如果端口处于LISTEN状态，说明服务正常。如果没有任何输出，说明dev server没起来或者已经崩了。我遇到过不少次，终端窗口输出还留在屏幕上，但实际上进程早被系统结束了。

第二步，直接在终端里请求本地服务，绕过浏览器。

curl -I http://localhost:5173

如果curl能拿到HTTP响应，说明服务正常，问题出在浏览器或系统网络设置。如果curl也失败，说明服务本身或防火墙有问题。

第三步，检查系统代理设置。这一步特别容易踩坑。macOS和Windows的系统设置里开启某个代理/PAC脚本后，浏览器对localhost的请求也可能被代理接管，而代理服务器本身又连不通，就会报network unavailable。解决方法是把localhost、127.0.0.1加入代理忽略列表。比如在macOS的网络设置中，把“忽略这些主机与域的代理设置”里加上localhost、127.0.0.1、*.local。

第四步，检查hosts文件和DNS解析。本地开发环境中，/etc/hosts或C:\Windows\System32\drivers\etc\hosts里如果出现了奇怪的localhost映射，也会导致访问异常。用nslookup localhost可以快速确认解析结果是否正常。

第五步，如果是接口请求报错，直接用curl测试后端接口地址，确认后端服务是否可访问、路径是否有误。很多情况下，登录页能打开，但登录接口报network unavailable，其实是vite的proxy把接口转发到了一个错误的后端地址。

2.3 这几个根因最容易被忽略

下面这个表是我在实际项目中遇到过的真实根因，也是排查时最容易被忽略的地方。

其中，WSL场景是这两年前端开发里出现频率很高的坑。WSL2里启动Vite，默认监听的是WSL内部的localhost，但Windows浏览器访问时走的是NAT网络，两者不是同一个网络环境。解决方案是在Vite配置里显式设置host：true，启动时使用--host 0.0.0.0，再用Windows浏览器访问WSL的IP或localhost对应的端口。

2.4 写个检查脚本，让这类问题一次定位

排查链路固定下来之后，我干脆写了个小脚本，一行命令把最关键的几项全检查一遍。

#!/bin/bash # 用法: ./check-dev.sh 5173 PORT=${1:-5173} echo "== 1. 检查端口监听 ==" lsof -i :$PORT | grep LISTEN || echo "端口 $PORT 无监听" echo "== 2. 请求本地服务 ==" curl -s -o /dev/null -w "localhost:%PORT -> HTTP %{http_code}\n" http://localhost:$PORT || echo "localhost 请求失败" curl -s -o /dev/null -w "127.0.0.1:%PORT -> HTTP %{http_code}\n" http://127.0.0.1:$PORT || echo "127.0.0.1 请求失败" echo "== 3. 检查代理环境变量 ==" echo "HTTP_PROXY=$HTTP_PROXY" echo "HTTPS_PROXY=$HTTPS_PROXY" echo "NO_PROXY=$NO_PROXY" echo "== 4. 检查 hosts 中的 localhost ==" grep -E "localhost" /etc/hosts || echo "无 localhost 映射"

脚本输出的结果直接告诉我服务端口有没有监听、能不能被访问、有没有残留的代理环境变量。它不能解决所有问题，但能帮我快速排除掉一大半环境因素，剩下的才是代码层面的问题。

我个人的习惯是，遇到这类报错先别动代码，先用这个脚本跑一遍，确认基础环境没问题再开始看业务逻辑。很多时候，问题真的不是代码写错了，而是电脑的网络状态变了。

3. 2026年前端性能优化：新建模、新开销、新工具

3.1 INP成为新的性能“硬指标”

如果过去一年你只关注性能优化里的LCP和CLS，那2026年的性能优化视野需要再扩一圈。INP（Interaction to Next Paint，交互到下一次绘制的时间）已经取代了FID，成为Core Web Vitals里的交互指标。

为什么会有这个变化？FID只统计用户输入到浏览器开始处理事件的延迟，不包含事件处理函数的执行时间，也不包含界面渲染的耗时。而用户真正感受到的卡顿，往往发生在事件处理函数执行了很长的同步逻辑、或者渲染阶段需要大量布局计算的情况下。INP则覆盖了从用户输入、事件处理、到下一帧绘制完成的完整链路，更贴近真实体验。

优化INP，我建议先监控主线程长任务。在Chrome DevTools的Performance面板里看时间线，如果出现明显的红色长任务，就用requestIdleCallback、scheduler.yield或者Web Worker把耗时计算拆出去。同时，事件处理函数里避免大面积DOM操作，尤其是循环中反复读写样式会导致强制同步布局和布局抖动。这两个方向是目前减少INP最有效的手段。

3.2 客户端AI带来的性能开销该怎么扛

2026年前端一个绕不开的新课题，是客户端AI能力引入后的性能平衡。越来越多产品选择在浏览器里直接运行完整体验较好但资源消耗较大的模型能力。曾经我以为WebGL推理已经很成熟，直到在项目中尝试给一个在线绘图工具加上AI辅助图层识别，才发现模型加载和推理跑在浏览器端时，首屏体验受到的压力比想象中大得多。

原因在于，模型文件动辄几十到几百MB，推理过程又需要消耗大量GPU和内存资源。如果直接在主线程里初始化模型，页面几乎是冰住的。我现在的做法是：

• 把模型加载逻辑放到Web Worker里，避免阻塞主线程；
• 在用户点击“开始识别”后再懒加载模型，不要在首屏提前拉取；
• 对移动端做降级处理，设备内存低于4GB或WebGPU不可用时，自动切到服务端API；
• 推理过程中使用OffscreenCanvas处理图像，隔离渲染上下文的压力。

这些措施并不能消灭AI功能的性能开销，但能把影响控制到用户可接受的范围。性能优化和产品体验本来就是一场平衡术，AI能力引入之后，平衡的难度又上了一个台阶。

3.3 一次LCP从3.2秒降到1.8秒的实战记录

说一个真实的优化案例。某个内容站首页，LCP一直徘徊在3.2秒左右，目标是压到2秒以内。一开始看报表示意图，第一反应是加CDN、上Brotli压缩，结果压完并没有显著改善。

后来认真分析LCP元素，发现页面主视觉是一张背景图，用CSS写在样式表里的。图片被浏览器识别为背景图，加载优先级很低，要等CSS加载完、渲染树构建之后才开始请求，天然就慢了半拍。同时，首页首屏还加载了大量非关键脚本，阻塞了解析。

优化方案也很朴素：把背景图改成<img>标签，加上fetchpriority="high"，让浏览器提前知道这是关键资源；同时给首屏非关键脚本加上defer和async。另外，图片本身从JPEG换成了AVIF格式，体积降了35%。这一套组合拳下来，LCP直接压到1.8秒。

这个案例的启发是：性能优化的第一刀不是堆技术，而是确认关键资源有没有被浏览器以正确的优先级加载。fetchpriority、preload、modulepreload这些属性，用对了能解决很多“看起来加了CDN也没用”的问题。

3.4 性能监控的埋点思路

指标和优化手段再多，不埋点等于白做。团队现在的做法是用PerformanceObserver收集Web Vitals数据，上报到自己的监控平台，并区分环境。

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'largest-contentful-paint') { reportMetric('LCP', entry.startTime); } } }); observer.observe({ type: 'largest-contentful-paint', buffered: true });

关键思路是：生产环境全量上报，预发布环境抽样上报，本地开发环境直接不上报。同时要记录设备类型、浏览器、联网类型等上下文信息，否则你分不清一个LCP长任务是卡在弱网还是低端设备上，定位成本会非常高。

4. 前端工程化选型：模块联邦、微前端与Monorepo别再混为一谈

4.1 它们解决的分别是哪一层的问题

聊到前端工程化，很多团队会直接把微前端、模块联邦、Monorepo放在一起对比，实际上它们解决的完全不是同一个问题。

Monorepo解决的是“代码怎么放”的问题——把多个应用或包放在同一个仓库里，共享代码、统一依赖管理、跨项目复用。你可以用pnpm workspace或Turborepo来管理。

模块联邦解决的是“运行时代码怎么共享”的问题——多个独立部署的应用，在浏览器端远程加载某个共享组件或模块，比如跨应用复用登录组件、权限组件。这是Webpack 5时代就开始流行的方案，现在Rspack也支持。

微前端解决的是“组织架构和应用边界怎么拆”的问题——多个团队维护同一个产品，技术栈可能不同，发布节奏不同，用微前端把页面切分成多个自治的子应用。

这三者不冲突，可以叠加使用。一个典型的大型项目可能是：Monorepo管理多个应用和共享包，微前端拆分技术栈和团队边界，模块联邦在运行时共享公共组件。但问题是，很多项目根本没有走到需要这种复杂度的阶段。

4.2 什么情况别上微前端

我见过太多团队，项目总共不到二十个前端开发者，业务边界也谈不上清晰，却非要上微前端。最后的结果往往是：子应用之间通信要设计一套事件总线，样式互相污染，切换应用时白屏，报个bug要跨三四个仓库排查，维护成本直线上升。

我自己现在的判断标准很简单：如果团队只有一个前端小组，所有模块由同一批人维护，发布节奏也一致，那就别上微前端。把多个页面拆成多个子应用，除了增加技术复杂度，没有任何实际收益。这种情况下，我更建议用Monorepo把代码管理起来，把共享的业务组件和工具函数抽成包，让同一团队用统一的技术栈简单维护。

如果确实有多个团队、技术栈异构、各自独立发布这些硬性条件，再考虑微前端也不迟。而且现在微前端方案成熟度已经很高，wujie、micro-app这类方案都经过了大量生产验证，不用重复造轮子。

4.3 2026年的构建工具变化怎么看

前端构建工具这两年的变化，对工程化选型也有实际影响。Rspack已经成了很多新项目默认选择的构建器，它兼容Webpack的配置和生态，编译速度却能快一个量级。Vite生态里的模块联邦插件也逐步成熟，用Vite搭建的应用可以和生产环境的Webpack应用互相共享模块。

这些变化让模块联邦的适用面从“Webpack专属”扩展到了更多场景。做选型时，不用再被构建工具绑定住，先想清楚你要的是“运行时代码共享”还是“代码仓库统一”，再选择对应的方案组合。

我个人的建议是，新项目从“Monorepo + 简单模块化”起步，先把代码组织好，等真实出现团队边界或独立发布需求时，再引入微前端或模块联邦。很多人喜欢一步到位、一次把架构拉满，但复杂架构的维护成本是随规模非线性上升的，过早引入只会拖慢迭代速度。

在我参与的团队里，这个选型思路经过几轮项目验证，整体开发效率比之前“一开始就上微前端”的阶段稳定很多。做架构决策时，问问自己：这个问题是我的真实痛点，还是我为了学习某个技术体系而制造出来的需求。这个问题的答案，往往比技术文档更能帮你做决策。