一. 问题

1. 问题：你的简历好像没更新，想了解你刚刚提到的在 实习 主要做了哪些事情。
   追问/关注点： 面试官想确认你最近实习经历的真实工作内容、个人贡献和技术产出。
   回答情况： 你回答了上个月在内部做 OA 老系统重构，因为原系统比较古老，导师希望你尝试重构。你使用类似 Vite 的构建工具替代旧工具，原本构建或启动需要 40 多秒，重构后大概不到 10 秒，并且不再依赖已停止维护的第三方工具，可以本地开发。你还提到参与了 YY 的一些中后台项目。
   评价： 有具体项目背景和性能提升数据，是有效回答。但表达比较散，还可以补充你负责哪些模块、遇到什么难点、如何落地、最终收益是什么。

2. 问题：浏览器里输入一个网址，比如头条.com，或者发起一个 API 请求，到前端代码拿到接口响应，中间发生了哪些事情？
   追问/关注点： 考察浏览器输入 URL 到页面/接口响应的完整网络链路。
   回答情况： 你提到浏览器会补全协议，检查本地缓存和 DNS 缓存，如果没有则进行 DNS 解析，拿到远程服务器 IPv4 地址，再向后端发起请求。你还提到可能涉及跨域问题。
   评价： 回答覆盖了 DNS 和请求发起的部分流程，但链路不完整。可以按顺序补充：URL 解析、缓存策略、DNS 查询、TCP 三次握手、TLS 握手、HTTP 请求、服务端处理、HTTP 响应、浏览器解析响应、前端代码消费数据、跨域/CORS、缓存命中等。

3. 问题：拿到 IPv4 地址后，是直接就能和服务端连接，还是还有什么过程？
   追问/关注点： 面试官在引导你补充 TCP 连接过程。
   回答情况： 你一开始说这点有点忘记，随后补充需要 TCP 握手等处理，然后才能和后端建立连接。
   评价： 方向对，但不够自信，也没有展开。更好的回答应说明：客户端拿到 IP 后，还要结合端口建立 TCP 连接；HTTP/1.1、HTTP/2 通常依赖 TCP；HTTPS 场景还要在 TCP 之后进行 TLS 握手。

4. 问题：如果追求安全通信，通常会选择什么协议？
   追问/关注点： 考察 HTTPS 基础。
   回答情况： 你回答选择 HTTPS 这种加密协议。
   评价： 回答正确，但非常简短。可以补一句 HTTPS = HTTP + TLS，用于身份认证、加密传输和完整性保护。

5. 问题：HTTPS 的加密过程大概是什么样的，或者安全通信过程是什么？
   追问/关注点： 考察 TLS 握手、证书、密钥协商等底层原理。
   回答情况： 你表示自己忘记了，准备比较仓促，没有展开。
   评价： 这是一个明显失分点。建议补充标准回答：客户端发起 ClientHello，协商 TLS 版本和加密套件；服务端返回证书和 ServerHello；客户端校验证书合法性；双方通过 ECDHE/RSA 等方式协商会话密钥；之后使用对称加密传输 HTTP 数据，并用 MAC/AEAD 保证完整性。

6. 问题：你提到 token 刷新，具体实现方案大概是什么样？
   追问/关注点： 面试官想了解你的登录态、鉴权和无感刷新实现。
   回答情况： 你回答使用双 token 机制，一个是 access token，生命周期约 15 分钟；另一个是 refresh token，生命周期约 7 天。请求后端接口时携带 access token，过期后调用刷新接口，用 refresh token 换取新的 token，然后更新前端存储，用户不需要重新登录。你还提到把过期期间失败的请求收集到队列，刷新成功后重新发起。
   评价： 这是回答较好的部分，有业务场景、有机制、有用户体验收益。可以再补充 token 存储位置、刷新失败处理、退出登录、refresh token 过期处理、安全风险和请求重放机制。

7. 问题：页面同时发起 5 个 API 请求，access token 刚好过期，怎么处理并发刷新，避免额外请求太多刷新接口，同时保证 5 个 API 都经过鉴权？
   追问/关注点： 考察并发请求下的 token refresh 竞态问题。
   回答情况： 你表示并发情况下只让第一个请求去刷新 token，拿到新 token 后保存，后续请求复用刷新结果，而不是每个请求都重新刷新一次，避免覆盖问题。
   评价： 思路正确。可以进一步明确实现方式：维护 isRefreshing 状态和 refreshPromise，后续 401 请求挂到等待队列；刷新成功后统一重放原请求；刷新失败则清空队列并跳转登录。

