这是一份持续增长的前端工程速记页。每个条目只保留能够帮助判断、测量和避免误优化的信息。
astro dev 与 astro preview 的内容来源不同
astro dev 运行开发服务器,监听 src/ 并通过 HMR 更新页面;astro preview 只提供最近一次 astro build 生成的静态目录(默认 dist/),修改 Markdown 或源码后不会自动重新构建。
- 排查旧页面:用
lsof -nP -iTCP:<port> -sTCP:LISTEN找 PID,再用ps -p <pid> -o pid=,ppid=,lstart=,etime=,command=和lsof -a -p <pid> -d cwd确认命令、启动时间和工作目录;同时比较dist/与源文件时间,并直接请求新增路由验证。 - 记忆点:本地 URL 能访问只证明端口仍有进程监听,不证明它读取的是最新源码。需要边编辑边看时运行
astro dev;需要验证生产构建时先astro build,再运行astro preview。 - 后台进程:Astro 7 的 background 模式会把 PID、端口和日志写入
.astro/dev.json或.astro/preview.json;检测到 AI 编码代理时可能自动启用。原终端关闭后进程仍可存活,父 PID 可能变为 1,应结合监听端口和 JSON 中的 PID 判断,不能只看是否还有终端窗口。 - 来源:Astro CLI:dev、build、preview 与 background;结论也由本地 Astro 7.2.9 进程命令、锁文件、构建时间和 HTTP 404 响应复核。
defineAsyncComponent 与路由体积预算
异步组件被拆成独立 chunk,不等于它不属于页面首次进入成本;如果异步组件在父页面首帧就被渲染,Vue 会立即调用 loader 并下载该 chunk。
- 适合场景:根据 Vite
manifest.json编写首屏或路由体积预算。 - 记忆点:Vite manifest 分别记录静态
imports和dynamicImports。只遍历imports会漏掉首帧立即渲染的defineAsyncComponent;递归计入所有dynamicImports又会把真正由点击等操作延迟的功能算进去。 - 验证方法:预算配置显式标记“首帧必触发”的动态入口并纳入依赖闭包,再用冷缓存浏览器网络记录核对实际请求。是否属于首次成本取决于组件何时渲染,而不是只看它是否使用
import()。 - 来源:Vue 异步组件、Vite manifest 结构。
请求超时应按工作流设置
只有某个关键阶段需要避免无限等待时,应让请求层提供可选超时能力,并由该阶段显式传入;不要因此给所有请求增加同一个全局时限。
- 适合场景:启动鉴权、健康检查等必须在有限时间内结束的流程,同时系统还包含同步、保存或其他可能合理耗时较长的请求。
- 记忆点:超时时间属于工作流策略。全局默认值会扩大行为变化范围,让无关请求在慢网络下被提前取消;请求封装只负责组合调用方取消信号、可选计时器和稳定错误码。
- 验证方法:分别覆盖显式超时会中止、调用方主动取消保持原语义、未传超时时不创建计时器三个测试。
- 来源:通过
AbortController、假定时器和挂起请求的聚焦测试验证。
批量构建必须传播失败退出码
批量构建多个子项目时,可以继续处理后续目标以收集完整结果,但最终命令必须在任一子构建失败时返回非零退出码。
- 适合场景:一个脚本循环执行多个应用、包或平台构建,并被
check、CI 或发布流程当作质量门禁。 - 记忆点:在循环内部
catch后只打印错误,会让脚本最终以0退出,形成“日志里失败、门禁却通过”的假成功。应收集失败项,并在循环结束后设置process.exitCode = 1或抛出汇总错误。 - 验证方法:故意让其中一个最小测试目标失败,确认后续目标仍按策略执行,同时父命令退出码非零且不会打印“全部成功”。
- 来源:通过 Node.js 脚本控制流与子进程退出行为检查验证。
实时循环中的 AI rollout 必须有独立预算
在动画帧回调中同步执行前向推演、MCTS 或其他候选搜索时,最危险的不是平均 CPU 占用,而是某个决策帧一次性超过帧预算并阻塞主线程。
- 适合场景:实时游戏、可视化模拟或交互式工具需要用多个候选动作 × 多个未来步长做决策。
- 记忆点:计算量通常近似
候选数 × 推演步数 × 单步状态成本;难度若同时增加候选数和推演深度,会形成乘法增长。Web Worker 可以移走主线程卡顿,但不会减少总计算量;仍应使用简化预测模型、固定候选预算、缓存/复用缓冲区或跨帧分片。 - 验证方法:用固定场景分别测量单步模拟、状态克隆和完整决策的耗时,并与目标刷新率的单帧预算比较;60 FPS 的理论预算约为 16.7 ms。一次聚焦微基准中,完整状态 rollout 随候选数和深度增长到数百至数千毫秒,证实渲染优化无法消除这种决策帧停顿。
- 来源:通过固定输入的 TypeScript 聚焦微基准和实时循环源码路径验证。