企业官网建设流程全解析

面试这事，真的很看缘分，但也真的很看准备。我在写这篇文章的时候，特意回看了自己当初一年半经验时投 Shopee 那段时间的记录和聊天截图，一边看一边冒冷汗。不是因为表现多差，而是因为我发现自己对"面经"这两个字的理解，和真正拿到 Offer 之后的复盘结论，几乎完全不一样。市面上太多面经在告诉你"考了什么题、怎么答"，但很少有人在讲"为什么要这样答、答完之后面试官到底在评估什么、你简历上哪句话会被追着问十分钟"。

这篇内容不打算写成标准答案汇总，而是想把我这一年半前端经验去面 Shopee 的真实路径、踩过的坑、以及后来复盘时才想明白的细节，完整剥开给你看。无论你是刚满一年想试试水，还是两年左右准备冲一波外企，都值得花十分钟把这篇文章看完，尤其是里面关于项目深挖和算法轮的部分，可能和你预想的不太一样。

1. 为什么在一年半经验的时候动了跳槽念头

很多人会觉得，一年半这个时间点很尴尬。你说自己是应届生吧，已经不是了；说自己是资深前端吧，又明显不够格。但恰恰是这个阶段，是跳槽性价比最高的时候之一。因为你有完整的项目经验，能独立负责模块，又还没有被某个公司的固定技术栈和业务逻辑完全同质化，面试官对你的预期，其实没有你想象的那么高。

1.1 一年半的经验到底处在什么阶段

在我自己看来，一年半的前端，核心任务不是证明自己什么都会，而是证明三件事。

第一，你能不能在没人盯着的情况下，把一个需求从设计稿变成线上功能。这包括技术方案选型、组件拆分、接口联调、自测上线，以及处理线上问题。很多一年左右的同学，在这个环节是缺位的，因为公司里往往有更资深的人兜底，需求拆解和排期都不用自己操心。但面试官不知道你有没有人兜底，他只能通过你的描述来判断。

第二，你有没有形成自己的技术判断力。举个例子，同样是做一个表格页面，你会不会在技术方案里写明为什么用虚拟滚动而不用分页？你会不会主动提出"这里用 useMemo 其实没有意义，因为数据来源是全局状态，每次都会变"？这种细节是区分一年经验和三年经验的关键分水岭，也是我在面试前集中补课的地方。

第三，你能不能吃亏。这话听起来有点虚，但放到面试场景里就非常具体：面试官抛出一个你没做过的场景题，你的第一反应是"这个我没做过，不知道"，还是"我没直接做过，但基于我对 XX 的理解，我会从这几个维度去拆"？后者就是吃亏之后练出来的表达能力。

1.2 Shopee 为什么值得在这个阶段投

我在决定投递之前，其实纠结了很久。一方面听说 Shopee 的面试流程比较规范，技术面至少两轮到三轮，每一轮都会有明确的考察侧重点；另一方面也听一些朋友说，外企对英语有一定要求，对算法和基础的要求也不低。作为一个平时不刷题的选手，我心里是有点打鼓的。

但我后来想明白了一个问题：你不可能等自己完全准备好了再去面试。所谓"准备好了"，在面试这个场景里是永远不会到来的。更务实的做法是：定一个周期，比如三周，用三周时间集中补齐最核心的知识盲区，然后直接投，用真实面试来检验自己的水平，再根据反馈做第二轮补充。我就是用这种方式推进的，前两轮面试确实暴露了不少问题，但也因此拿到了非常具体的复习方向，比自己闷头刷题高效得多。

如果你也是一年半左右的前端，我建议你认真评估一下自己目前负责的业务复杂度。如果每天的工作内容已经很难让你在技术上有新的积累，那现在就是你启动面试计划的最佳时机。跳槽不是否定当前的公司，而是主动给自己换一个成长速率更高的环境。

2. 简历筛选阶段：把一年半的资历写出辨识度

简历这件事，我吃过很大的亏。第一次投递的时候，我几乎是照着网上的模板把自己的经历填进去的。比如"负责 XX 后台管理系统开发"、"使用 Vue 3 和 Element Plus 实现页面交互"、"对接后端接口，完成数据展示"。听起来好像很完整，但实际上每一句话都像白说。HR 每天看几百份简历，这一版描述和隔壁应届生的描述几乎没有区别，凭什么约你面试？

