面试官很专业，循序渐进。第一次面试表现不太好，面着面着就熟练了。加油吧

手写题：用户卡片（串行请求 + 竞态）

实现一个 React 卡片组件 Demo，根据 props userId 拉用户和团队信息并展示。

接口

两个 REST 接口，团队接口依赖用户接口返回的 teamId，必须串行。

fetch 即可，不用封装请求库。

UI

一张横排卡片（样式见 demo.less）：

左侧头像图
右侧上：用户名、年龄、团队名
右侧下：成员数（members.length）

约束：

userId 为空：不请求
用户还没回来：整卡显示「加载中...」
用户已到、团队未到：人的信息先出来，团队名显示「团队加载中...」，成员数显示 -
请求失败：显示「加载失败」（取消请求不要当成失败）

必须处理的点

串行：先 user，再用 user.teamId 打 team，不要两个一起发。
竞态：userId 从 A 快速切到 B 时，A 的响应不得写到 B 的卡片上。用 AbortController：userId 变化时 abort 上一次的 user + team 请求；AbortError 直接忽略。
切人要清态：新的 userId 进来时先把 user / team / error 置空，不要闪一下上一个人的数据。
数据分开存：user、team 两个 state，不要揉成一个对象（两份数据到的时间不同，合成后切人容易把旧 team 贴到新 user 上）。

组件签名

验收

传入 userId 后先出加载中，再出用户，再出团队
连续快速改 userId，最终卡片必须是最后一次 id 的数据
切走时没有「加载失败」闪一下（abort 不是错误）

卡片场景，a 接口用户信息，b 接口团队信息。写到一个变量里 vs 分开写，哪个好？各有什么优缺点

对着 面试/demo.tsx 讲。接口是串行的：/user/info/${userId} 先拿到 { name, age, teamId }，再用 teamId 打 /team/info/${teamId}。

demo 现在是分开的：user、team 两个 state。面试官说「写到一个变量里」，指的是另一种写法：const [card, setCard] = useState(null) 把两份数据揉成一张卡。

这题选分开。 两份数据来源不同、到的时间不同、失败也可以不同。

	分开两个 state（demo）	合成一个 `card`
渲染	user 先到就能出名字/年龄，team 未到显示「团队加载中…」	容易等拼齐再画，首屏更空；或者每次 spread，容易把旧 team 带到新 user 上
失败	user 挂了整卡失败；team 挂了人还在，成员显示 `-`	loading / error 不好拆，一张卡只能「全成功 / 全失败」
更新	`setUser` / `setTeam` 语义清楚	一次 setState 少一次 render，reset 也方便
竞态	切换 userId 时两个都置 `null`，旧请求 abort	`setCard({ ...prev, user })` 特别容易串卡（上一张的 team 留在新 user 上）

口述 30 秒：

这个卡是两个接口、team 还依赖 user.teamId，我会分开存。demo 里 user 到了先画人，team 后到再补团队名和人数。揉成一个对象看起来省事，但 userId 一切换，旧 team 很容易贴到新 user 上，loading/error 也拆不开。多个一次 render 换数据边界清楚，这场景划算。

什么时候可以合成一个：同一接口一次返回、或必须同时有才展示（骨架统一、没有渐进）。这张卡不是。

怎么处理 props 的竞态问题

竞态：userId 从 A 很快切到 B，A 的请求后回来，把 B 的卡改成 A 的数据。更隐蔽的是 A 的 user + A 的 team 后到，写进已经是 B 的卡。demo 就是这个场景，因为 team 请求更晚。

demo 里已经做了三件：

AbortController：userId 变了，cleanup 里 abort()，A 的 user/team 请求都停；AbortError 直接 return，不 setError。
先清空：effect 一进来 setUser(null); setTeam(null)，界面立刻回「加载中」，不会短暂显示上一张卡。
依赖只有 userId：换人就重跑整段串行请求，不拿过期的 teamId 去打 team。

为什么 abort 特别重要： 两个请求是串行的。只判断「回来的 userId === 当前 userId」但忘了 abort，A 的 team 仍可能在 B 的 user 已经渲染后才 setTeam，团队名就会错。一个 controller 绑两次 fetch，切人两个一起断。

没有 AbortController 的备选： 闭包里 let cancelled = false，cleanup 置 true，setState 前判断；或自增 reqId，只认最新 id。无限滚动分页同理：只认最新 page。

