文远知行全栈日常实习一二面：SSR 流程与项目拷打

《面试题目》

一面（约 1 小时，无算法无手撕）

1. 自我介绍。
2. 项目中你的数据库是怎么设计的？
3. 数据库中有表之间的包含关系，怎么关联起来？
4. 你提到的这个任务，如何在数据库保证它存储是有序的？
5. 如何记录任务之间的依赖？
6. 简历中提到的”异步任务与事务一致性”是为了解决什么问题？
7. 什么是 SEO 优化？
8. 什么是 SSR？为什么用 SSR？
9. 讲一下 SSR 的流程。
10. SSR 阶段请求到的数据是怎么发给浏览器的？放在哪里？
11. 评论区使用了懒加载还是异步加载？怎么做的？
12. 既然评论区使用了懒加载（不参与 SSR），那么最终浏览器怎么知道要将评论区渲染在哪？
13. 讲一下垃圾回收。
14. 讲一下 HTTPS。
15. 讲一下浏览器缓存。Cache-Control 有哪些字段？ETag 有哪些字段？
16. Vue2 和 Vue3 有哪些区别？

二面（约半小时，全程项目拷打）

17. 自我介绍。
18. 你说到了打包优化，你是怎么发现问题的？有没有测试首屏速度？
19. 选一个你最熟悉的项目，展开讲讲？
20. 你提到了使用 Cloudflare Worker 的 Queues，为什么选择它？
21. 为什么 markdown 转 HTML 选择后端异步渲染？
22. 你的博客首屏加载速度很慢，如何优化？从 HTML 或 Vue 代码的角度入手。
23. 为什么选择 JWT？
24. Serverless 的冷启动了解吗？有没有遇到过冷启动过慢的问题？
25. 讲一下你的 GitHub Actions 脚本做了什么？
26. 为什么需要用 Nginx？

《参考解析》

SSR 的流程与数据注水：服务端收到请求后执行组件渲染，此时数据请求在服务端发出，渲染出的 HTML 直接返回给浏览器；同时把渲染时用到的数据序列化后内联到 HTML 里（通常是 window.__INITIAL_STATE__ 这类全局变量）。浏览器先展示静态 HTML（首屏可见），随后加载 JS 并做 hydration（注水）——客户端用同一份数据重新执行组件树、把事件监听挂上去，让页面”活”过来。核心收益是 SEO 与首屏可感知速度；代价是服务端要承担渲染压力、注水前后不一致会导致闪烁或报错（hydration mismatch），以及需要处理服务端没有 window、document 的问题。

懒加载的评论区如何定位：不参与 SSR 的区块，服务端渲染时只输出一个占位容器（比如带固定 id 或 data 属性的空 div），并把它在文档流中的位置固化进 HTML。客户端 hydrate 后，框架按组件树的结构把评论组件挂载到这个容器里；如果评论还有独立的异步数据，则靠路由或参数（比如文章 id）在客户端发起请求后填充。所以定位靠的是”组件树结构 + 占位节点”，而不是内容本身。

数据库里的有序与依赖：保证有序有两种思路——用自增主键或 position 字段记录显式序号（便于拖拽排序时批量更新），或利用时间戳排序（简单但同一毫秒会并列）。任务之间的依赖用关联表表达（task_id + depends_on_id）比在单行里塞数组更好：能加唯一约束防重复、能反查”谁依赖我”，也便于做环检测。异步任务与事务一致性要解决的问题是”业务数据写成功了但消息没发出去”（或反之），常见解法是本地消息表 + 定时补偿，或事务提交后发消息再由消费端做幂等去重。

首屏优化：按”下载量 → 解析量 → 渲染”三段排查。下载侧看是否把首屏不需要的依赖打进了主包（路由级代码分割、把大库换成按需引入或 CDN 外链）；解析侧看是否有超大的第三方库拖慢主线程；渲染侧看关键 CSS 是否内联、有没有阻塞渲染的同步脚本、字体是否做了 font-display。SSR 站点还要看服务端的渲染耗时和数据请求串行——把首屏需要的几个请求并行发，或者把静态部分预渲染成 ISR，往往比前端优化收益更大。测量工具上，先看首屏速度指标（LCP、TTFB）再动手，别凭感觉改。

为什么用 JWT：它是无状态的自包含凭证，服务端不用存 session、天然适合多实例和跨域场景，也方便 CDN / 边缘节点校验。代价要说清楚：签发后无法立即失效（除非引入黑名单或短过期 + refresh token）、payload 是明文可读（不能放敏感信息）、体积比 sessionId 大、密钥泄露即全盘沦陷。所以选型的正确说法不是”JWT 更好”，而是”这个场景需不需要无状态，能不能接受撤销延迟”。需要即时踢人的后台系统，用服务端 session 或”短 token + 每次校验版本号”更稳。

Serverless 冷启动：函数实例在一段时间无请求后被回收，下次请求要重新拉起运行时、加载依赖、初始化连接，这几步加起来就是冷启动延迟。常见的缓解手段是：控制包体积（依赖裁剪、避免把整个 SDK 打进包）、把重初始化逻辑放到实例外（利用执行环境的复用）、保持一定预热（定时 ping 或预留并发）、连接池改为按需建立或走 HTTP 而非长连接。冷启动对低频接口影响大、对高频接口几乎无感，所以选型时要看流量形态。

Nginx 的作用：反向代理与负载均衡、TLS 终止、静态资源服务与缓存、gzip / brotli 压缩、限流与基础防护、按路径分流到不同后端（比如 /api 转发到应用、其余给静态站）。它挡在应用前面的核心价值是把”不该由应用处理的活”接过去，同时为后端的滚动升级提供统一的入口。