2.1 我踩过的最大的简历坑

最大的坑，是把项目描述写成了工作日志。工作日志记录的是"我做了哪些事"，而面试官想看到的是"我解决了什么问题、带来了什么结果、体现了我什么能力"。这两个视角的差别非常大。

举一个具体的例子。我做过一个内部运营平台的数据报表模块。刚开始简历上写的是：

负责数据报表模块的开发，使用 ECharts 实现多种图表展示，支持按日期、按渠道筛选，提升运营人员的数据查看效率。

这版描述的问题在于：它只是罗列了功能，没有解释任何决策。为什么用 ECharts 不用其他图表库？图表数据量大了之后卡顿怎么解决？筛选条件联动时有没有遇到性能问题？运营同学的真实使用场景是什么样的？这些内容一概没有，面试官想追问题都无从追起，他只能按自己的经验问一些通用问题，然后把你当成普通开发对待。

后来我重写这版的时候，改成了：

主导运营后台数据报表模块重构，对接日均百万级埋点数据。针对图表渲染卡顿问题，调研并落地 ECharts 大数据模式 + 按需更新方案，将首屏渲染时间从 3.8s 降至 1.2s。负责筛选条件组件化设计，抽象出通用 QueryBar 组件，支撑三个业务线复用。

前后对比你会发现，后者天然地埋了三个可以被追问的点：百万级数据是怎么处理的？3.8s 是怎么测出来的？QueryBar 抽象的时候是怎么设计 API 的？这三个点每一个都能引出一次有深度的对话，而对话的主动权在你手里，因为你才是做过这件事的人。

2.2 项目描述的具体写法

我在重写简历的时候，给自己定了一个规则：每个项目只保留两到三个最有辨识度的点，其余全部砍掉。不要贪多，不要指望面试官通过你的简历读完整个项目，他能记住的只有那么两三个亮点。

具体写法上，我总结了三个要素，按顺序排列：

1. 背景和问题。一句话说清楚这个项目为什么要做，或者你为什么要改它。比如"原有报表页加载超过 5 秒，运营反馈无法接受"。
2. 你的动作和决策。你做了什么，你的方案是什么，为什么选这个方案而不是另一个。这是整个描述里最重要的一块，能体现你的技术判断力。
3. 结果和量化指标。性能提升了多少？业务方效率提升了多少？复用了多少条业务线？最好有数字，没有数字就用对比，比如"从无法使用到可流畅查看"。

我当时整理完这三个要素以后，删掉了简历里一半的废话，整体篇幅也短了，但信息密度反而高了。后来约面率明显提升，应该是和这个有直接关系的。

2.3 技能清单应该怎么列

如果你经验不到三年，技能清单这块建议不要写"熟练使用 XXX"这种话。熟练这个词，在面试官眼里等于没写。更合适的写法是标出你实际使用过的场景和深度，比如"Vue 3（组合式 API 开发中后台项目，封装过表格/表单/弹窗等 10+ 通用组件）"、"TypeScript（封装过带泛型的请求层，处理过类型收敛和接口对齐问题）"。

还有一点心得是：不会的东西不要硬写。简历上写的每一项，都有可能被追问。与其赌面试官不问，不如只列自己真正能把前因后果讲清楚的内容。我在第一版简历里写过"了解 Webpack 原理"，结果面试官问我 loader 和 plugin 的区别、写过自定义 plugin 没有，我回答得支支吾吾，那一轮印象分就掉了不少。

如果你准备时间充裕，这一步值得静下心来慢慢改。我的建议是简历改完之后，自己先对着每一行问三个问题：这段描述背后的技术难点是什么？当时的可选方案有哪些？为什么做了这个选择？如果三个问题里任何一个答不上来，就说明这个描述要么不该写，要么你还没理解透。

3. 一面：基础题怎么答出"非应届感"