8. 问题：具体怎么做到并发场景下只刷新一次？
   追问/关注点： 面试官继续追问实现细节。
   回答情况： 你回答在第一次出现 401 时进入刷新流程，并给刷新流程加锁。第一个请求去后端刷新 token，后续请求看到锁后不再重复请求刷新接口，而是等待或复用已经刷新得到的 access token 和 refresh token。
   评价： 核心思路对，但“锁”的生命周期、等待队列、失败重试、并发请求如何恢复没有讲透。面试中可以用 axios 拦截器举例，说明请求拦截、响应拦截、队列和 Promise 的关系。

9. 问题：你有做性能上报吗？FP、FCP、LCP、INP 这些指标分别是什么意思？
   追问/关注点： 考察 Web Vitals 和性能指标理解。
   回答情况： 你大致说明 FP 是首次绘制，FCP 是首次内容绘制，LCP 是最大内容绘制，INP 是用户交互到响应之间的时间。
   评价： 方向正确

10. 问题：LCP 一般怎么采集到？
    追问/关注点： 面试官想知道你是否理解指标采集原理，而不是只会用库。
    回答情况： 你说项目中主要用了第三方库，调用它的 API 计算得到，具体操作没有深入探究。
    评价： 回答较弱。建议补充：可以通过 PerformanceObserver 监听 largest-contentful-paint 条目，也可以用 web-vitals 库上报；需要注意页面隐藏、用户交互后停止采集、图片/文本块作为候选元素等。

11. 问题：首页 LCP 的 75 分位是 4.2 秒，但准出标准是 2.5 秒，如果让你排查，会怎么排查？可能原因有哪些？
    追问/关注点： 考察性能问题分析方法。
    回答情况： 你首先想到图片问题，尤其是首页大图未压缩、体积过大导致加载慢；你结合自己项目经验提到曾经遇到 4MB 图片影响 LCP，通过压缩图片改善。你还提到榜单或大内容区块可用虚拟列表优化，以及做并发处理。
    评价： 有项目经验支撑，但排查路径不够完整。更好的回答可以按“数据定位 -> 资源分析 -> 渲染分析 -> 服务端分析 -> 优化验证”展开，例如看 Lighthouse/WebPageTest/Performance 面板、确认 LCP 元素、检查图片格式和尺寸、preload 优先级、CSS/JS 阻塞、接口耗时、SSR/缓存/CDN 等。

12. 问题：75 分位、99 分位、100 分位的区别是什么？对性能优化分析有什么不同？
    追问/关注点： 考察性能数据统计视角。
    回答情况： 你明确表示没有了解过分位值，并请面试官解释。
    评价： 此题未答上。建议掌握：P75 代表大多数用户体验，常用于 Core Web Vitals 标准；P99/P100 更关注长尾用户和极端慢请求，通常要按网络、设备、地区、浏览器、页面版本、资源失败等维度拆分定位。

13. 问题：FP、FCP、INP 等指标一般有哪些优化手法？
    追问/关注点： 考察你能否针对不同性能指标提出优化方案。
    回答情况： 你回答了 SSR、减少 HTTP 请求、接口聚合、前端 Promise 并发请求、preconnect、DNS prefetch、虚拟列表、Nginx 静态资源缓存、图片压缩等。还提到这些优化在训练营项目中用过。
    评价： 覆盖面较广，是一个相对不错的回答。但需要把优化手法和指标对应起来：FCP/FP 关注首屏 HTML/CSS/字体/关键资源；LCP 关注主体资源加载和渲染；INP 关注主线程阻塞、长任务拆分、事件处理耗时、渲染更新成本。

14. 问题：SSR 相比 CSR 优化了哪些步骤？
    追问/关注点： 面试官想确认你是否真的理解 SSR。
    回答情况： 你回答 SSR 在服务端先请求数据并生成 HTML，浏览器拿到后可以更快看到页面，后续再进行水合和 JS 注入。相比 CSR，省去了浏览器拿到空壳后再请求数据、再渲染页面的等待。
    评价： 回答方向正确。可补充：SSR 改善首屏和 SEO，但也带来服务端压力、水合成本、缓存策略复杂度；Next.js 还可结合 SSG、ISR、Server Components、数据缓存等。

