面试题手册

分布式链路追踪就是给一次请求打上 Trace ID，把它经过的网关、服务、数据库、消息队列调用都串起来。面试里先答核心：Trace 表示一次完整请求，Span 表示其中一次操作，Span 之间用 parentId 形成调用树；上下文通常通过 HTTP Header、RPC Metadata 传播；数据由 SDK 或 Agent 采集，再异步上报到 Jaeger、SkyWalking、Zipkin 等后端。现在更推荐用 OpenTelemetry 做统一采集标准，后端再按团队习惯选择 Jaeger、SkyWalking 或商业 APM。追问Trace、Span、Trace ID 有什么区别？Trace 是整条调用链，Span 是链路上的一个节点，比如一次 HTTP 调用或 SQL 查询。Trace ID 贯穿全链路，Span ID 标识当前节点，Parent Span ID 用来还原父子关系。OpenTelemetry 和 Jaeger 是什么关系？OpenTelemetry 主要解决“怎么埋点、怎么采集、怎么传输”的标准化问题；Jaeger 更像存储、查询和展示链路的后端。实际项目里常见组合是 OTel SDK/Collector + Jaeger。Jaeger、SkyWalking、Zipkin 怎么选？Java 微服务、想要 APM 能力更全，可以选 SkyWalking；多语言、高并发链路追踪，Jaeger 更常见；Zipkin 简单稳定，适合轻量场景。新项目优先保证采集侧接 OpenTelemetry，避免后续迁移被某个后端绑死。项目里最容易踩什么坑？第一是异步线程、消息队列、定时任务没传上下文，链路会断。第二是采样率过高拖慢系统，过低又抓不到问题；线上通常按流量、错误率和核心接口分层采样。链路追踪和日志、监控有什么区别？监控告诉你“哪里慢了”，日志告诉你“发生了什么”，链路追踪告诉你“一次请求到底卡在哪个调用”。排障时三者结合，Trace ID 要能在日志里直接检索。写段代码Span span = tracer.spanBuilder("queryUser").startSpan();try (Scope scope = span.makeCurrent()) { return userClient.getUser(id);} catch (Exception e) { span.recordException(e); span.setStatus(StatusCode.ERROR); throw e;} finally { span.end();}

MobX 的 observable 用来把普通状态变成“可被追踪的状态”。组件、computed、autorun 或 reaction 读取它时，MobX 会记录依赖；之后状态变化，相关派生值和视图就会自动更新。现在项目里更常用 makeAutoObservable 或 makeObservable，装饰器写法能见到，但要看团队 Babel/TypeScript 配置。注意：修改状态最好放在 action 里，大对象可用 shallow 降低追踪成本。追问makeAutoObservable 和 makeObservable 有什么区别？makeAutoObservable 会按成员类型自动推断：字段是 observable，getter 是 computed，方法通常是 action。makeObservable 需要手动标注，麻烦一点，但控制更精确，适合复杂 store。observable 默认是深度追踪吗？是的，普通对象会递归转成可观察结构。数据很大、嵌套很深，或者只关心引用变化时，可以用 shallow，避免不必要的代理和依赖追踪。为什么建议在 action 中修改状态？action 能把多次修改合并成一次事务，减少中间状态暴露，也方便开启 enforceActions 做约束。异步请求完成后修改 observable，常用 runInAction。observable 和 computed 怎么配合？observable 存原始状态，computed 负责派生结果。比如 todos 是 observable，completedTodos 应该是 computed，而不是每次在组件里重复 filter。项目里常见坑是什么？一是解构 observable 后丢失响应式读取场景；二是把 observable 对象直接传给不支持代理的第三方库；三是冻结对象或随意替换深层结构，导致追踪和更新不符合预期。写段代码class TodoStore { todos = [] filter = 'all' constructor() { makeAutoObservable(this) } addTodo(text) { this.todos.push({ text, done: false }) } get doneTodos() { return this.todos.filter(t => t.done) }}

MobX 的 computed 用来声明“由 observable 推导出来的值”，比如过滤后的列表、总价、表单是否有效。它的关键点是自动追踪依赖、懒计算、缓存结果：没人读取时不算，依赖没变时重复读取也不重算。面试回答要强调：computed 应该像纯函数，只负责返回值，不要发请求、写日志或修改状态；这些副作用应该交给 reaction。追问computed 为什么能提升性能？因为它会缓存上一次计算结果。只有依赖的 observable 变化，并且 computed 再次被读取时，MobX 才会重新计算；复杂过滤、排序、聚合都适合放进去。computed 和普通 getter 有什么区别？普通 getter 每次访问都执行。computed getter 会被 MobX 管理依赖和缓存，在 observer、autorun、reaction 等响应式上下文中效果最明显。computed 里能不能写异步请求？不建议，也不应该。computed 要同步返回派生值；异步请求会产生副作用，应该用 action 改状态，再用 computed 读取状态生成结果。computed 和 reaction 怎么选？要“算出一个值”，选 computed；要“值变了以后做一件事”，选 reaction。比如 completedTodos 是 computed，userId 变化后拉接口是 reaction。项目里有什么坑？不要在 computed 里返回每次都新建且结构相同的对象，否则可能让观察者误以为结果变了。需要时可以拆小 computed，或使用结构比较配置。写段代码class TodoStore { todos = [] filter = 'all' constructor() { makeAutoObservable(this) } get visibleTodos() { if (this.filter === 'done') return this.todos.filter(t => t.done) return this.todos }}