Shopee 的一面通常以基础为主，考察范围集中在 JavaScript、浏览器、网络、框架原理这几个方向。说实话，这些内容的八股文版本网上到处都是，但很多人背得很熟，一问到具体场景就露馅。原因很简单：死记硬背的答案没有上下文。面试官想看到的，不是你一字不差地背出"事件循环分为宏任务和微任务"，而是你能不能把这个概念放到一个真实问题里讲清楚。

3.1 事件循环、闭包、this 这类题的高分回答逻辑

先说我真实遇到的一道题，可能很多人也见过："setTimeout 的延时是准确的么？为什么？如果我想精确测量一段代码的执行时间，应该怎么做？"

这道题表面在考 setTimeout，实际上考的是事件循环、宏任务微任务、性能计时这三个层次。低分回答是："setTimeout 不准确，因为它是宏任务，会被前面的任务阻塞，可以用 performance.now() 测时间。"这个回答不能算错，但只停留在第一层。

高分逻辑是这样展开的：

1. 先给结论，setTimeout 的延时不是精确的，最小延时受浏览器实现影响，Chrome 里嵌套调用还会有限制。
2. 解释为什么不准。JS 是单线程的，setTimeout 只是把回调放进宏任务队列，要等当前执行栈清空、微任务队列清空之后才轮到它。所以实际执行时间 = 设定延时 + 当前任务队列的剩余执行时间。
3. 如果真到面试官问"怎么测代码执行时间"，一定要提到 performance.now() 的高精度特性，以及为什么不用 Date.now()——因为 Date.now() 受系统时间调整影响，而 performance.now() 是单调递增的，不会被时钟回拨干扰。
4. 更进阶的一点是，如果你在 React 场景里，还要能扯到 requestIdleCallback 或者调度，比如 React 的 Scheduler 底层就是基于 MessageChannel 来模拟 requestIdleCallback 的，这能体现你对框架原理的理解不是停留在 API 层。

同样是背过八股文，这个回答思路明显更能体现"非应届感"。我准备的技巧是：每当复习一个概念，都强迫自己回答三个问题——它解决什么问题？它的机制是什么？如果让我设计一个方案替代它，我会怎么做？这比单纯刷题有效得多。

3.2 React 原理和 Hooks 陷阱

Shopee 的岗位如果用的是 React 技术栈，一面基本都会追 React。我当时准备了几个高频问题：Hooks 为什么不能写在条件语句里、useEffect 的依赖数组到底怎么比较、useCallback 和 useMemo 的适用场景。

这里面最容易答偏的是 useEffect。很多人只会说"依赖数组里的值变了就会重新执行"，但面试官追问一句"如果我传了一个空数组，是不是只在挂载时执行一次？"很多人就开始犹豫了。正确答案是：不一定。关键在于你的 effect 里有没有访问外部变量，以及这些变量是不是 React 每次 render 都会重新创建的。如果依赖是空数组，但 effect 里用了一个在组件内定义的函数，那这个函数每次 render 都是新引用，但由于依赖数组是空的，React 不会在更新时重新执行 effect——这看起来是安全的，实际上如果你用了函数内的状态且没有正确注册依赖，就相当于闭包捕获了旧值，这就是经典的 stale closure 问题。

如果你在项目里用过 React 函数的闭包导致过 bug，比如定时器里拿不到最新 props，这块一定要准备好。最简单也最不易出错的解法，是把依赖项写全，或者用 ref 去保存最新的值。面试里能主动讲出"我在项目里遇到过这种问题，最终的解法是 xxx"，比单纯背概念要加分非常多。

3.3 浏览器和网络：从背概念到讲场景

这一部分，我强烈建议你不要只看协议原理，一定要结合一个真实页面从输入 URL 到展示的完整链路去理解。缓存、DNS、TCP、渲染、JS 执行、重排重绘，这些本来就不是孤立的知识点，它们共享一条完整的请求生命周期。

比如常见的面试题"浏览器缓存机制"，低分回答是背一遍强缓存和协商缓存的状态码。我后来学到的加分答法是：先说浏览器在请求资源时，会先查强缓存，也就是 Cache-Control 和 Expires，命中的话直接用本地副本，发 200 from cache；没命中才发请求，服务端通过 ETag 或 Last-Modified 返回 304，让浏览器继续用旧资源。然后补一句"实际开发里，我一般会结合打包工具给静态资源加 hash，这样文件名变了，缓存自然会失效，同时保证没有变化的资源可以继续命中强缓存"。这样既展示了原理，又展示了工程实践。

