企业官网建设流程全解析

1. 先搞明白：项目运行提示network unavailable，问题出在哪一层

1.1 浏览器说的“网络不可用”，其实想表达什么

做web前端开发，尤其是到了第10天这个阶段，很多人的进度已经从“照着课程写登录页”推进到“自己拉一个接口数据渲染列表”了。这个阶段最容易撞见一个特别迷惑的报错：页面能打开，但是请求发出去以后控制台显示network unavailable，或者在Network面板里看到一个红色的失败请求，状态码都没有，只有一行“网络不可用”。

我第一次遇到这个问题，第一反应是电脑断网了，结果网页都能正常打开，微信能收消息，偏偏项目里的接口全挂了。后来才慢慢想明白，浏览器报“网络不可用”，很多时候不是你的网线坏了，而是请求根本没有被成功送到服务器手上，或者服务器压根没有回应。它跟页面打不开是两码事，页面能打开说明静态资源加载没问题，而接口请求失败，说明请求链路里某个环节出了岔子。

这里先给一个基本判断：network unavailable在web前端开发里，通常代表请求被中断、被拦截、或者根本没有到达后端服务。它不是一道有标准答案的报错，更像是一个泛化的提示，具体原因必须自己去查。常见的情况有这么几类：

• 后端服务没启动，前端请求打到了一个不存在的端口；
• 前端请求地址写错，比如本地开发环境应该请求http://localhost:8080/api/user，实际写成http://localhost:8080/user；
• 开发服务器的接口代理配错了，请求发到了自己服务器上，结果服务器再去转发时目标不可达；
• 本地路径里混入了多余的斜杠/拼接错误，导致请求地址变成http://localhost:3000//api/user这种问题；
• 电脑本地防火墙或安全软件拦截了开发服务器的通信；
• 浏览器插件拦截了跨域请求，比如某些广告拦截插件会把本地开发请求一并拦掉。

所以，排查network unavailable，本质上是搞清楚“请求走到哪一步断了”，而不是瞎改代码。

1.2 分清前端报错和网络报错

很多新手容易把“前端报错”和“网络报错”混在一起。举个例子，你用fetch请求一个接口，返回了500状态码，控制台可能也会飘红，但那个是HTTP层面的错误，说明服务器收到了请求，只是服务器内部的代码炸了。这种错误在Network面板里能看到明确的HTTP状态码，并且Response会返回一段后端错误信息。

而network unavailable完全不一样，它在Network面板里往往连状态码都没有。你要是点开那条失败请求，面板里显示的不是“500 Internal Server Error”，而是“Failed to fetch”或者“Net::ERR_CONNECTION_REFUSED”。这就说明TCP连接都没建立成功，更别说HTTP请求了。

这两种错误的排查方向完全不同：

• 看到500/40x状态码，重点去看后端日志，或者后端同事给的接口文档是不是有出入；
• 看到ERR_CONNECTION_REFUSED、ERR_NAME_NOT_RESOLVED、ERR_ADDRESS_UNREACHABLE这一类的，说明前端到后端的网络路径有问题，重点应该放在端口、地址、代理、服务器启动状态这些点上；
• 如果是在移动端调试时看到network unavailable，还要考虑一下局域网IP是否跟开发电脑在同一网段，或者手机是否限制了该网络的访问权限。

理解了这两类的差别，你就能少走一半弯路。别一看到network unavailable就回头检查前端代码，先看Network面板里那条失败请求到底是怎么失败的。

1.3 第一步永远是把DevTools的Network面板打开

我自己的排查流程里，第一件事永远是打开浏览器的开发者工具，切到Network面板，然后刷新页面或重新触发一次接口请求。这一步的目的只有一个：把问题从“玄学”变成“看得见的东西”。

在Network面板里，你会看到这次请求的状态、耗时、请求头、响应头。如果失败，点击那条红色的请求，重点看两个地方：