MobX 里的 reaction 用来处理副作用：状态变了以后，去做日志、请求、持久化、路由跳转这类“不产生派生值”的事。常见有三种：autorun 会立即执行并自动追踪用到的 observable；reaction 把“追踪什么”和“执行什么”分开，更适合精确控制触发条件；when 只在条件第一次满足时执行一次，然后自动清理。面试里要先说清：派生数据用 computed，副作用才用 reaction。追问autorun 和 reaction 有什么区别？autorun 会立即跑一次，函数里读到什么 observable 就追踪什么。reaction 先用 data 函数明确返回要追踪的数据，只有这个数据变化时才执行 effect，适合监听 userId、query 这类明确字段。when 适合什么场景？适合“一次性条件触发”，比如用户登录成功后加载资料、初始化完成后启动订阅。它触发一次后会自动 dispose，不适合长期监听。reaction 里最容易踩什么坑？一是忘记清理 disposer，组件卸载后还在监听；二是在 reaction 里修改自己依赖的状态，造成循环触发；三是异步请求回来后没用 runInAction 修改状态。reaction 和 computed 怎么选？要返回可缓存的派生值，用 computed；要调用接口、写 localStorage、打印日志、操作外部系统，用 reaction。一个记忆法是：computed 回答“值是什么”，reaction 回答“变化后做什么”。写段代码const dispose = reaction( () => store.query, query => { if (query.length > 2) store.search(query) }, { delay: 300 })// React 卸载或不再需要时// dispose()

在 React 中用 MobX，核心是让读取 observable 的组件被 observer 包住。store 可以通过 Context、props 或模块变量传入；实际项目更推荐 Context，测试和多实例更好控。observer 会追踪组件渲染时真正读到的 observable，相关字段变化才重渲染，所以不要在外层提前把 observable 解成普通值再传下去。函数组件优先用 mobx-react-lite，类组件或旧项目才考虑 mobx-react。追问observer 应该包父组件还是子组件？谁读取 observable 就包谁。把整个 App 包起来不等于所有子组件都响应，细粒度 observer 反而更容易减少无关渲染。Context 里的 store 要不要经常替换？通常不要。Provider 的 value 保持同一个 store 实例，更新 observable 字段即可；频繁替换 store 会让依赖关系和测试都变复杂。组件为什么没有更新？优先查三件事：组件是否用了 observer，读取的对象是否真是 observable，是否在 observer 组件外提前解构成普通值。第三方组件能直接吃 observable 吗？不建议。第三方组件不是 observer，传入前最好转成普通数据，或只传它需要的字段。写段代码const StoreContext = createContext(null)export const useStore = () => useContext(StoreContext)const TodoList = observer(() => { const store = useStore() return store.todos.map(todo => <span key={todo.id}>{todo.text}</span>)})

MobX 处理异步的关键不是“能不能 await”，而是 await 之后的状态修改已经离开原来的 action。开启 enforceActions 时，接口返回后直接改 observable 容易报警，也会让更新边界不清。常用做法有两种：简单请求用 async/await + runInAction，在成功、失败分支里集中更新 data/loading/error；流程复杂、需要取消任务时用 flow(function*(){})，把 await 换成 yield。不要说 async action 会自动包住整个异步过程，它只覆盖同步阶段。追问runInAction 和 flow 怎么选？普通接口请求选 runInAction，写法接近日常 async/await；多步骤流程、需要取消、想少写包装代码时选 flow。为什么 await 后还要重新进 action？因为 await 后是新的 tick，原 action 已结束。MobX 官方也强调 await 后的状态修改不在同一个执行阶段。loading 和 error 应该怎么写？进入请求前设 loading=true、清空 error；成功和失败分支都要把 loading=false 放进 action，避免页面一直转圈。实际项目最常见的坑是什么？最常见是 catch 里只记录错误，忘了重置 loading；其次是连续修改多个字段却没用 runInAction，导致严格模式报警。写段代码async fetchUser(id) { this.loading = true this.error = null try { const data = await api.getUser(id) runInAction(() => { this.user = data; this.loading = false }) } catch (e) { runInAction(() => { this.error = e.message; this.loading = false }) }}