15. 问题：你后端主要做哪一块？
    追问/关注点： 面试官想判断你的全栈深度。
    回答情况： 你回答后端主要是 Node.js，Next.js 上层框架也有所掌握。
    评价： 回答比较简单。可以补充你在后端负责的接口、鉴权、SSE、数据库、部署、日志或异常处理。

16. 问题：AI 对话项目中，用户前端发起一次 AI 对话，后端通过 SSE 把 token 一段一段推给前端，前后端流程是什么？
    追问/关注点： 考察 SSE、流式输出和 AI 项目的实际实现。
    回答情况： 你回答前端先发起请求，后端才能持续单向推送数据；你提到原生 SSE/EventSource 通常只支持 GET，所以使用了基于 fetch 魔改、支持 POST 的库。后端设置 text/event-stream、不缓存、保持连接等响应头，然后把 LangChain 的流式输出推给前端，前端持续接收并渲染。
    评价： 回答比较贴近实战。可以进一步补充：SSE 数据格式、心跳、断线重连、错误处理、取消请求、前端逐字渲染、后端流关闭和资源释放。

17. 问题：用户短时间连续发送 10 条消息，后端还没处理完，作为 AI 平台开发者怎么处理连续追问，保证消息不乱、历史消息不混乱？
    追问/关注点： 考察流式 AI 对话中的并发、顺序、状态一致性。
    回答情况： 你说当前项目中不支持连续发送，用户必须等上一次回复完成后才能继续发。若要处理，可以参考 token 刷新队列，用后端队列存储并分批处理。
    评价： 诚实说明了项目限制，但设计回答不够充分。更好的方案可以包括：每条消息分配 messageId/conversationId/parentId；维护消息状态 pending/streaming/canceled/done/failed；新问题到来时取消上一条流；只把最终有效消息写入历史；前端按 ID 合并流式片段，避免错乱。

18. 问题：连续追问时，一般要取消前一个请求，这种取消操作怎么实现？
    追问/关注点： 面试官继续深入取消流式请求的实现。
    回答情况： 你一开始表示没遇到也没想过，随后想到可以用类似 AbortController 的 API 取消前端请求。你又提出可以新增一个接口通知服务端中断本次流式输出，同时不把这次记录保存到数据库。
    评价： 后半部分有思路，但不够体系化。建议掌握：前端用 AbortController.abort() 取消 fetch；后端监听连接关闭或 abort signal，停止模型调用/工具调用，释放资源；数据库记录标记为 canceled 或不入最终上下文；如果模型 API 支持取消，也要向下游传播取消信号。

19. 问题：同一个 AI 对话 100 轮后，上下文超过模型窗口，第 101 轮如何保证上下文尽可能塞进去？
    追问/关注点： 考察 LLM 上下文管理。
    回答情况： 你回答可以做上下文压缩，类似一些 AI 开发工具在超过上下文窗口时做压缩，把无关内容剔除，保留关键用户内容和 AI 回答。
    评价： 有基本方向，但太笼统。可以补充：滑动窗口保留最近 N 轮；对早期对话做摘要；保留用户画像、任务目标、关键决策、未完成事项；工具调用结果可结构化压缩；必要时用向量检索召回相关历史；发送前做 token 预算。

20. 问题：具体压缩哪些东西，哪些不压缩？结合你的项目，哪些上下文无关，哪些有关？
    追问/关注点： 面试官要求落到你项目的数据结构和业务语义。
    回答情况： 你说项目历史对话存储用了 LangChain 相关库自动创建数据库并存储，但没有仔细看过具体存储内容。你认为时间记录、模型标识等字段可以剔除。
    评价： 这是比较弱的回答。建议后续准备：必须清楚历史消息表结构，区分 system/user/assistant/tool 消息；保留系统提示词、当前任务目标、用户最近问题、关键事实、工具结果摘要；丢弃 UI 元信息、时间戳、traceId、重复闲聊、已过期工具结果。

