esbuild不解析HTML导致script 404却不报错，因其仅处理显式声明的entryPoints；必须配置entryPoints、outbase与outdir对齐路径，并用绝对路径引用或借助esbuild-plugin-html插件扫描。
为什么 HTML 中 script 404 却不报错？
esbuild 默认完全不解析 HTML 文件内容，它只处理你显式声明的 entryPoints。你在 index.html 里写了 <script src="app.js"></script>，但没把 app.js 加进 entryPoints，esbuild 就当它不存在——既不打包，也不校验，浏览器自然加载失败。
- 必须显式声明入口：
entryPoints: ["src/app.js"]，否则任何 HTML 里的src都是“幽灵路径” -
outbase: "src"+outdir: "dist"才能保证输出路径与 HTML 中的引用路径对齐（比如src/app.js→dist/app.js） - HTML 中推荐用绝对路径：
<script type="module" src="/app.js"></script>，避免./app.js在子路由下解析失败 - 若真要自动扫描 HTML 里的 script 标签，得引入插件
esbuild-plugin-html，它会主动提取并注入 entry，但会增加配置复杂度
开发时用 --serve 还是 --build --watch？
用 --serve。根本不是速度问题，而是行为差异：前者是专为开发设计的服务入口，后者本质仍是生产打包逻辑。
-
esbuild --serve=3000不写磁盘、不生成完整 bundle、所有编译在内存中完成，首次 HTTP 访问延迟通常仅 50–200ms -
esbuild --build --watch即使加了--watch，仍会反复写入完整文件到磁盘，且无内置 HTTP 服务，需额外配live-server或 Nginx 才能访问 -
--serve自动响应变更并刷新页面，但注意：它只做全页刷新，不支持 HMR（模块热替换），状态会丢失 - 命令示例：
esbuild src/index.ts --bundle --sourcemap --serve=3000 --outfile=dist/bundle.js，--outfile在 serve 模式下仅用于路径映射，不实际写入文件
开发阶段加 --minify 会导致断点失效？
会，而且非常典型。压缩不是“锦上添花”，而是直接破坏调试链路。
-
--minify重排代码结构、合并变量、删空格，导致sourcemap行号严重偏移，Chrome DevTools 断点大概率跳到错误位置甚至无法命中 -
--tree-shaking默认开启，但开发时删掉未用代码会让逻辑“看起来不完整”，比如某函数明明写了却调不到，怀疑代码没执行，其实是被摇掉了 - 开发只需保留：
--sourcemap=inline（默认值，不用显式写）、loader: "ts"（若用 TS）、tsconfig.json中"sourceMap": true - 如果用了自定义 loader（如
loader: "tsx"），要确认它没覆盖 sourcemap 生成逻辑，否则 TS → JS 映射就断了
VSCode 里怎么一键触发 esbuild dev 服务？
靠 .vscode/tasks.json 注册 shell 任务，而不是装插件或改 launch.json。
立即学习“前端免费学习笔记（深入）”；
- 先全局安装：
npm install -g esbuild（Windows PowerShell 可能需管理员权限；macOS/Linux 用 nvm 的建议加--ignore-scripts） -
tasks.json中 command 写"esbuild"，别写绝对路径（如/usr/local/bin/esbuild），依赖系统PATH更可靠 - type 必须设为
"shell"，否则 Windows 上&&类连接符会失效 - 示例 task：
"command": "esbuild src/index.ts --bundle --sourcemap --serve=3000 --outfile=dist/bundle.js"，设"isBackground": true后 Ctrl+Shift+B 就能跑起来
真正卡顿的地方往往不是打包本身，而是 HTML 路径错位、入口遗漏、sourcemap 被压缩干扰——这些细节没对齐，再快的工具也白搭。