不要这么写： setCard(prev => ({ ...prev, team }))。prev 可能已经是下一个人，旧 team 会合并进去——这就是「合成一个变量」在竞态里更危险的原因。

卡片非定宽（自适应元素卡片）一排n个水平换行怎么做

多卡片这边怎么做性能优化？虚拟滚动，无限滚动

三件事不是互斥：先控数据量，再控 DOM 量。社区博客/活动卡片列表、大赛滚榜都是这套。

	解决什么	怎么做	什么时候上
分页	一次别拉 1000 张卡	`page` + `pageSize`，首屏 10～20	永远先有
无限滚动	接着往下看，不用点「下一页」	底部哨兵 + IntersectionObserver 触达再请求下一页、append	信息流、卡片墙
虚拟滚动	就算数据已经很多，DOM 也只画可视区	占位总高度 + 只 mount 可见行（+ overscan）	几百张以上、滚动开始掉帧

你写的 MutionObserve 是 IntersectionObserver。MutationObserver 看 DOM 增删，不管滚动曝光，无限加载用错了。

口述 45 秒

多卡片我分层做。
数据： 接口分页，首屏只拿一屏。卡片上的封面图 loading="lazy"，进视口再下。
无限滚动： 列表底放一个哨兵 DOM，IntersectionObserver 看见了就请求下一页，数据 append。请求带 page，旧页返回就丢（竞态）。key 用业务 id，不要 index。
虚拟滚动： 数据已经很多、DOM 太多才上。容器固定高度，scrollTop 算出可见区间，只渲染这几行，上面用 padding 撑开。社区大赛滚榜就是虚拟列表 + userId 当 key，避免整表 replace 闪烁。
卡片墙还有一特：一排 n 个，虚拟化按行做，不是按单张卡。高度不齐（摘要有长有短）时虚拟滚动很难估总高，这种列表我优先分页 + 无限滚动，不上虚拟列表。

无限滚动要点

用 IntersectionObserver，别用 scroll 里狂读 scrollTop（易回流）
rootMargin: '200px' 提前加载，少白屏
分页请求竞态：只认最新 page / AbortController（接上一题 props 竞态）
不要每张卡再打用户信息、团队信息；列表接口一次带齐，详情再懒拉

虚拟滚动原理（多列卡片）

坑：

卡片高度不固定 → 要测量缓存，别一上来承诺虚拟列表
key 必须稳定（blogId / userId），index 会错位、图片串
和无限滚动可以叠：下面加载更多，上面仍只画可视行
库：react-window / react-virtualized；手写能讲清原理即可

可能追问

几十张卡也要虚拟滚动吗？ 不要。分页 + 图懒加载够了，虚拟列表有滚动跳动、焦点、测高成本。
无限滚动 vs 虚拟滚动？ 前者管「数据从哪来」，后者管「DOM 画多少」。数据 20 条无限滚就行；数据 2000 条且要一次拿着筛选，才虚拟化。
滚榜怎么防闪？ 稳定 key、增量 patch、节流 setState；高峰只更 Top N。
Observer 为啥比 scroll 好？ 浏览器算交叉，回调次数少，不在滚动热路径里读布局。

介绍下你们的性能优化，哪个提升最大

只讲社区官网。口径：核心模板（首页、博客列表）治理期 RUM P75 首屏 4s→1.2s，FCP 2.1s→0.9s。别说全站、别说 LCP<1.2s。

提升最大的一刀：路由级拆包。 CSR SPA 首屏慢，主因是主包把博客/活动/大赛/Three.js 全打进去，下载+解析堵住 FCP。React.lazy / Bigfish dynamic() 按路由拆，重库 import()，主包大约少 40%，RUM 上 JS 下载和 FCP 一起掉。图片是第二刀（LCP 元素），memo 是列表卡顿，不是这次首屏数字的主因。

口述 60 秒