21. 问题：你在 AI 项目中怎么决定什么时候调用工具，什么时候直接回答？怎么控制模型做这件事？
    追问/关注点： 考察 Agent 工具调用、路由和提示词控制。
    回答情况： 你回答项目没有面试官想得那么复杂，本质是把智能体提示词规范化后塞给模型；模型切换如深度思考/普通模型是手动切换；没有接入复杂工具调用。面试官总结它本质更像一个问答机器人，你表示是的。
    评价： 回答真实，但会降低项目技术深度。若要优化表述，可以说“当前版本是问答型助手，暂未实现自动工具路由；如果扩展，会通过 tool schema、意图分类、函数调用、RAG 检索和执行结果回填来控制”。

22. 问题：除了智能英语学习平台和实习项目，还有哪些没聊到但你觉得有难点或亮点的项目？
    追问/关注点： 给你机会展示其他项目亮点。
    回答情况： 你介绍了前端工程化训练营/创新大赛项目，重点说工程化亮点：使用 Monorepo、增量构建工具、CI/CD 流水线、GitHub 托管后自动部署、ESLint、提交规范、公共包、前后端类型共享和配置共享，也提到 AI 辅助生成代码。
    评价： 内容丰富，但表达没有形成“背景-问题-方案-效果”的结构。建议整理成 3 个亮点：构建性能、工程规范、部署自动化，每个亮点说清楚技术选型、个人贡献和收益指标。

二. 算法题

1. 问题：前端应用题：实现一个任务调度，每次调度最多只能同时执行指定数量的任务，任务完成后继续补充新任务，最终按顺序返回结果。你怎么实现？
   追问/关注点： 这是现场编码/算法题，考察 Promise 并发池、异步调度和结果顺序。
   回答情况： 你表示有思路但担心写代码耗时，希望直接讲思路。你说可以维护任务标识、运行中的任务列表和结果数组；每轮调度只执行限定数量的任务；有任务完成后，将下一个未执行任务加入运行队列；直到运行队列为空，说明所有任务完成，再按顺序返回结果。
   评价： 总体方向接近并发池，但没有写出代码，且描述中有“循环不断判断”的倾向，容易变成低效轮询。面试中更推荐直接写 Promise 版本：维护 nextIndex、running，每个 worker 循环取下一个任务并 await，结果按原 index 写入数组。

2. 问题：异步任务什么时候标记为完成？什么时候去遍历和补充新任务？
   追问/关注点： 面试官发现你当前描述更像同步循环，继续追问异步完成时机。
   回答情况： 你一开始说在循环中不断判断，面试官指出代码都是同步的、任务是异步的。之后你尝试修正，说可以把异步任务封装成函数，任务执行完成后将标记改为完成，从运行列表中移除，再加入下一个任务，最终把所有结果返回。
   评价： 说明你理解到“任务完成后再补新任务”，但 Promise 回调/await/递归调度的实现不够清晰。建议重点练习并发池题：Promise.race 方案、worker 方案、递归 runNext 方案，尤其要保证结果顺序和错误处理。

3. 问题：你这个应用题思路正不正确？
   追问/关注点： 这是你反问面试官，希望确认自己的方案。
   回答情况： 面试官表示大概能看懂你的意思，但因为代码没有写出来，无法完全确认。你解释因为电脑电量和时间原因，选择提前讲思路。
   评价： 现场编码题最好尽量写出核心代码，即使不完整，也比只讲思路更有说服力。建议提前准备 10 分钟内能写出的并发调度模板。

三. 复盘总结

4. 总体回答情况总结。
   优势： 你在 token 无感刷新、并发刷新、SSR、SSE 流式输出、工程化项目等方面有实际项目经验；能主动结合项目经历回答，不是完全背概念。
   主要短板： 计算机网络底层链路不够系统，HTTPS/TLS 基础缺失；性能指标知道名称但采集原理和分位分析较弱；AI 项目的 Agent、上下文管理、取消流式请求等深度不足；现场编码题没有写出代码，异步并发调度表达不稳。
   建议优先补强： 第一，准备“URL 到响应全过程”和“HTTPS/TLS 握手”标准答案。第二，补 Web Vitals 的采集、P75/P99 分析和 LCP 排查 SOP。第三，把 AI 项目重新包装成清晰架构：SSE、取消、消息状态、上下文压缩、历史存储。第四，练熟 Promise 并发池、请求队列、并发刷新 token 这类高频代码题。