• 第一个是Headers里的Request URL，确认请求地址到底长什么样。这里经常能发现拼接错误，比如少了/api前缀。
• 第二个是Console里详细的报错文案，比如ERR_CONNECTION_REFUSED说明端口没监听，ERR_NAME_NOT_RESOLVED说明域名解析失败。

有时候浏览器给出的错误文案比较晦涩，我会配合右键那条请求，选择“Copy as cURL”，然后把命令贴到终端里执行。curl的执行结果比浏览器更直白，能直接看到TCP层的连接结果。比如curl输出curl: (7) Failed to connect to localhost port 8080 after 0 ms: Connection refused，那就很清楚了，8080端口上根本没有服务在跑。

这里也提醒一句：在network unavailable这个问题上，千万别凭感觉修。先用DevTools把失败请求的详细信息记录下来，再动手改。否则很可能你改了半天的代码，最后发现是后端服务没启动。

2. 跑通一个前端项目的完整链路：配置、启动、排查

2.1 从仓库代码到本地能跑，缺一不可的几步

第10天这个阶段，很多人已经不再满足于只写单页面，开始接触真实项目结构。这时候经常遇到的情况是：从同事或者课程那里拿到的项目，npm install装完依赖，npm run dev一敲，页面是出来了，但接口全挂，一查发现network unavailable。

要解决这个问题，得先把项目本地运行的完整链路走一遍。一次标准的本地开发启动，其实是这样的流程：

1. 安装依赖（npm install / yarn / pnpm install）；
2. 检查环境变量配置（.env.development、.env.production等文件）；
3. 启动开发服务器（npm run dev）；
4. 前端发起接口请求；
5. 开发服务器把请求按配置转发到真正的后端接口（这一步通常由proxy配置完成）。

很多新手卡在第一步到第五步之间。比如项目里的.env.development配置了VITE_API_BASE_URL=https://api.example.com，但你本地根本没有这个域名的访问权限，那所有请求都会network unavailable。解决办法是把baseURL改成本地接口地址，或者确保代理配置正确。

我还遇到过一种很隐蔽的情况：项目里有多个.env文件，比如.env.development.local和.env.development，而.env.development.local的优先级更高，里面的地址已经过期了。你改了.env.development发现没生效，就是因为被.local覆盖了。这个问题不看到文件内容很难发现，排查的时候一定把项目根目录下所有点开头的配置文件都检查一遍。

2.2 接口代理配置怎么写，才能真正解决跨域

跨域是web前端开发里绕不开的坎。本地开发时，前端跑在http://localhost:5173，后端接口在http://localhost:8080，两个端口不同，浏览器默认是跨域的。如果你的所有请求都是直接写死后端地址，比如fetch('http://localhost:8080/api/user')，大概率会因为CORS限制被浏览器拦截，表现就是network unavailable或者控制台报CORS policy相关的错误。

推荐的做法是使用开发服务器的代理能力。以Vite为例，在vite.config.js里可以这样配置：

// vite.config.js export default { server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, } } } }

这样配置之后，前端请求只需要写/api/user，Vite启动的开发服务器会自动把请求转发到http://localhost:8080/api/user。因为请求是服务器转发的，规避了浏览器的跨域限制。

用Vue CLI或者Webpack的开发服务器，原理也完全一样。核心就一句话：ajax请求发给自己的开发服务器，开发服务器在后端转发给真实接口。

配置代理时最容易踩的坑有两个：

• 一是target地址末尾多加了斜杠，导致转发路径变成http://localhost:8080//api/user，后端路由匹配不上，返回404；
• 二是没有加changeOrigin: true，某些后端会在意请求头里的Host字段，不加这个选项可能导致后端拒绝。

我自己的习惯是在改完代理配置后，强制重启开发服务器。因为proxy配置不像热更新那样能即时生效，有时候改了vite.config.js没重启，请求还是走老配置，排查半天还以为是代理写错了。

2.3 端口占用、后端没启动、地址不对，一网打尽

除了代理，端口问题也是network unavailable的高发原因。开发中常见的情况是：后端同事告诉你接口地址是http://localhost:8080/api，你请求后一直失败，结果一查，8080端口被另一个程序占了，后端服务压根没启动起来。

