根本原因是误用build命令跑dev服务，应改用serve：它跳过写磁盘和完整bundle输出，内存中编译并支持热响应，首次访问延迟仅50–200ms。
开发环境构建等待时间长，根本原因不是 esbuild 慢，而是你用了 build 命令跑 dev 服务——它不监听、不热刷新、每次都要写磁盘，天然不适合开发。
为什么本地启动慢？别用 build，改用 serve
esbuild 的 build 是生产打包逻辑：全量解析、生成文件、写入磁盘。哪怕加了 --watch，它仍会反复输出完整 bundle，首次访问延迟常达 1–3 秒。
-
serve是专为开发设计的轻量服务入口，跳过写磁盘和完整输出，所有编译都在内存中完成 - 首次 HTTP 访问延迟通常压在
50–200ms，且自动响应文件变更并刷新页面 - 不需要额外装
live-server或webpack-dev-server，一条命令就能跑起来
--serve 怎么配才不 404？路径和入口必须对齐
常见错误是 HTML 里写了 <script src="app.js"></script>，但没把 app.js 加进 entryPoints —— esbuild 不扫描 HTML，不会报错，但浏览器加载时就是 404。
- 显式声明入口：
entryPoints: ["src/app.js"]，再配outbase: "src"+outdir: "dist"，确保输出路径与 HTML 引用一致 - HTML 中 script 路径尽量用绝对路径：
<script type="module" src="/bundle.js"></script>，避免./bundle.js在嵌套路由下失效 - 若必须动态解析 HTML 内的
<script></script>标签，用插件esbuild-plugin-html，它能主动扫描并注入 entry
开发阶段加 --minify 反而断点失效？别压缩，保留原始映射
--minify 会重排代码、合并变量、删空格，直接破坏 sourcemap 行号映射。Chrome DevTools 很可能定位到错行，甚至完全找不到断点。
- 开发时关掉
--minify和--tree-shaking（后者默认开启，但删未用代码会让调试逻辑变“不完整”） -
--sourcemap=inline是默认行为，无需额外配置；确保 TypeScript 项目中tsconfig.json同样启用了"sourceMap": true - 如果用了自定义 loader（如
loader: "ts"），确认它没覆盖 sourcemap 生成逻辑
真正卡顿的地方往往不是打包速度，而是路径错位、入口遗漏或 sourcemap 被压缩干扰——这些细节不处理，再快的工具也白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
