🧠 为什么 ESM + 无 optimizeDeps 能工作？
| 机制 | 说明 |
|---|---|
| Symlink 保留路径 | web/node_modules/@my-org/utils → ../../../utils |
Vite 直接加载 .ts | 遇到 .ts 自动用 esbuild 转 JS，保留 sourcemap |
| HMR 监听源文件 | Vite 的 watcher 跟踪 packages/utils/index.ts 变更 |
| 无中间缓存 | 不走 .vite/deps/，避免“代码冻结” |
🚫 为什么不推荐用 module.exports + optimizeDeps？
| 缺点 | 说明 |
|---|---|
| 热更新失效 | 预构建后代码被“快照”，变更不触发 HMR |
| 构建变慢 | 每次启动都要重新构建 deps |
| 类型丢失 | CJS 模块难以提供 .d.ts 类型 |
| 与现代生态脱节 | React/Vue/Svelte 全面拥抱 ESM |
✅ 什么情况下才需要 optimizeDeps.include？
| 场景 | 是否需要 |
|---|---|
本地包是纯 ESM（.js 或 .ts + export） | ❌ 不需要 |
本地包用了 CommonJS（module.exports） | ✅ 需要 |
| 本地包依赖了未被 Vite 自动识别的第三方库（如某些 CJS 库） | ✅ 需要 |
| 本地包很大，想提前编译加速首屏 | ⚠️ 可选，但牺牲 HMR |