端口被占用很好排查。Windows下用netstat -ano | findstr 8080，Mac/Linux下用lsof -i :8080，就能看到是哪个进程占用了端口。如果发现端口被无关程序占用，可以直接结束对应进程，或者跟后端确认一下换一个端口。

还有一种情况是后端的服务启动了，但只监听了127.0.0.1，没有监听0.0.0.0。这种情况下面向真机调试（比如手机访问电脑上的前端服务）时，其他设备无法访问，表现也可能像网络不可用。遇到这种问题，需要让后端把监听地址改成0.0.0.0，或者你直接通过电脑本机访问。

我把这个阶段的排查经验整理成一个清单，照着做基本能覆盖大部分问题：

这个清单我基本存在本地笔记里，遇到同类问题直接对照排查，效率很高。

2.4 再啰嗦一句：本地服务与浏览器之间的隔离

最后补一个很多人忽视的点：有时候network unavailable不是请求真的失败，而是开发服务器的热更新丢了连接。举个例子，你用Vite开发时，可能偶尔会看到页面右上角提示“网络异常，加载失败”，刷新一下又好了。这种情况多半是WebSocket连接因为电脑休眠、网络切换等原因被断开了，前端页面试图通过WebSocket重新同步代码，但连不上开发服务器。

遇到这种，最直接的办法就是刷新页面或者重启开发服务器。别一看到network unavailable就怀疑是接口问题，先刷新页面试一次。如果刷新后接口恢复正常了，那大概率是设备休眠或网络切换导致的临时断连，属于环境问题，不是代码问题。

3. 第10天前后，用一个小项目把技术点钉死

3.1 一个适合当前阶段练手的项目选型

学到第10天，基础三件套（HTML/CSS/JavaScript）应该已经过完一遍，Vue或React也上手了一部分。这个时候最忌讳的就是继续跟着视频一课一课往下看，看得再多不动手全是白费。比较好的做法是割一段整块的时间，自己从头搭一个小项目，把知识点串起来。

项目选型上，我不建议一上来就做一个大而全的后台管理系统，那样会陷入大量重复的表格和表单中，技术含量低还容易让人失去兴趣。比较适合第10天阶段的项目是带有明确交互和数据请求的小型应用，比如：

• 一个待办事项管理系统（增删改查、过滤、本地存储）；
• 一个天气查询应用（对接公开天气接口、城市搜索、加载状态）；
• 一个迷你博客（文章列表、详情页、评论交互）。

我个人的推荐是待办事项管理系统。原因很简单：需求明确、实体单一、方便扩展。它天然包含了列表渲染、事件绑定、表单提交、状态管理、本地持久化、排序筛选这些web前端开发里的高频操作，做完一轮，等于把之前零散的知识点全部串联了起来。

3.2 组件怎么拆、状态怎么管，一次说透

以React为例（Vue的思路几乎一样），做一个待办事项管理，我习惯把组件拆成三层：

• 最外层是TodoApp，负责整体状态管理和数据存取；
• 中间是TodoInput和TodoList，一个负责输入新增，一个负责列表展示；
• 最内层是TodoItem，负责单条待办的展示和操作（完成、删除）。

这个拆分逻辑的出发点是“状态往上走，事件往下传”。所有待办数据都存放在TodoApp里，输入框要新增一项，就通过父组件传入的回调函数把数据提交上去；列表组件只负责展示数据并通知父组件“用户点了某一条”。

状态管理这一块，第10天阶段直接使用组件自带的state就够了，不需要引入Redux或Pinia这样的大工具。先用原生方案把状态流的“单向数据流”思路吃透，之后再学状态管理库就会快很多。

拿React举例，核心状态大概长这样：

const [todos, setTodos] = useState([ { id: 1, text: '学习web前端基础', completed: false } ]); function addTodo(text) { const newTodo = { id: Date.now(), text, completed: false }; setTodos([...todos, newTodo]); }