社区官网是 Bigfish CSR SPA，日均 PV 约 1 万。治理前核心入口打开慢，内部 RUM P75 首屏大约 4 秒。
我按 Web Vitals 拆：先看 FCP/LCP 被什么堵住。瀑布图上首屏 JS 太大，主包里塞了非首屏路由和 Three.js、G2。所以提升最大的是代码分割：路由懒加载 + 重库动态 import，主包体积大概少 40%。然后补 LCP 主图：WebP、压体积、preload，非首屏图 loading="lazy"。CDN 保静态资源。
治理发版后核心模板 RUM P75 4s→1.2s，FCP 2.1s→0.9s。1.2s 是那一窗口核心 URL 的档位，不是每次打开、也不是全站；后来上了 Three、大赛，个别页 LCP 会回弹，所以简历写「首屏」不写 LCP。

手段按贡献排序（被追问展开）

优先级	做什么	为什么有效
1 最大	路由 `lazy`/`dynamic()`；Three.js、G2、富编辑器 `import()`	主包约 −40%，先下载、先解析的 JS 变少，FCP 跟着掉
2	首屏主图 WebP + 合适尺寸 + `<link rel="preload">`	LCP 元素经常是 Banner，图比 JS 还晚出时这一刀最明显
3	非首屏图 TinyPNG + `loading="lazy"`	不抢首屏带宽
4	CDN、公共 vendor 抽 chunk	缓存命中、长缓存
列表卡了再上	`React.memo` / `useMemo`	保滚动，不解释 4s→1.2s

爬虫路径把 Three 降级是 SEO/FC 超时，跟用户首屏分开说，别算进 1.2s。

可能追问（短答）

为什么拆包贡献最大？ 站点是 CSR，HTML 几乎是空壳，首屏时间被 JS 下载和执行绑死。图优化救 LCP 元素，救不了「主包还没下完」。

cookie 和 localstorage，你们平常怎么使用。有什么业务使用场景

口述分层（先画职责，再接项目）：

	Cookie	localStorage
谁写	登录态：服务端 `Set-Cookie`；埋点 ID：前端 SDK	前端自己写
JS 能不能读	HttpOnly 的读不到；埋点 Cookie 能读	能
请求自动带	同源自动带，适合鉴权	不会自动带，要自己塞 Header
容量 / 过期	~4KB；可设 Expires/Max-Age	~5MB；永不过期，除非手动清
跨子域	可写父域 `.oceanbase.com`	严格同源，跨不了子域
典型场景	登录 Session、CSRF token、埋点 `cookieofx`	语言偏好、侧边栏折叠、合法期内授权缓存、埋点备份

业务里怎么分：

登录鉴权：走 Cookie，前端不碰；401 拦截跳登录。
纯前端偏好：语言、UI 状态 → localStorage / sessionStorage（SeekDB locale：URL > localStorage > 默认英文）。
埋点用户标识（ob-tm）：Cookie + localStorage 双写 cookieofx + 30 分钟滑动 sessionId。只清 Cookie 时从 localStorage 补回来，避免同一人被运营算两个人。

cookie 呢

我们平常一般不直接操作 cookie，因为整站登录态是 HttpOnly。

展开（面试官追问「那 cookie 你们还用吗」）：

登录 Cookie 前端不碰

服务端 Set-Cookie + HttpOnly + Secure + SameSite
JS 读不到 document.cookie，XSS 也偷不走登录态
请求浏览器自动带上，前端只处理 401 / 过期跳转
这就是「整站 HttpOnly、不直接操作 cookie」的意思——指的是鉴权 Cookie

但埋点 Cookie 必须前端写

ob-tm 的 cookieofx 要给 JS 读、给各子站共享，不能 HttpOnly
写到父域 .oceanbase.com，path /，社区官网 / SeekDB 共用一份用户 ID
同时写一份到 localStorage：用户只清 Cookie 时还能修回来
sessionId 是 30 分钟滑动：每次上报前续期，离开 30 分钟再来算新会话

和 localStorage 的分工一句话

Cookie：要随请求走、要跨子域、要给服务端看见 → 用 Cookie
localStorage：只给前端自己用的偏好 / 备份 → 用 Storage
Token 不放 localStorage 当登录态（XSS 能读），登录态交给 HttpOnly Cookie

可能再追问，短答：

HttpOnly：禁止 JS 读，防 XSS 偷 Cookie
Secure：只走 HTTPS
SameSite=Lax/Strict：减轻 CSRF；跨站 POST 要 None + Secure
跨子域：Domain=.oceanbase.com；localStorage 做不到
为什么不把 cookieofx 也设 HttpOnly：埋点 SDK 要读、要和 localStorage 互修，设了就双写失败