服务端2月18日 23:52
Vite 为什么不默认做 TypeScript 类型检查？Vite 支持 TypeScript，但默认只转译，不做完整类型检查。很多人迁移后会疑惑：页面能跑，`tsc --noEmit` 却报错。原因是 Vite 把开发反馈速度放在前面，类型检查需要理解整个项目的类型图，如果塞进每次模块转换，HMR 会明显变慢。
## Vite 负责转译，不负责兜底
`.ts`、`.tsx` 文件会被 esbuild 快速转成 JavaScript，类型标注会被擦除，JSX 和新语法也会被处理。但 esbuild 不会像 TypeScript 编译器那样做完整类型分析，所以“Vite 能运行”不等于“类型安全”。
```ts
type User = { ...
乐闻
服务端2月18日 23:53
Vite 构建慢该从哪些地方优化？Vite 性能优化先别急着堆配置，先判断慢在哪里：冷启动、页面首次加载、HMR，还是生产构建。Vite 开发环境用原生 ESM 按需转换，生产构建走 Rollup，两条链路的瓶颈不一样。把 Webpack 时代的“全量调参”直接搬过来，常见结果是配置变复杂，速度没明显提升。
## 先定位瓶颈
开发阶段优先看依赖预构建是否反复执行、插件 transform 是否过重、浏览器请求是否太碎。生产阶段重点看 source map、压缩器、大依赖和 chunk 策略。可以先用调试日志和产物分析确认问题，而不是凭感觉改配置。
```bash
pnpm vite --debug
pnpm bui...服务端2月18日 23:53
Vite 如何集成 Vue、React 和 Svelte？插件配置怎么选？Vite 和框架集成的核心，不是把脚手架命令背下来，而是理解插件负责什么。Vite 自己处理开发服务器、依赖预构建、静态资源和 Rollup 构建；Vue、React、Svelte 这些框架特有的语法转换、热更新和编译选项，则交给对应插件。这样拆开看，配置就不容易乱。
## 新项目优先用官方模板
创建项目时最稳妥的方式是使用官方模板。模板会装好框架插件、入口文件和基础 TypeScript 配置，适合从零开始。
```bash
npm create vite@latest my-vue-app -- --template vue-ts
npm create vite@latest ...服务端2月18日 23:53
Vite 环境变量怎么用？为什么只有 VITE_ 前缀能进客户端？Vite 的环境变量分两类：一类给构建工具和服务端配置用，一类会被注入到浏览器代码里。很多线上事故都出在这里：以为 `.env` 里的变量只是本地配置，结果把密钥用 `VITE_` 开头写进了前端包。记住一句话，凡是能通过 `import.meta.env` 在客户端读到的值，都应该被当成公开信息。
## .env 文件怎么加载
Vite 会按当前 mode 读取环境变量。常见文件有 `.env`、`.env.local`、`.env.development`、`.env.production`、`.env.[mode].local`。本地覆盖文件通常不要提交，因为它经常放个人端口、...前端2月19日 09:32
MobX 的核心概念是什么？它是怎么自动更新视图的？MobX 解决的是一个很具体的问题：状态变了以后，哪些地方应该跟着变，不需要你手动列清单。它把应用里的数据看成一张依赖图，组件、计算值和副作用只要在运行时读过某个状态，就会被记录为这个状态的消费者。之后状态被修改，MobX 沿着这张图通知真正受影响的部分，所以它看起来像“自动更新”，实际靠的是运行时依赖追踪。
## MobX 的几个核心概念
**observable** 是可观察状态，通常是对象属性、数组或 Map。它的关键不是“存数据”，而是让读写行为能被 MobX 捕获。
**computed** 是从状态派生出来的值，比如 `fullName`、过滤后的列表、购物车总价。它默...前端2月19日 09:32
MobX 和 Redux 到底该怎么选？适合哪些场景？MobX 和 Redux 的区别不只是 API 写法不同，而是状态管理哲学不同。Redux 强调显式数据流：组件 dispatch action，reducer 生成新 state，状态变化可以被记录和回放。MobX 强调响应式模型：你修改 observable，系统自动知道哪些 computed、reaction 或 observer 组件需要更新。
如果用一句话选型：需要强约束、审计和统一协作时偏 Redux；需要快速建模复杂业务对象、减少样板代码时偏 MobX。现在 Redux Toolkit 已经大幅减少模板代码，所以不能再简单说“Redux 一定啰嗦”。但 MobX 在深层对...服务端2月19日 09:33
MobX 中 observable、computed 和 action 该怎么分工？`observable`、`computed` 和 `action` 是 MobX 里最容易混在一起的三个词，但分工其实很清楚：`observable` 放状态，`computed` 放由状态推导出的值，`action` 放修改状态的过程。一个常见判断是，如果它需要被 UI 观察，就用 observable；如果它能由已有状态算出来，就别再存一份；如果它会改变状态，就让它进入 action 边界。
```ts
import { makeAutoObservable, runInAction } from "mobx";
class TodoStore {
todos = [] a...前端2月19日 09:33
MobX 依赖追踪到底是怎么知道该更新谁的？MobX 依赖追踪的核心可以用一句话概括：谁在运行时读了 observable，谁就会被登记为它的依赖；以后这个 observable 变了，只通知登记过的人。这里的“谁”可能是 `autorun`、`reaction`、`computed`，也可能是被 `observer` 包装的 React 组件。MobX 不靠你手写依赖数组，而是靠运行时读取行为建立依赖图。
一个最小例子如下。`autorun` 第一次执行时会读取 `store.count`，MobX 会把当前 reaction 和 `count` 这个可观察字段连起来。之后 `count` 改变，`autorun` 会重新执行...服务端2月19日 09:34
React 里 MobX observer 为什么能自动更新组件？MobX 的 `observer` 不是简单地给组件加一个订阅开关，它会在组件渲染时记录“这次 render 到底读了哪些 observable”。之后只有这些被读过的状态变化，组件才会重新渲染。也就是说，`observer` 的关键不是“组件用了 store”，而是“组件在渲染期间访问了 store 的哪个字段”。
在 React 项目里，函数组件通常使用 `mobx-react-lite`，类组件才会用到 `mobx-react`。MobX 6 以后更推荐 `makeAutoObservable`，少写装饰器，也更适合 TypeScript 和现代构建环境。
```tsx
imp...服务端2月19日 09:36
MobX 异步操作为什么要用 runInAction 或 flow？MobX 处理异步的核心问题只有一个：`await` 之后，代码已经离开了原来那个 action 的同步执行栈。如果项目开启了 `enforceActions`，这时直接改 observable 可能报错，调试也会变乱。所以 MobX 异步写法通常有两条路：普通 `async/await` 搭配 `runInAction`，或者使用 `flow` 让 generator 的每一步自动包进 action。
## async/await 的常见写法
简单请求用 `runInAction` 最直观。请求前设置 loading；请求回来之后再改 data、error、loading，就放到 ...