esbuild本地开发服务启动慢是因为误用build命令，应改用serve：它跳过写磁盘和完整bundle输出，内存中编译并支持热响应，首次访问延迟仅50–200ms。
esbuild 本地开发服务启动太慢？别用 build，改用 serve
开发阶段最常踩的坑，就是把生产打包命令直接搬进 dev 流程。esbuild 的 build 是单次快照式打包，不监听文件变化，也不起 HTTP 服务；而 serve 才是专为开发设计的轻量服务入口。
它底层复用构建逻辑，但跳过写磁盘、跳过完整 bundle 输出，直接内存中编译 + 热响应，首次访问延迟通常在 50–200ms 内。你不需要额外装 live-server 或 webpack-dev-server。
-
esbuild --servedir=src --port=3000：静态资源直发，适合纯 HTML + JS 小项目 -
esbuild src/index.ts --bundle --sourcemap --outfile=dist/bundle.js --watch --serve=3000：带编译 + 自动刷新，适合含 TS/JSX 的前端页 - 注意：
--serve不支持 HMR（模块热替换），只做全页刷新；如需保留状态，得靠插件或切换到esbuild-plugin-livereload
HTML 中 script 标签引用未打包 JS，为什么 esbuild 不报错却加载失败？
esbuild 默认不解析 HTML 文件里的 <script src="..."></script>，它只处理你显式传入的 entryPoints。如果你在 index.html 里写了 <script src="app.js"></script>，但没把 app.js 加进 entryPoints，esbuild 不会警告，也不会自动打包它——浏览器自然 404。
正确做法是让 esbuild 主动接管入口：
- 显式声明：
entryPoints: ["src/app.js"]，再配outbase: "src"+outdir: "dist"，确保输出路径对齐 HTML 引用 - 避免相对路径陷阱：HTML 中写
<script type="module" src="/bundle.js"></script>，而非./bundle.js，防止路由嵌套时路径错乱 - 如果必须动态加载 HTML 内 script，用插件如
esbuild-plugin-html，它能扫描并自动加入 entry
为什么加了 --minify 反而让开发时 sourcemap 断点失效？
--minify 在开发阶段毫无必要，而且它会破坏原始行号映射。esbuild 的 sourcemap 默认是 inline 模式，一旦启用压缩，生成的 map 与源码偏差变大，Chrome DevTools 很可能无法准确定位断点位置。
开发环境只需保留基础转换能力：
- 关掉
--minify和--tree-shaking（后者默认开启，但开发时删未用代码反而干扰调试） - 用
--sourcemap=inline（默认值）即可，无需额外配置 - 若用了 TypeScript，确保
tsconfig.json中"sourceMap": true，且 esbuild 的loader: "ts"配置生效，否则 TS → JS 的映射链会断
多人协作时，为什么同事的 esbuild 构建快，你的却卡在 “Scanning” 阶段？
esbuild 的 “Scanning” 阶段负责分析 import 依赖图，耗时主要来自 node_modules 路径遍历。常见瓶颈不是代码量，而是没排除无关目录。
必须加这两项过滤：
-
absolve: ["**/node_modules/**", "**/dist/**", "**/build/**"]—— 注意这是 esbuild v0.21+ 的新字段，旧版本用external列出包名 - 检查是否有
import语句指向了巨型工具库（比如import * as pdfjsLib from 'pdfjs-dist'），这种包即使 external 了，扫描时仍会尝试读取 package.json - Windows 用户特别注意：路径分隔符混用（
\vs/）可能导致 glob 匹配失败，建议统一用正斜杠写法
真正影响开发等待时间的，往往不是最终打包速度，而是从保存文件到浏览器刷新之间的链路完整性——任何一环没对齐，比如 HTML 引用路径错、sourcemap 未生效、node_modules 扫描失控，都会让“极速”变成“假快”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