这里只用了两个API：useState声明状态，setTodos更新状态。整个页面的数据流非常清晰：用户操作 -> 触发回调 -> 更新状态 -> 重新渲染列表。

这个小项目做完之后，我建议你做一个额外动作：把数据持久化到localStorage里。这样刷新页面后待办还在，体验上更像一个真正的应用。实现思路也很简单，读取时用localStorage.getItem，写入时用localStorage.setItem，在状态更新后同步一次即可。

3.3 没有后端也能开发：Mock数据的正确姿势

很多第10天的学习者会卡在一个现实问题上：自己没有后端接口，怎么办？前端开发的一个核心技能就是在没有后端时自己造数据。这不是投机取巧，而是实际工作中非常常见的需求，前后端并行开发时，前端必须等后端接口或者先mock一份模拟数据。

最朴素的mock方式，是在本地建一个数据文件（比如mock/data.js），然后在请求拦截层做判断：如果开发环境，直接返回本地数据；如果是生产环境，走真实接口。

// 简单版mock const useMock = import.meta.env.DEV; export async function fetchTodoList() { if (useMock) { // 模拟网络延迟 await new Promise(resolve => setTimeout(resolve, 300)); return [{ id: 1, text: 'mock数据', completed: false }]; } const res = await fetch('/api/todo'); return res.json(); }

这样做的好处在于，你在代码里一直按“异步请求”的方式写，到后续拆掉mock、对接真实接口时，改动的成本极小。

再往深走一点，可以使用json-server这个工具，一条命令就能在你本地起一个REST风格的数据接口服务。第10天阶段非常推荐试一次，体验一下“前端开发真的与后端有个数据交换过程”是什么感觉。

提示：mock数据的时候，一定养成一句话注释的习惯，写明“这段数据是mock的，接入真实接口后怎么替换”。短期可能觉得没用，但过一个星期再回来看自己的代码，你会感激这个习惯。

3.4 做这个小项目时最值得注意的三个细节

第一，空状态必须处理。列表没有数据时不能白屏，要显示“暂无待办，去添加一条吧”之类的提示。很多新手只顾着写完整数据的样子，忘了空数组也是UI的一部分。

第二，加载状态要设计。即使本地mock数据只有300毫秒延迟，也要有一个加载中的反馈。这不只是体验问题，更是代码健壮性的体现。真实接口的延迟可能是秒级的，没有加载状态，用户会以为页面坏了。

第三，操作不可逆要注意。删除一条待办前，如果有重要数据，应当设计二次确认或者支持撤销。这个小细节在很多大厂面试和实际需求中都会被考到，因为产品经理永远会追问“删错了怎么办”。

我自己的习惯是，每完成一个小项目，就顺手写一个十几行的README，里面记录的除了启动命令，还有项目里遇到的一个坑和一个亮点。这个记录不是为了给别人看，而是为了让自己在面试或者复盘时有据可查。真实面试时，面试官问“你做过什么项目”，你能把细节说到“那个列表的筛选状态我放到了父组件里，因为需要跟接口的分页参数联动”，这个深度和只能泛泛而谈的人完全不一样。

4. MCP技能入门前端开发：新的工作方式已经不远

4.1 MCP技能不是玄学，是一套连接协议

最近web前端相关的讨论里，MCP这个缩写出现的频率越来越高。MCP的全称是Model Context Protocol，模型上下文协议。它解决的核心问题是：让AI工具能够安全地接入外部数据和工具，为代码生成提供更加可靠的上下文。

第10天的学习者可能觉得这个东西离自己还很远，但实际上，MCP正在悄悄地改变前端开发的工作流。过去你写代码是IDE加人脑，偶尔用AI辅助，但AI对项目结构、当前文件上下文、组件库版本这些信息可能都是“蒙的”。有了MCP之后，AI可以通过协议读取项目配置、查看文档、访问组件库的API，甚至能够直接执行一些安全的构建命令。