Zustand 性能优化先看订阅粒度：组件只订阅自己需要的字段，不要 useStore() 拿整个 store。多个字段一起取时用 shallow 或拆成多个 selector；状态太大时按领域拆 store；异步更新用函数式 set 或 get() 避免旧值。真正的瓶颈通常不是 Zustand，而是选择器返回新对象、组件订阅过宽、列表渲染太重。追问为什么 useStore() 容易造成重渲染？它订阅整个 store，任何字段变化都会让组件重新渲染。字段越多，误伤越明显。shallow 能解决什么问题？selector 返回对象或数组时，每次都是新引用。shallow 会比较第一层字段，字段没变就不触发更新。拆 store 一定更好吗？不一定。强相关状态放一起更好维护；变化频率差异很大、业务边界清楚时再拆，否则会增加同步成本。批量更新要手动处理吗？React 18 下大多数场景会自动批处理。更重要的是把相关字段放在一次 set 里，避免中间状态被订阅者看到。写段代码import { shallow } from 'zustand/shallow';const count = useStore((s) => s.count);const inc = useStore((s) => s.inc);const userView = useStore( (s) => ({ name: s.user.name, role: s.user.role }), shallow);const useStore = create((set) => ({ count: 0, inc: () => set((s) => ({ count: s.count + 1 }))}));

Zustand 处理异步不需要额外机制，直接在 action 里写 async/await，用 set 更新 loading/data/error，需要最新状态时用 get()。如果是服务端缓存、重试、失效刷新这类问题，优先交给 React Query 或 SWR，Zustand 只保存跨页面共享的 UI 或业务状态。追问async action 里为什么要用 get()？异步代码执行时，闭包里的旧值可能已经过期。get() 读取的是当前 store 状态，适合在 await 后继续基于最新状态更新。loading 和 error 应该怎么设计？简单请求可以放 loading: boolean；多个并发请求最好按 key 存状态，避免 A 请求结束把 B 请求的 loading 误关掉。Promise 链和 async/await 有区别吗？能力上差不多。面试回答用 async/await 更清楚，但要说明 action 可以返回 Promise，组件或测试里可以继续 await。什么时候不该把请求全塞进 Zustand？需要缓存、分页、去重、后台刷新、请求取消时，不要自己造一套数据请求框架，直接用 React Query/SWR 更稳。写段代码const useStore = create((set, get) => ({ user: null, loading: false, error: null, fetchUser: async (id) => { set({ loading: true, error: null }); try { const user = await fetch(`/api/users/${id}`).then(r => r.json()); set({ user, loading: false }); } catch (e) { set({ error: e.message, loading: false }); } }}));

Zustand store 单测重点是把状态恢复到干净初始值，再验证 action、异步状态和 selector 行为。同步 action 可以直接用 getState() 调；React hook 场景用 renderHook 和 act；异步 action 要 mock 请求并等待 Promise 结束。面试里别只说“很好测”，要提到全局 store 会污染用例，必须在 beforeEach 重置。追问为什么每个测试前要重置 store？Zustand store 默认是模块级单例，上一个测试改过的状态会留到下一个测试，导致用例顺序一变就失败。测 action 一定要 renderHook 吗？不一定。纯 store 逻辑用 useStore.getState().action() 更快；只有要验证 hook 订阅和组件重渲染时，才需要 renderHook。异步 action 怎么测？mock fetch 或请求层，调用 action 后断言 loading、data、error 的最终状态。需要中间态时，可以分阶段 await。selector 性能怎么测？订阅一个具体 selector，更新无关字段，断言渲染次数不变；再更新目标字段，断言它才重新触发。写段代码beforeEach(() => { useStore.setState({ count: 0, user: null }, true);});test('increments count', () => { useStore.getState().increment(); expect(useStore.getState().count).toBe(1);});test('fetch user', async () => { vi.spyOn(global, 'fetch').mockResolvedValue({ json: async () => ({ id: 1 }) }); await useStore.getState().fetchUser(1); expect(useStore.getState().user).toEqual({ id: 1 });});

Zustand 自定义中间件本质是包一层 config：拦截 set/get/api，再把增强后的能力交还给 store。常见用途是日志、校验、性能埋点、撤销重做。面试里先说函数签名，再强调两点：不要破坏原始 set 语义；组合多个 middleware 时外层先执行，顺序会影响结果。追问自定义 middleware 和普通 action 封装有什么区别？普通 action 只管某个业务动作；middleware 能统一拦截所有状态更新，适合横切能力，比如日志、持久化、校验。set 包装时最容易踩什么坑？别忘了转发 replace 参数，也不要在 middleware 里无条件再次调用增强后的 set，否则可能递归或改变 replace 行为。多个 middleware 的执行顺序怎么看？create(a(b(config))) 中，a 先拿到 config 并包装，实际更新时通常外层逻辑先触发。日志、persist、immer 混用时要明确谁先处理原始对象。实际项目会怎么用？我更倾向把日志、权限校验、状态快照放 middleware，业务状态变化仍留在 action 里，避免 middleware 变成黑盒业务层。写段代码const logger = (config) => (set, get, api) => config((partial, replace) => { const prev = get(); const ret = set(partial, replace); console.log('zustand change', { prev, next: get() }); return ret; }, get, api);const useStore = create(logger((set) => ({ count: 0, inc: () => set((s) => ({ count: s.count + 1 }))})));