服务端2月19日 12:37
大型前端应用中 MobX Store 应该如何拆分和协作？大型应用里用 MobX，关键不是“建一个 store 然后全局导出”，而是把状态边界划清楚。页面越多，store 越容易变成杂物间：登录信息、列表缓存、弹窗状态、错误提示、持久化逻辑全塞一起，短期写得快，后期任何改动都像拆炸弹。比较稳的做法是用 RootStore 管组合关系，业务 Store 管自己的数据和动作，跨模块协作只通过少数明确入口发生。
## 推荐的基本结构
RootStore 不应该写太多业务逻辑，它更像装配层。UserStore、ProductStore、CartStore 等模块各自维护领域状态，构造时拿到 root 或必要依赖。也方便测试时替换依赖。
```ty...
乐闻
前端2月19日 12:39
MobX 的 toJS、toJSON 和 observable.shallow 到底该怎么选？MobX 里经常让人混淆的不是 observable 本身，而是数据离开 MobX 时该怎么处理。`toJS`、`toJSON` 和 `observable.shallow` 都和“普通对象”有关，但位置不同：`toJS` 负责把响应式数据深度转成普通对象，`toJSON` 负责控制序列化输出，`observable.shallow` 则是在创建 observable 时只追踪顶层。## 先记住一句话
把 MobX 数据交给 API、缓存或第三方库时，用 `toJS`；控制 `JSON.stringify` 输出时，写自定义 `toJSON`；数据量很大且整批替换时，才考虑 `obse...前端2月19日 12:39
MobX 应用应该怎么测试 Store 和组件？测试 MobX 应用时，重点不是验证“observable 是否真的能响应”，而是验证业务状态在 action、computed、reaction 和组件渲染之间有没有按预期流动。优先测试 Store，因为大部分规则都在那里；组件测试只覆盖用户能看到和能操作的行为。API 边界可以用 mock 或 MSW 隔离，reaction 这类副作用要记得释放 disposer。不要把每个 observable 字段都测一遍，那会让测试和实现细节绑死，重构一次就碎一片。
一个比较稳的分层是：Store 单元测试覆盖状态变化和异常分支，组件测试覆盖点击、输入、展示，少量集成测试覆盖多个 store...服务端2月19日 13:15
Jest 中 describe、test 和 it 该怎么分工？`describe` 负责分组，`test` 和 `it` 负责定义具体用例；`test` 与 `it` 在 Jest 里是同一个能力，只是表达风格不同。写测试时不要把 `describe` 当成必填包装，也不要为了层级好看一层套一层。好的组织方式是让读者从外层看到模块或场景，从内层看到行为，再从断言里确认结果。简单说，`describe` 管上下文，`test/it` 管一个可以独立失败的事实。
很多测试文件难维护，不是因为 Jest API 难，而是命名和分组把问题藏起来了。比如 `describe('utils')` 下面放几十个用例，失败时只能知道 utils 坏了，却不知道是...服务端2月19日 13:17
Jest 测试跑得太慢时该从哪些地方优化？Jest 测试变慢时，先不要急着把所有用例都改成 mock。更稳的做法是先量出慢在哪里，再从运行范围、测试环境、并发、转换缓存和外部依赖几个点逐个处理。通常收益最大的是三件事：只跑相关测试、把不需要 DOM 的用例放到 `node` 环境、把网络和计时器这类不稳定依赖隔离掉。CI 上还要控制 worker 数量，因为机器核数看起来很多，不代表同时跑满就最快，I/O、转译和内存都会抢资源。
优化前最好先固定基线：记录完整测试耗时、最慢的测试文件、是否开启 coverage、是否每次都重新转译。很多团队感觉“Jest 越来越慢”，实际是新增了 jsdom 用例、覆盖率范围过大、mock 泄...服务端2月19日 13:19
Jest 如何测试异常处理并正确使用 toThrow 和 rejects？异常测试不是为了证明代码“会报错”，而是确认它在错误输入、依赖失败和边界条件下报出正确的错，并且调用方能按预期处理。Jest 里同步异常主要用 toThrow，Promise 拒绝主要用 rejects，回调错误则要显式等待测试结束。最常见的误区是把函数先执行了，再把结果交给 expect，这样异常会在断言前就抛出。
## 同步异常怎么测？
toThrow 接收的是一个函数包装，而不是函数调用结果。可以匹配错误类型、完整消息、部分字符串或正则。
```js
function divide(a, b) {
if (b === 0) throw new RangeError('Di...服务端2月19日 13:19
Jest 如何测试 TypeScript 项目并配置 ts-jest？Jest 测 TypeScript 项目时，先要分清两个问题：测试运行时怎么把 TS 转成 JS，以及类型错误由谁负责检查。ts-jest 可以在 Jest 运行时编译 TypeScript，配置直观，适合希望测试和 tsconfig 保持一致的项目。另一个常见选择是 Babel 或 SWC 转译，它们更快，但通常不做完整类型检查。
## ts-jest 基础配置怎么写？
先安装 Jest、类型声明和 ts-jest。Node 项目一般使用 node 环境，前端组件或 DOM 工具才需要 jsdom。
```bash
npm i -D jest ts-jest @types/jes...服务端2月19日 13:20
Jest 如何测试 fs 文件系统和 I/O 操作？测试文件系统代码时，最重要的问题不是“能不能读写文件”，而是“你的业务逻辑在文件存在、缺失、权限不足、内容损坏时是否处理正确”。Jest 可以 mock fs，也可以配合临时目录做接近真实的集成测试。两种方式都该会用，因为纯 Mock 快但容易脱离真实行为，真实 I/O 准但慢且需要清理。
## 什么时候 Mock fs？
如果函数只是包装读取、解析和错误处理，mock fs 很合适。它能让测试不依赖本机路径，也不会污染项目目录。
```js
const fs = require('fs')
jest.mock('fs')
function readConfig(path) {
...服务端2月19日 13:20
Jest 如何测试 Redux 的 Action、Reducer 和 Selector？Redux 测试最好按代码职责拆开：action creator 测返回的 action，reducer 测状态如何变化，selector 测派生数据，异步 thunk 或 RTK Query 再测副作用边界。不要把所有东西都塞进一个 React 组件测试里，否则失败时很难判断是 UI、store、接口 Mock，还是 reducer 写错了。Jest 的价值在于让这些纯逻辑可以被快速、稳定地验证。
## 从 reducer 开始最划算
reducer 通常是纯函数，输入旧 state 和 action，输出新 state。它不需要 DOM，也不需要 mock store，是 Red...服务端2月19日 13:21
Jest 如何配合 Vue Test Utils 测试 Vue 组件？Vue 组件测试的核心不是把组件内部每一行都测一遍，而是验证它对外表现是否稳定：传入 props 后渲染什么，用户点击后发生什么，是否 emit 正确事件，依赖插件或异步更新时是否能按预期收尾。Jest 负责断言、Mock 和运行环境，@vue/test-utils 负责把 Vue 组件挂载成可操作的 wrapper。实际项目里，测试越贴近用户行为，后期重构越不容易被测试绑住。
## 基础配置怎么写？
Vue 3 项目常见组合是 Jest、@vue/test-utils 和 @vue/vue3-jest。如果还在 Vue 2，需要换成对应版本的 vue-jest，这是最容易踩的版本坑...