用一个浅显的类比：以前用AI辅助编程，像是请了一个没有看过你项目的远程顾问，你问他问题，他只能凭经验猜；有了MCP，相当于这位顾问拥有了一个可以直接查阅你项目资料的接口，给出的答案更有依据。

4.2 前端开发者通过MCP能获得什么

具体到web前端开发，MCP技能能带来的帮助主要有三个方向：

第一个方向是项目上下文理解。AI不再需要你一遍遍把代码复制给它，而是可以通过MCP技能读取你当前打开的文件、项目的依赖清单、代码规范配置，甚至能查看最近修改记录。这样生成的代码在命名风格、文件组织、依赖选择上会更贴近你的项目。

第二个方向是组件库和设计系统的接入。团队如果维护了自己的组件库，通过MCP可以把组件名称、属性说明、使用示例同步给AI工具。这样AI生成的业务页面，直接使用团队已有的组件，而不是每次生成一套类似但不完全一致的按钮和表格。

第三个方向是文档与接口的实时获取。开发过程中最繁琐的事情之一就是查文档。前端框架更新快，组件多，今天用到一个API不记得参数了，又要去翻文档。MCP技能可以把这个过程变成：AI自动检索对应版本的技术文档，把准确用法直接带到编辑器里。

这一块我自己的体会是，现阶段MCP技能的生态还在快速演进中，工具链也还不完全统一，但趋势已经很明确了——AI辅助开发正在从“聊聊天”走向“接入系统”。作为前端开发者，现在了解MCP的基本概念和应用场景，至少能保证工具真正成熟时不至于重新学起。

4.3 让MCP在前端工作流里真正发挥作用

实际操作上，你不需要立刻去开发一个MCP服务器，可以先从使用现成能力开始。不少编辑器与AI编程工具已经支持自定义MCP配置，你可以在配置文件里添加一个MCP服务的地址，然后工具就能自动加载对应的技能。

一个典型的最小配置长这样：

{ "mcpServers": { "web-docs": { "command": "npx", "args": ["@some-mcp/docs-server"], "env": { "DOCS_DIR": "./docs" } } } }

配置好之后，AI工具会在合适的时候自动调用这个MCP服务，去docs目录下查找与当前任务相关的文档，而不是凭空猜测API用法。

对于前端项目来说，比较有价值的MCP场景包括：

• 连接UI组件库的文档，生成页面时自动匹配可用组件；
• 连接项目的代码规范文件（ESLint、Prettier配置），让生成的代码自动符合团队规范；
• 连接接口文档平台，自动获取接口定义和字段说明，从而生成类型声明和请求代码。

需要注意的是，MCP技能并不是越多越好。每个MCP服务器都会消耗开发工具的资源和上下文窗口。我自己一般只保留两到三个最常用的，其他按项目需求临时开启。这一点的取舍逻辑跟安装依赖一样，宁缺毋滥。

4.4 现阶段怎么评价MCP对前端开发的价值

说到底，MCP技能现在还是一个“优化开发流程”的工具，而不是一个“取代开发能力”的魔法。一个完全不懂前端基础的人，即使配置再多的MCP技能，也写不出合理的组件划分和状态管理代码。

所以我的建议是：第10天这个阶段，先把前面讲的基础打好，把network unavailable这类问题吃透，把一个小项目真正写完。MCP了解概念即可，可以试着配置一次，感受一下工具链的变化，但不要本末倒置。真正决定你能走多远的，仍然是HTML、CSS、JavaScript这些底层知识的扎实程度。

5. 面试题常考点提前过一遍，比临时抱佛脚有用

5.1 闭包、作用域链、this指向，别光背概念

web前端面试几乎是必问JavaScript基础的，而闭包、作用域链、this指向这三件套是出现频率最高的组合。

闭包的常见考法是让你解释闭包是什么，并写出一个使用闭包的例子。光背“函数内部函数可以访问外部变量”是不够的，更好的是能说清楚闭包的形成条件、带来的内存问题以及实际用途。

比如一个典型的闭包例子：

function createCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = createCounter(); console.log(counter()); // 1 console.log(counter()); // 2

