前端2月21日 21:15
MobX 异步操作为什么要用 runInAction 或 flow？MobX 处理异步的关键不是“能不能 await”，而是 `await` 之后的状态修改已经离开原来的 action。开启 `enforceActions` 时，接口返回后直接改 observable 容易报警，也会让更新边界不清。常用做法有两种：简单请求用 `async/await + runInAction`，在成功、失败分支里集中更新 `data/loading/error`；流程复杂、需要取消任务时用 `flow(function*(){})`，把 `await` 换成 `yield`。不要说 async action 会自动包住整个异步过程，它只覆盖同步阶段。
## 追问
#...
乐闻
服务端2月24日 10:29
如何优化 Zustand 状态更新性能？Zustand 性能优化先看订阅粒度：组件只订阅自己需要的字段，不要 `useStore()` 拿整个 store。多个字段一起取时用 shallow 或拆成多个 selector；状态太大时按领域拆 store；异步更新用函数式 `set` 或 `get()` 避免旧值。真正的瓶颈通常不是 Zustand，而是选择器返回新对象、组件订阅过宽、列表渲染太重。
## 追问
### 为什么 `useStore()` 容易造成重渲染？
它订阅整个 store，任何字段变化都会让组件重新渲染。字段越多，误伤越明显。
### shallow 能解决什么问题？
selector 返回对象或数组时...服务端2月24日 10:30
如何在 Zustand 中处理异步操作？Zustand 处理异步不需要额外机制，直接在 action 里写 `async/await`，用 `set` 更新 `loading/data/error`，需要最新状态时用 `get()`。如果是服务端缓存、重试、失效刷新这类问题，优先交给 React Query 或 SWR，Zustand 只保存跨页面共享的 UI 或业务状态。
## 追问
### async action 里为什么要用 `get()`？
异步代码执行时，闭包里的旧值可能已经过期。`get()` 读取的是当前 store 状态，适合在 await 后继续基于最新状态更新。
### loading 和 error...服务端2月24日 10:35
如何对 Zustand store 进行单元测试？Zustand store 单测重点是把状态恢复到干净初始值，再验证 action、异步状态和 selector 行为。同步 action 可以直接用 `getState()` 调；React hook 场景用 `renderHook` 和 `act`；异步 action 要 mock 请求并等待 Promise 结束。面试里别只说“很好测”，要提到全局 store 会污染用例，必须在 `beforeEach` 重置。
## 追问
### 为什么每个测试前要重置 store？
Zustand store 默认是模块级单例，上一个测试改过的状态会留到下一个测试，导致用例顺序一变就失败。
...服务端2月24日 10:35
如何在 Zustand 中自定义中间件？Zustand 自定义中间件本质是包一层 `config`：拦截 `set/get/api`，再把增强后的能力交还给 store。常见用途是日志、校验、性能埋点、撤销重做。面试里先说函数签名，再强调两点：不要破坏原始 `set` 语义；组合多个 middleware 时外层先执行，顺序会影响结果。
## 追问
### 自定义 middleware 和普通 action 封装有什么区别？
普通 action 只管某个业务动作；middleware 能统一拦截所有状态更新，适合横切能力，比如日志、持久化、校验。
### `set` 包装时最容易踩什么坑？
别忘了转发 `replace` ...服务端2月24日 22:21
什么是 Cookie？它的工作原理和用途是什么？Cookie 是浏览器保存的一小段键值数据，通常用来让 HTTP 这种“无状态协议”记住用户状态。流程很简单：服务端在响应里用 `Set-Cookie` 下发 Cookie，浏览器按 Domain、Path、Expires、SameSite 等规则保存；之后访问匹配的地址时，浏览器会自动把 Cookie 放进 `Cookie` 请求头发回服务端。它常用于登录会话、用户偏好、购物车和统计分析。敏感会话 Cookie 一般要配 `Secure`、`HttpOnly`、`SameSite`，否则容易被窃取或被跨站请求滥用。
## 追问
### Cookie 和 localStorage 有...服务端2月24日 22:22
Cookie 的 Secure、HttpOnly、SameSite 有什么区别？如何防止被窃取？防止 Cookie 被窃取，核心是把“传输、读取、跨站发送、作用域”四件事管住：`Secure` 只允许 HTTPS 传输，降低中间人窃听风险；`HttpOnly` 禁止 JavaScript 读取，降低 XSS 偷 Cookie 的风险；`SameSite` 控制跨站请求是否带 Cookie，缓解 CSRF；`Domain` 和 `Path` 缩小发送范围。敏感登录态建议服务端设置 Cookie，不把 token 暴露给前端脚本，并优先使用 `__Host-` 前缀来避免子域覆盖。
## 追问
### Secure 和 HttpOnly 有什么区别？
Secure 管传输，只保证 ...服务端2月24日 22:23
SameSite Cookie 如何防止 CSRF？Strict、Lax、None 怎么选？SameSite 是 `Set-Cookie` 的属性，用来决定 Cookie 是否会随跨站请求发送。它能缓解 CSRF，是因为 CSRF 依赖“用户已登录，浏览器自动带上目标站 Cookie”。当 Cookie 设置为 `Strict` 或多数情况下的 `Lax` 时，恶意站点发起的跨站 POST、iframe、图片等请求通常拿不到登录态。常规业务优先用 `Lax`；高敏感操作用 `Strict`；确实需要第三方嵌入或跨站登录时才用 `None`，并且必须同时加 `Secure`。
## 追问
### Lax 会完全禁止跨站 Cookie 吗？
不会。跨站顶级导航的安全方法，比如用...服务端2月24日 22:23
如何在 JavaScript 中设置、读取和删除 Cookie？JavaScript 操作 Cookie 主要靠 `document.cookie`。读取时它返回当前页面可访问的 Cookie 字符串；设置时一次只能写入一个 `name=value`，不会清空其他 Cookie；删除本质是把同名 Cookie 的过期时间设为过去。实际开发要注意两点：值要用 `encodeURIComponent` 编码，删除时 `Path`、`Domain` 要和设置时一致，否则看起来执行了，其实没删掉。`HttpOnly` Cookie 不能被 JavaScript 读取或设置，只能由服务端通过 `Set-Cookie` 下发。
## 追问
### docum...服务端2月24日 22:23
Cookie 有哪些安全风险？如何防范 XSS、CSRF 和窃取？Cookie 的主要风险有四类：XSS 读取 `document.cookie`、CSRF 借浏览器自动带 Cookie 发请求、HTTP 明文传输被中间人截获，以及 Domain/Path 配置过宽导致 Cookie 被子域或无关路径滥用。敏感 Cookie 应由服务端设置，并组合使用 `HttpOnly`、`Secure`、`SameSite=Lax/Strict`、短有效期和签名校验。注意：SameSite 能降低 CSRF 风险，但高风险写操作仍建议校验 CSRF Token 或 Origin/Referer。
## 追问
### HttpOnly 能彻底防住 XSS 吗？
...