如果你能再进一步，提到 HTTP/2 多路复用、队头阻塞问题，以及为什么还需要 HTTP/3 的 QUIC 协议来解决传输层的队头阻塞，面试官对你的印象会再上一个台阶。虽然这些问题不一定会被问到，但它们之间是有逻辑链条的，理解了这条链路，哪怕换一种问法你也能接住。

4. 二面：项目深挖和技术方案设计的真正分水岭

一面是考你会不会，二面是考你有多会。这个问题是我面试完最大的感受。

Shopee 的二面通常不再围绕通用八股文，而是会花大量时间问你自己做过的项目。你简历上写的每一个亮点，都可能被拿来精细解剖。面试官会问你：这个方案是你自己决定的还是别人帮你定的？当时还有哪些备选方案？你了解它们各自的优缺点吗？上线以后有没有出过问题？如果让你重做一次，你会有什么改动？

这些问题没有标准答案，但非常考验你有没有真正思考过自己的工程实践。

4.1 项目复盘的正确打开方式

很多人在准备项目深挖的时候，会犯一个错误：把项目准备成一份"做成 PPT 的成功案例"，只讲做了什么、结果多好，完全不讲踩过的坑、走过的弯路。但实际上，面试官愿意听到的恰恰是失败和反思，因为那更能体现一个人的思考深度。

我二面讲的一个项目是"前端性能优化专项"，一开始我是打算只讲成功部分的：发现页面慢、做了性能分析、改进了哪些点、LCP 从 4.5s 降到 1.8s。但后来我复盘的时候发现，真正让我对性能优化有深刻理解的不是那些成功的点，而是整个过程中我曾经做过一个无效优化：把图片全部转成 WebP，结果发现数据上几乎没变化，后来查了才发现，线上大部分图片已经通过 CDN 的压缩参数处理过了，我转换的图片总量只占页面的很小一部分。

这个"失败"故事反而比我罗列一堆优化手段更能展示我的判断力，因为它说明我在优化的时候不是无脑堆方案，而是会验证方案的有效性，并且在无效之后能重新定位问题。面试官对这段追问了很多，比如"那你后来怎么定位到真正的瓶颈？""用的是什么工具？Performance 面板里的什么数据给了你线索？"这些问题我可以答得非常细节，因为它是真实经历，不是背出来的。

4.2 场景设计题：如何拆解一个前端需求

二面还会出现一类题，就是给你一个业务场景，让你现场做技术方案。我遇到的一个问题是："如果我们要做一个支持多人实时协作的文档编辑器，你会怎么设计前端架构？"

这类问题听起来很大，面试官并不期待你完整地把整个系统设计出来，他更在意的是：你在拿到一个模糊需求的时候，有没有一套自己的拆解方法。

我当时没有直接说用什么技术，而是先问了一连串澄清问题：并发冲突怎么解决？是服务端权威还是客户端乐观更新？要不要支持离线编辑？协作人数规模大概是多少？历史版本保留多久？这些问题本身就向面试官传递了一个信号：我不是一个只会写代码的人，我会先定义问题，再想解决方案。

澄清完之后，我再给出一个分层设计。前端层面，要把编辑器核心（文档模型、操作转换）、UI 层（工具栏、状态同步）、网络层（WebSocket 消息收发、重连恢复）分开；操作冲突解决，最简单的是服务端用 CRDT 或者 OT 算法，前端只需要把用户的每个操作转换成原子化的指令发给服务端；状态管理上，本地状态和远端状态的同步需要有一个明确的中间层，避免直接把 WebSocket 消息散落到各个组件里。

如果对 CRDT 和 OT 的区别不了解，至少也应该能讲清楚：CRDT 是无中心、合并友好的方案，Google Docs 用的就是类 OT 方案，需要中心服务端做转换。能讲到这一层，面试官已经会认为你是认真思考过的。

4.3 遇到"我不会"的正确表达方式