这道题背后考察的是“词法作用域”和“函数作为返回值”的机制。答的时候如果能顺带提到闭包里变量不会立即释放，使用不当会造成内存泄漏，一般会让面试官觉得你是真懂的，而不是背了题。

this指向的题目更烧脑一些，核心记住一句话：this指向取决于函数被调用时的调用方，而不是定义位置。普通函数里指向全局对象，对象方法里指向该对象，箭头函数没有自己的this，跟着外层作用域走。遇到fn.call(obj)、fn.apply(obj)、fn.bind(obj)这种，就是把this手动绑到指定对象上。

5.2 CSS布局和BFC，面试官真的有在听你的回答

CSS部分的面试题，除了flex居中的三种写法这种送分题，更爱问的是BFC（块级格式化上下文）。

BFC的理解方式可以类比成一个独立的容器，容器内部的布局不会影响外部元素。触发BFC的方式有overflow: hidden、display: flow-root、position: absolute等。两个常见应用场景是：父容器高度塌陷时，给父容器创建BFC就能包裹住浮动的子元素；两个相邻的margin会合并成一个较大的margin，想避免合并，让其中一个元素处于BFC里就行。

答BFC的时候最好结合一个实际发生的问题，比如“我遇到过一个高度塌陷的问题，网上一搜说是要用overflow:hidden，我当时不理解为什么，后来才知道是因为创建了BFC”。这句话一出来，面试官对你的好感度会明显提升。

5.3 页面性能优化，不要背那种没人用的列表

性能优化的题目，十个人里八个人都会回答“图片懒加载、JS和CSS压缩、CDN加速、开启gzip”。这些答案没有错，但太泛了，面试官一听就知道是背书。

更好的答法是从实际指标入手，比如“页面首屏加载速度”。把这个问题拆开：

• 首屏资源有哪些，哪些是可以延迟加载的；
• 接口请求能不能做合并，能不能做缓存；
• 图片资源有没有体积过大的问题，需不需要转成WebP；
• 项目构建产物有没有被拆包，公共依赖是否可以单独抽出；
• 白屏期间用户看到了什么，有没有loading状态。

面试官真正想听的，是你有没有真的思考过“一个页面从输入URL到显示出来的过程中，哪些地方最容易耗时，我能做什么来减少这个耗时”。所以第10天阶段，你不需要把性能优化吃得很深，但至少要能把一个具体的优化点从头到尾讲明白。

5.4 工程化问题怎么答才不会显得虚

工程化相关的常见问题包括：npm install的流程、模块化的发展、Webpack的核心概念、Vite为什么快。新手容易犯的错是只背名词，比如“Webpack是一个模块打包工具，它把各个模块打包成静态资源”，说完就没了。

我建议你的回答遵循一个结构：解决什么问题 -> 核心机制是什么 -> 我实际用过哪个配置 -> 遇到什么问题。以Vite为例，可以这样说：Vite解决的问题是传统打包工具在开发环境下的启动慢问题，它利用现代浏览器的原生ESM支持，开发时不打包、直接按需加载模块，所以冷启动很快。我在项目里第一次用Vite时，最大的感受是修改代码后的热更新几乎是瞬时的，不像以前Webpack那样要等一两秒。这样答，既有知识深度又有真实体感。

5.5 回答问题时的节奏感，也是可以被练习的

最后分享一个面试里很实用的技巧：遇到不会的问题，不要直接说“不会”然后沉默。你可以先说出与之相关的、你确定的知识点，然后诚实表达“这个具体的实现细节我还需要进一步了解”。比如被问到“React的useEffect执行时机”，你就算忘了确切机制，也可以先答出“useEffect是在组件渲染后执行的，依赖项变化时会重新执行”，再往下深入。

面试官要的不是一台行走的百科全书，而是一个有扎实基础、有学习能力、有沟通意愿的候选人。这个状态其实是装不出来的，它来自平时的积累和复盘。如果你在第10天就已经开始看面试题，说明你在认真对待这条技术路，这个起点本身就是优势。