二月底的时候，我还在学校宿舍里对着电脑屏幕刷题。大专大二，前端方向，手里只有一个自己搭的博客项目和一份刚写到一半的Vite脚手架源码。说实话，这个配置放到暑期实习的池子里并不起眼，但我很清楚一件事：我缺的不是技术深度，而是一套能把“我会的东西”讲清楚的能力。这篇面经实录，就是我在这两个月里摸爬滚打总结出来的东西，覆盖了脚手架搭建、HTTP、XSS这几个面试里被反复问到的核心模块，也记录了每一道题背后面试官真正想听的答案逻辑。
写这篇文章的初衷很朴素：前端八股文满天飞，但大多是“背诵版”，很少有人告诉你面试官为什么这么问、你答到哪一步算过关、哪些细节能帮你把普通答案变成亮点。我希望用自己的真实经历，帮你把这些硬骨头啃下来，尤其是跟我一样学历不占优势、想靠实力拼一把暑期实习的同学。
1. 面试准备与整体策略
1.1 大专大二前端选手，起点低不代表没机会
先交代一下背景吧。我读的是专科，大二下学期，前端基础大概是：HTML/CSS/JavaScript 都能写，Vue3 和 React 都上手过小项目，Node.js 会写简单的接口，但没接触过复杂的工程化配置。投暑期实习之前，我先把目标岗位的要求翻了一遍，发现中小公司普遍看重三件事：能不能独立交付页面、懂不懂工程化工具、知不知道常见安全漏洞。
大专生的简历投出去，确实容易在第一轮被筛掉，这个我承认。但我后来想明白了一件事：暑期实习的筛选标准和校招不一样，很多团队要的是“能干活、肯学习、不捣乱”的人。学历不够，就用项目经验来凑；项目不够亮眼，就在面试表现里让面试官感受到你的成长速度。我那份脚手架项目，在技术上不算多高深，但因为它是我一行一行从零写的，每个配置项我都能说出用途和踩过的坑，这反而成了面试中最大的加分项。
所以如果你也是大二、学历普通，别急着否定自己。把“我会什么”和“我能讲透什么”对齐，比堆砌一堆没深入用过的技术名词重要得多。面试官一天面好几个人，对面坐的是一个能流畅讲清楚原理的候选人，还是一个背了一堆名词却一问就卡壳的候选人，差别太大了。
1.2 我的准备路线：项目、八股、算法三线并进
我的备考节奏大概持续了两个月，分成三个方向并行：项目线、八股线、算法线。项目线就是把脚手架项目重新过一遍，每一个配置、每一段代码都自己重新写一遍，确保面试被问到细节时不会卡壳。八股线我按主题整理了笔记，重点就是 HTTP、XSS、浏览器渲染、事件循环这四块，每一块都写了自己的理解，而不是直接抄别人的答案。算法线我用的力扣热题，主要刷数组、字符串、链表和简单动态规划，目标不是做难题，而是把常见题型的思路练熟。
说句实在话，大专生的课余时间其实很多，比起本科生少了很多课程压力，这反而是优势。我每天固定花3小时在项目上、2小时刷八股、1小时写算法，坚持了两个月。中间有一段时间真想放弃，看着一堆感觉永远背不完的知识点，整个人特别焦虑。后来我把备考从“学不完”调整成“抓重点”，只围绕面试高频考点展开，心理压力瞬间小了，效率也上来了。
2. 脚手架的搭建，面试官到底想考什么
2.1 从零搭建 Vite 脚手架的完整思路
我那个项目是用 Vite 从零搭的一个 React + TypeScript 脚手架，没有直接用 create-vite 一键生成。刚开始我室友觉得我闲得慌，明明有现成工具不用，非要自己折腾。但我心里清楚，面试官看简历的时候，一封“手动搭建脚手架”的项目描述，含金量比“熟悉 webpack/vite”高得多。因为手动搭建意味着你知道每个依赖为什么存在、每个配置解决什么问题，这是一键生成给不了的能力。
搭建的核心思路分四步走。第一步是初始化工程，用 npm init 生成 package.json，然后手动安装必要依赖：react、react-dom 是运行时依赖，typescript、vite、@vitejs/plugin-react 是开发依赖。第二步是配置 TypeScript，创建 tsconfig.json，把 strict 模式打开，这样能在编译期拦截大量低级错误。第三步是写 vite.config.ts，配置插件、别名和开发服务器。第四步是搭目录结构，区分 src、public、components、pages 等目录，并配好 eslint 和 prettier 保证代码规范。
这里有一个很重要的经验：如果你在简历上写了“从零搭建脚手架”，那就一定要能回答出每个依赖的作用。比如 @types/react 和 @types/react-dom 是 TypeScript 识别 React 类型声明的关键，没有它们，JSX 文件会报一堆类型错误。再比如 vite 的 optimizeDeps 配置，作用是预构建依赖，能显著提升开发服务器的启动速度。这些细节看似小，但面试官一听就知道你是真写过还是只是抄了别人的配置。
2.2 面试现场被追问的配置细节
面试的时候，面试官对我的脚手架问了三个印象很深刻的问题。第一个是“Vite 和 Webpack 的区别是什么”，我答了三条：开发服务器启动方式不同，Vite 基于原生 ES Module 按需编译，Webpack 需要先把所有模块打包再启动，所以 Vite 冷启动更快；构建流程不同，Vite 在生产环境用 Rollup 打包，Webpack 自研打包流程；配置复杂度不同，Vite 的开箱即用程度明显更高。
第二个问题是“你配置的 proxy 是怎么工作的”。我解释说 devServer 会拦截匹配到 /api 的请求，把 target 重写到后端地址，同时利用 changeOrigin 修改请求头中的 Host 字段，防止后端做域名校验时报 403。为了说明我是真懂，我还补充了为什么生产环境不能用 proxy——因为生产环境通常由 Nginx 做反向代理，开发服务器的 proxy 只服务于本地开发。
第三个问题是“ESLint 和 Prettier 会不会冲突，你怎么处理”。这个我真踩过坑，所以答得也很顺。ESLint 主要管代码质量（比如 no-unused-vars），Prettier 主要管代码格式（比如缩进和分号），两者确实会有冲突。解决方案是在 ESLint 配置里引入 eslint-config-prettier，把 ESLint 中和排版相关的规则关掉，再配合 eslint-plugin-prettier 让 ESLint 直接执行 Prettier 的格式检查，这样责任边界就清晰了。
注意：如果你也在简历里写“从零搭建脚手架”，务必把 proxy、alias、ESLint 这些关键配置的真实场景准备好。面试官不关心你的配置是否完美，而是关心你是否理解每个配置背后的设计动机。宁可讲清楚一个配置，也不要背出五个配置却说不清用处。
3. HTTP 八股文，不只是背概念
3.1 HTTP 与 HTTPS 的区别，怎么答才不白背
HTTP 和 HTTPS 的区别几乎是前端面试必考题，但大多数人只会背“HTTPS 比 HTTP 多了加密，更安全”。这种一句话答案只能保底，拿不到加分。面试官更想听到的是你对整个链路有完整理解。
我的回答思路分四层。第一层是传输层差异：HTTP 使用明文传输，HTTPS 在 TCP 和 HTTP 之间加了一层 TLS/SSL 加密协议，通过对称加密加密数据、非对称加密交换密钥，保证传输内容的机密性。第二层是端口和证书：HTTP 默认 80 端口，HTTPS 默认 443 端口，HTTPS 需要 CA 机构颁发的证书，用来验证服务器身份，防止中间人攻击。第三层是性能成本：HTTPS 增加了一次 TLS 握手，首次连接会比 HTTP 慢一些，但现代网络环境下这个差异已经很小，而且 HTTP/2 强制要求加密，所以现在新项目基本都直接上 HTTPS 了。第四层是应用场景：涉及登录、支付、个人信息等敏感数据的场景必须用 HTTPS，纯静态展示页面用 HTTP 也不是不行，但浏览器对不安全网页的警告标注会劝退大量用户。
面试时我还补充了一个很实际的知识点：HTTPS 握手过程中证书校验失败会出现什么情况。比如网站证书过期，或者域名和证书不匹配，浏览器会显示“您的连接不是私密连接”，用户可以选择忽略警告继续访问，但如果是在登录页出现这个提示，大概率是中间人攻击在等着收集你的账号密码。这个细节一出来，面试官普遍会点头，因为说明我不是只会背概念，而是真的理解 HTTPS 保护的是什么。
3.2 状态码、缓存机制与 TCP 握手
HTTP 状态码也是高频考点，但我发现很多同学只记得 200、404、500 这几个最常见的。面试官问“你遇到过哪些状态码，各表示什么”，其实是在考察你平时开发有没有留意接口状态。我整理了一个速查表，按分类记忆：2 开头是成功，200 表示请求成功，204 表示成功但没有返回内容，206 表示部分内容，常用于视频分段加载；3 开头是重定向，301 是永久重定向，302 是临时重定向，304 是协商缓存命中；4 开头是客户端错误，400 是请求参数有误，401 是未认证，403 是已认证但无权限，404 是资源不存在，429 是请求太频繁；5 开头是服务端错误，500 是服务器内部错误，502 是网关错误，503 是服务暂时不可用，504 是网关超时。
缓存机制这块，面试官最爱问的是强缓存和协商缓存的区别。强缓存是浏览器直接读本地缓存，不会发请求到服务器，响应头里 Expires 和 Cache-Control 控制，Cache-Control 的 max-age 单位是秒，优先级高于 Expires。协商缓存是浏览器带着缓存的标识发给服务器，服务器决定用缓存还是返回新资源，对应 Last-Modified 和 ETag 两个响应头，If-Modified-Since 和 If-None-Match 两个请求头。这里有个细节容易忽略：现在默认使用 ETag 优先策略，因为 Last-Modified 的精度只到秒级，如果同一秒内文件被修改两次，它会误判为未修改。
TCP 三次握手和四次挥手也是老八股了。三次握手的作用是确认双方收发能力都正常，第一次客户端发送 SYN，第二次服务端回复 SYN+ACK，第三次客户端发送 ACK。我之前一直有个误区：只知道三次握手，不知道为什么必须是三次而不是两次。后来想明白了，两次握手无法防止客户端历史连接请求错乱到达服务端。四次挥手则是因为 TCP 全双工的特性，需要四条报文才能让两个方向的数据都传输完毕，还有 TIME_WAIT 状态要等 2MSL，目的是确保最后一个 ACK 能到达对方。
4. XSS 漏洞专题：从原理到防御
4.1 三种 XSS 类型的区别与识别
XSS（跨站脚本攻击）是我觉得八股文里最值得深挖的一块，因为它是少数几个前端开发者必须亲自负责的安全防线。面试官问 XSS，本质上是在考察你是否具备安全开发意识。
XSS 分三类，存储型、反射型和 DOM 型，核心区别在于恶意脚本存在哪里、怎么执行。存储型是指攻击者把恶意脚本长期存储在服务器上，比如评论区、个人签名、订单备注等场景，其他用户访问页面时，脚本从服务器被加载并执行，危害最大，因为它影响所有访问该页面的人。反射型是恶意脚本藏在 URL 参数里，服务器把参数原样返回给页面执行，常见于搜索页面，用户点击攻击者精心构造的链接才会中招。DOM 型比较特殊，脚本根本不出现在服务端，而是完全在前端通过操作 DOM 的方式执行，比如 location.hash 或 window.name 中的内容被直接拼进 innerHTML。
我面试时举了一个实际的识别例子：一个搜索框，输入<script>alert(document.cookie)</script>，如果提交后页面直接弹窗，那大概率是反射型 XSS。如果这个脚本被存储下来，别人打开页面也弹窗，那就是存储型。如果弹窗由前端 JS 从 URL 的 hash 部分取出并拼接到 HTML，而服务端日志里完全没有这个 payload，那就是 DOM 型。这个“服务端日志中有没有 payload”的判断标准非常实用，面试官听到这里通常会追问一句“DOM 型为什么服务端看不到”，正好引出下一层答案：DOM 型 XSS 的所有操作都发生在前端，恶意输入不会经过服务端处理。
4.2 讲讲 payload 和攻击流程
面试官还问过一道题：解释一下 XSS payload 的含义。我当时从一条典型 payload 拆解起：<img src=x onerror=alert(document.cookie)>。img 标签是 HTML 里最常用的 XSS payload 载体，因为它的 src 属性可以指向一个不存在的地址，从而触发 onerror 事件，onerror 里可以执行任意 JavaScript。用 img 而不是 script 标签的原因很简单：很多过滤规则会直接删除 script 标签，但 img 标签太常见了，防御方容易放松警惕。
完整的 XSS 攻击流程我总结成四步。第一步是发现注入点，攻击者会在输入框、URL 参数、请求头等位置尝试插入特殊字符，观察页面是否原样输出。第二步是构造可用 payload，绕过前端过滤和服务端过滤，常用技巧包括大小写混写、事件属性替换、编码绕过。第三步是提取敏感数据，最常见的自动化代码是用 XMLHttpRequest 或 fetch 把 document.cookie 发送到攻击者的服务器。第四步是扩大战果，拿到 cookie 后攻击者可以尝试伪造身份登录，或者继续在页面中植入持久化脚本。
这里有个值得强调的细节：很多网站在登录时设置了 HttpOnly 标记的 Cookie，这意味着 document.cookie 根本拿不到这个值。所以现在 XSS 攻击的目标已经从偷 cookie 升级成劫持会话、篡改页面、键盘记录。在面试中主动提到 HttpOnly Cookie 和它的局限性，会显得你对安全的理解远超背答案的层面。
4.3 防御方案与面试应答策略
XSS 的防御要从前端、后端、机制三个层面一起做，单靠一个层面挡不住所有攻击。前端最基础的手段是输入验证和输出编码。输入验证只做白名单校验，比如电话号码只允许数字和短横线；输出编码是在渲染时把<、>、&、"、'转义成 HTML 实体，让浏览器把它当作文本而不是标签解析。在 React 中，默认的 JSX 渲染已经做了转义，所以直接用{}插入内容一般是安全的，真正危险的是dangerouslySetInnerHTML和拼接 innerHTML 的写法。
后端层面要做严格的输入过滤，同时设置正确的 HTTP 响应头。CSP（内容安全策略）是现在最推荐的一种纵深防御手段，它通过Content-Security-Policy响应头限制页面可以加载的资源来源，即使攻击者注入了脚本，浏览器也会因为 CSP 规则拒绝执行。比如设置default-src 'self'，页面就只能加载同源的脚本和样式，外部域名注入的脚本会被直接拦截。
面试应答策略上，我有一个建议：不要只答“如何防御”，要把攻击流程和防御手段对应起来讲。比如“存储型 XSS 利用的是后端不过滤输入、前端不转义输出两个漏洞，所以防御要从后端过滤、前端转义、CSP 兜底三个层次做”。这种回答展现的是结构化思维，面试官会认为你具备完整的安全认知体系。
实践建议：自己在本地搭一个 DVWA 靶场，把反射型、存储型、DOM 型三种 XSS 都实际打一遍，然后尝试修复。这个实操周期大概只需要几天，但效果比背十篇 XSS 博客都强。面到最后一家公司时，我发现自己已经能自然地讲出“如果我是攻击者，我会先看页面哪里用了 innerHTML”这种话，面试官当场眼睛都亮了。
5. 面试现场与复盘总结
5.1 面试中踩过的坑和答不好的题
不管准备多充分，面试现场总会有你想不到的坑。我第一家面试就翻车了：面试官问“Vite 的 HMR 原理是什么”，我只知道热更新是改代码后页面自动刷新，却说不清它是如何通过 WebSocket 把更新消息推给浏览器、浏览器又是如何用模块替换的方式保留页面状态的。这个问题暴露了我只停留在“会用”的层面，没有深入“原理”。回家之后我恶补了 HMR 的底层机制，再去面下一家时，这类问题就再也没难住过我。
另一个印象深刻的问题是“如果页面加载很慢，你会怎么排查”。我这道题答得很散，想到什么说什么，没有清晰的主线。后来复盘时整理了一套链路：先看 Network 面板，确认是否有很多大文件、资源有没有被缓存、接口是否慢；再看 Lighthouse，分析首屏渲染性能；然后用 Performance 面板定位 JS 执行和重排的瓶颈；最后检查服务端配置，看有没有开启 Gzip、图片有没有做压缩。面试里“能不能结构化表达”真的比“知道多少知识点”更重要，这个复盘让我彻底认识到了。
我自己的心态也经历了很大的变化。第一次面的时候，我全程紧张到声音发抖，一个问题答完就等着被赶出去。面到第三次的时候，我已经能跟面试官讨论某些方案在特定场景下的取舍了。我的一位老师说得很对：面试不只是公司挑你，也是你在挑公司，把面试当成一次技术交流，状态会自然很多。这个心态调整对我后来的表现帮助极大。
5.2 我的时间轴与暑期实习规划回顾
从开始投简历到拿到 offer，我一共经历了五周，投了 20 多家公司，收到 6 个面试邀约，面完 4 家，最后拿到 1 个 offer 和 1 个 waitlist。时间轴大概是这样的：第一周集中改简历，重点突出脚手架项目，用 STAR 法则把“需求背景、执行动作、项目结果”写清楚；第二到第三周边投边面，前两场面试主要用于练手，不抱期望，反而更放松，表现反而比预期好；第四周开始有面试官在反问环节问我的项目细节，说明我的技术储备已经能支撑深度交流；第五周拿到暑期实习 offer，薪资不高但方向很匹配，核心就是负责一个内部中台系统的前端开发。
复盘这段经历，我最想分享的一个经验是：准备面经要有优先级，围绕“项目深挖 + 高频八股 + 少量算法”这三块就够了，别想着覆盖所有知识点。八股文部分，我最开始试图面面俱到，结果效率很差，很多冷门知识点看了就忘。后来我做了减法，只聚焦每个主题里最高频的 5 个问题，把每个问题都吃透、能讲出原理、能举例说明。事实证明这个策略是对的，面试中被问到的绝大多数问题，都在我重点准备的范围内。
进入暑期实习之后，我的短期规划是先把组内的代码规范和执行流程吃透，不要急着提改进方案。毕竟学校里的项目和个人项目，跟真实生产环境还是有很大的区别。中期规划是继续深入 TypeScript 和 Node.js，争取在实习结束前能独立负责一个完整的业务模块。长期来看，等顺利转正之后，再考虑做一些工程化方向的基建工作。
最后再分享一个我踩过坑后总结的小技巧：准备面试答案的时候，不要写在文档里就完事，一定要自己说出来，最好能对着镜子或者录下来回放。很多知识点你觉得自己懂了，但一说出来就发现逻辑断点、表达啰嗦、术语混乱。反复说到自己都觉得流畅，面试时的表现才能稳定。这招我推荐给了好几个同学，亲测有效。
如果你也是大专在读、想做前端，正在为暑期实习焦虑，我想说一句：学历只是起点不是终点，技术面试中你能展示的深度和真诚，远比一纸文凭更有说服力。把这些基础八股文吃透，配上一个拿得出手的小项目，大胆去投就是了。