这一点是我最想说、也最想让所有准备面试的人记住的。

面试中一定会遇到你不会的题，区别只在于你用什么样的方式处理。最常见的错误是沉默，然后挤出一句"这个我不会"。这会把对话瞬间冰住，面试官想帮你都无从帮起。另一种错误是强行编造，被追问两轮之后就露馅，反而让人质疑你的诚信。

正确的处理方式是把你已知的部分拆出来，然后表达你未知的部分，并给出你的猜测方向。比如面试官问你"有没有用过 WebAssembly？"你可以说："我没有在实际项目里用过 WebAssembly，但我知道它适合计算密集型的场景，比如音视频处理、图像处理。如果要我现在设计一个方案，我可能会考虑把复杂的编解码逻辑用 Rust 或 C++ 打包成 wasm，然后通过 JS 调用。具体到集成细节——比如内存管理和与 JS 的通信开销——我还没有实践经验，需要去查一下文档。"这段话既表明你没有经验，也证明你知道它该用在什么地方、有哪些知识点需要补足，而不是一个完全空白的大脑。

这个方法在我身上屡试不爽，我甚至有一次面试官听完之后主动说："你没做过也很正常，这个领域用的人确实少。"然后他就开始给我讲他们团队是怎么做的了——面试变成了技术交流。

5. 算法轮和手写题：一年半前端最容易被击穿的地方

我承认，算法是我整个面试过程中准备得最痛苦、也是最花时间的部分。因为平时工作根本用不到那些复杂的算法，大学里学的那点东西也早还给老师了。但实际上，Shopee 的算法考察并没有想象中那么可怕，难度基本保持在 LeetCode 中等题以下，而且很多题目都是可以通过针对性准备拿到分数的。

5.1 算法到底要刷到什么程度

作为一个不刷题的人，我给自己定的目标是：先把最常见的题型刷熟，而不是追求刷题数量。我当时集中刷了大概 100 道题，分成几个固定的模块：数组和字符串、哈希表、链表、二叉树、动态规划入门、栈和队列、双指针、排序和二分。每类题刷够 10 道左右，基本就能开始看到一些规律了。

我的感觉是，面试里的算法题和刷题网站不完全一样。面试官更看重你的思考过程，他会观察你拿到题之后是直接开始写，还是先和面试官交流清楚题目里的细节。我个人的体会是，哪怕会让你显得慢一点，也一定要先口头分析一遍：题目的输入规模有多大？边界条件是什么？有没有可能有负数？能不能改变原数组？这些问题问出来，既帮你避免编码中大量出错，也让面试官看到你是一个有工程思维的人。

我实际遇到过的题目里，印象比较深的一道是给一个字符串，求最长无重复字符子串的长度。这道题在 LeetCode 上是第三题，非常经典。准备过的同学可能直接就会写滑动窗口，但我当时先口头分析了窗口的扩展和收缩条件，确认了重复字符处理的方式，再写代码，整个流程反而非常顺畅。如果你的目标是外企，刷题的时候建议一定要养成英文读题的习惯，很多题目翻译成中文之后意思会有微妙变化，直接读英文更准确。

5.2 高频考点和手写题清单

除了纯粹的算法题，大厂面试还非常喜欢手写一些 JS 题，这类题更像是对语言基础和工程能力的综合考察。我把当时重点准备的一些题列在这里：

• 手写 Promise.all、Promise.race，并解释 Promise 的 microtask 机制
• 手写防抖和节流，并说清楚它们的核心区别和使用场景
• 手写深拷贝，处理循环引用和特殊类型（Date、RegExp 等）
• 手写 instanceof 原理，并说明它和 typeof 的区别
• 实现一个简单的发布订阅 EventEmitter
• 实现一个 LRU 缓存
• 用二分查找实现一个版本号排序
• 手写数组 flat 以及去重（注意 NaN 和对象）
• 实现虚拟列表的基本逻辑，数据量大时只渲染可视区域

我的建议是不要只背代码，一定要会讲思路。比如手写防抖，你要能说清楚"最后一次触发之后延迟执行"和"第一次触发立即执行"的两种模式，并且能根据业务场景讲出你实际用过哪一种。我当时还主动提到，在一些场景里防抖会导致操作无响应感太重，所以会改用节流来保证一定频率的执行，这种"实际权衡"比单纯默写代码更能加分。

5.3 在线 coding 时的心态和节奏控制

在线 coding 最怕的不是写不出，而是写的过程中内心慌乱，越急越出 bug，然后开始怀疑自己。我之前在别的公司面试时就经历过一次，写一个很简单的快排，因为紧张把 while 条件写错了，调了五分钟才看出来，整场面试的节奏都被打乱了。

后来我总结了一套自己的节奏控制方法，分享给你。拿到题之后强制自己先看两分钟题，不要急着写；想清楚边界条件再动手；开始写的时候，注释先行，把思路用注释写出来，再填充代码；写完之后不要马上说写完了，主动检查一遍边界情况。这一套流程下来，哪怕中间有小 bug，面试官也会觉得你的思路是清晰的。

还有一个小技巧是，在写代码的时候保持和面试官的交流。不用每行代码都解释，但在关键节点说一句"这里我用双指针，是为了把时间复杂度从 O(n²) 降到 O(n)"，会让面试官知道你不是在背题，而是真的在思考。我曾经在一次手写题中，写完之后主动提了一句"这里还有一个小边界情况，当指针相遇的时候要再加一个判断"，面试官笑着说 fine，那场面试的氛围明显轻松了很多。

6. 反问环节和 HR 面：容易被忽略的隐性加分项

很多人觉得面试到最后一问"你有什么想问我"的时候，面试已经基本结束了，随便问一两个问题客套一下就行。但我的经验是，反问环节真的是可以影响面试结果的一个独立环节。它不像技术上那样有硬性的评分标准，但它能影响面试官在写评价时那种微妙的、对你个人的印象。

6.1 技术面反问什么才显专业

我当时整理过一套反问问题，按效果从好到差排下来大概是这样：

• "如果我有幸入职，前三个月团队对我最大的期望是什么？"——这个问题直接说明你已经在设想入职后的工作计划，显得非常真诚。
• "团队现在的技术栈里，你觉得最大的历史包袱是什么？"——这个问题能问出很多真实信息，也会让面试官觉得你对技术有好奇心。
• "前端团队在公司的组织架构里和产品、后端是怎么协作的？"——适合想了解工作方式的同学。
• "你们有没有什么正在调研或者试点的新技术方向？"——适合展示你在技术视野上的兴趣。

尽量避免只问一些"公司福利怎么样"、"加班多不多"之类的问题，不是说不能问，而是这些问题最好留到 HR 面，不要浪费技术面宝贵的交流机会。

如果面试官在技术面里给你讲过某个复杂的系统设计，或者某个技术方案选型，你在反问环节可以顺着他的思路再问一句"你刚才提到的那套方案，上线之后有没有踩过什么坑？"这会是一个非常漂亮的收尾，因为它证明了你刚才真的有在认真听，并且对技术本身感兴趣，而不是把面试当成一场拷问。

6.2 HR 面谈薪和离职原因的话术

HR 面通常会问离职原因和期望薪资，这两个问题没聊好，前面技术面积累的优势可能会被抵消掉一部分。

离职原因的核心原则是：不吐槽前公司、不抱怨前领导，把所有原因都归因到"个人成长诉求"上。哪怕你真实原因就是工资太低、感觉没前途，也要包装成"我希望能在业务复杂度更高、技术挑战更大的环境里继续成长"。这句话听起来很官方，但它安全、不出错，HR 也知道大多数人的真实原因是什么，ta 要的只是你处理敏感话题时能不能保持体面。

谈薪的时候，我的体会是不要直接报一个具体数字，而是给一个有理有据的范围。比如："我目前的总包是 xx，考虑到 Shopee 的职级体系和我对标的能力水平，我希望整体涨幅能在 30% 左右。"如果你有多个 Offer 在谈，也可以含蓄地提一句"我目前正在流程中的其他机会给的预期也在这个范围"，这会让 HR 更认真对待你的数字。

7. 复盘：我踩过的坑、挂过的地方和最终建议

文章写到后半段，我想把最真实的那部分经历放出来。不是因为我面试全过了才有资格说这些话，恰恰相反，我在整个面试周期里也挂过不少，包括一些我自认为准备得很充分的环节。

7.1 挂掉的那场面试，问题出在哪

我印象最深刻的一次，是在二面项目深挖环节被问到一个我完全没有准备好的角度。面试官问我："你项目里用了一个自定义的请求 hook，它内部是怎么处理取消请求的？如果用户快速切换路由，你怎么保证不会把上一个页面的响应 setState 到已经卸载的组件上？"

这个问题其实不算刁钻，正常用 AbortController 或者 axios 的 cancel token 就能处理。但因为我简历里只写了"封装了 useRequest 请求 hook"，没有深入准备这个 hook 的内部细节，所以当时只是简单说"我用了 mounted 标志位来避免已卸载组件的 setState"，面试官追问"那如果请求已经发出去了，服务端还在处理，你怎么取消它？"我就卡住了。

复盘下来，问题不在于我不会 AbortController，而在于：我简历上放了一个我没有真正从底层思考过的技术点。如果我在写简历的时候，先把自己封装过的每个工具函数、每个组件都重新审视一遍，问问自己"最底层它是怎么工作的"，这场面试就不会挂。这也是我个人最想提醒你的一点：不要因为某个项目是你做的，就觉得你天然能讲清楚它。你能不能讲清楚，和你做的时候有没有深入思考过，是完全两回事。

7.2 我对一年半经验前端的一些实用建议

如果让我重新走一遍这段路，我会给自己三条建议。

第一，准备时间最好拉长到三周以上，不要压缩到一周。因为基础知识、算法手感、项目深挖这三个模块，需要不同的复习节奏。基础知识和项目可以用碎片时间反复过，算法需要连续的大块时间刷题，一周的话很难平衡。

第二，找一个朋友或者同事，做两到三场模拟面试。我在真正面试前做了一场模拟，朋友模拟面试官，把我简历上的项目逐条追问了一遍。那场模拟让我发现自己讲故事的能力很差：讲到一半就开始细节发散，完全没有主次。后来我调整了话术，刻意训练自己在每个项目上用三分钟讲完"背景——难点——方案——收益"这个框架，真实面试时发挥稳定了很多。模拟面试这件事，真的不是浪费时间。

第三，把心态从"通过面试"调整为"技术交流"。我在二面的时候，因为抱着"这是一次交流"的心态，整个人松弛了很多，反而答出了不少自己都没预料到的亮点。如果你只是想着"答对"每一道题，脑子里就全是"标准答案"，稍微遇到一个不一样的问题就开始慌。但如果你想着"分享我自己做过的项目，聊聊我对某个技术的理解"，你的表达会自然得多，而且对方听着也会舒服得多。

7.3 这个内容后续还能怎么用

如果你正处在准备投递或者已经进入流程的阶段，这篇文章里的很多东西可以直接复用。比如简历那段的写法，你可以直接拿自己的项目套一下看看；针对一面基础题的回答逻辑，你可以挑几个高频知识点，用"它解决什么问题、它的机制、我的工程实践"这个框架重新组织一遍；项目深挖的部分，至少要想清楚我提到的那些问题——方案是为什么做的、有没有备选方案、上线之后有没有出过问题、如果重做一次会怎么改。

另外，像 Shopee 这样以英文沟通和外企文化为特点的公司，如果你英语口语还行，面试中尽量用中英文混合的方式表达专业术语，比如直接说"component"、"hydration"、"race condition"，会比刻意全部中文翻译更自然，也会让对方觉得你在国际化环境里能顺利沟通。如果你的英语面试是全英文的，至少把简历上的项目介绍准备一个英文版本，特别是项目描述里的那个"背景——难点——方案——收益"框架，提前用英文讲顺一两遍，会非常有帮助。

最后，真心建议每一位准备跳槽的前端同学，把面试当作一个周期性的事情来对待，而不是一次性的冲刺。你不需要等最好的时机，也不需要等自己变成"完全体"再行动。一年半也好，三年也好，只要你手上有一个值得讲的项目、有一颗愿意复盘的心、加上一套有节奏的复习计划，就已经足够开始了。