企业官网建设流程全解析

evlog 是一个 TypeScript 优先的结构化日志库，主打「宽事件（wide events）」与「结构化错误」，一套核心 API 覆盖 15 种以上框架接入方式。这篇文章用一张速查清单帮你 5 分钟选对 Hono、Fastify、Express、NestJS、oRPC 等框架的 evlog 接入方式，不翻几十页文档。

一分钟看懂：框架接入只解决两件事

每个 evlog 框架集成本质上只回答两个问题：

1. logger 放在哪？每个请求创建请求级 logger，挂在框架的上下文上（req.log、c.get('log')、event.locals.log…）
2. 响应结束时发宽事件：整个请求积累的所有字段合并成一条结构化事件，而不是散落的十几行日志

其余能力在所有框架间完全一致：宽事件、结构化错误、采样、脱敏、drain 适配器（Axiom、Sentry、Datadog、OTLP 等）。

💡 没有 HTTP 框架？evlog也支持 Standalone 脚本模式、Cloudflare Workers 和 AWS Lambda。

evlog框架接入方式速查表（15+种完整对照）

完整表格源自官方概览文档：apps/docs/content/4.integrate/frameworks/00.overview.md

四种初始化模式：evlog最快配置方法

所有接入方式按「启动 evlog」的方式归为四类，对号入座即可：

1️⃣ 中间件 / 插件模式（Hono、Express、Fastify、Elysia、SvelteKit、React Router）

一行evlog(options)挂到框架上，请求级 logger 自动创建，响应结束时自动发射宽事件。你不需要管理生命周期。

2️⃣ 模块模式（Nuxt、Nitro v2/v3、NestJS）

Nuxt 和 Nitro 用模块默认导出（Nuxt 下还自动获得useLogger、createError、parseError的自动导入）；NestJS 用EvlogModule.forRoot()，附带全局中间件、异常过滤器和异步配置。

3️⃣ 工厂模式（Next.js、Cloudflare Workers）

Next.js 用createEvlog()工厂 +withEvlog()handler 包装，并提供客户端 Provider；Workers 用createWorkersLogger()创建带 Cloudflare 专属上下文的请求级 logger。

4️⃣ 手动模式（Standalone、AWS Lambda、Astro）

脚本、CLI、队列、无框架 Worker 直接createLogger()/createRequestLogger()。AWS Lambda 的最佳实践是：运行时启动时initLogger一次，每次调用createLogger。

五大主力框架要点速记 🎯

Hono 接入：c.get('log')类型化访问

中间件 +EvlogVariables类型，c.get('log')在整个路由里全类型安全；深层服务用useLogger()（基于 AsyncLocalStorage，Workers 上需要nodejs_compat标志，c.get('log')则无需该标志）。支持流式 body 延迟发射、log.fork()后台任务关联。指南：08.hono.md，示例：examples/hono/

Fastify 接入：request.log影子替换 pino

插件形式的request.log会覆盖 Fastify 内置的 pino logger，老项目迁移时注意这一点。指南：09.fastify.md，示例：examples/fastify/

Express 接入：req.log+ 四参数错误处理器

app.use(evlog())后req.log直接可用，错误交给标准四参数 error handler，宽事件在响应结束时发射。指南：07.express.md，示例：examples/express/

NestJS 接入：模块 + 异常过滤器

EvlogModule.forRoot()一条命令带来全局中间件和异常过滤器，handler 内useLogger()取请求级 logger，适合强类型 DI 风格项目。指南：06.nestjs.md，示例：examples/nestjs/

oRPC 接入：withEvlog()包装 + procedure 中间件

两个原语：withEvlog(handler)把任意 oRPC handler 包装成「每请求一条宽事件」；evlog()procedure 中间件提供类型化的context.log，并自动把 procedure 路径（如users.profile.get）写入operation字段。oRPC v2 官方已宣布原生支持 evlog。指南：15.orpc.md，示例：examples/orpc/

一个隐藏技巧：useLogger()全框架通用

不管选哪种接入方式，调用栈深处（service、repository、AI SDK 层）都可以直接用useLogger()拿到同一个请求级 logger，不需要把req/c/event一层层传下去。这是 evlog 跨框架体验最统一的部分。

日志发往哪里：evlog 适配器（Drains）一览

框架决定「logger 在哪」，适配器决定「事件去哪」，两者完全独立：

• 云端：Axiom、Datadog、Sentry、PostHog、HyperDX、Better Stack、OTLP（及 OTLP/Protobuf）
• 自托管：Loki、ClickHouse、文件系统、内存
• 生产加固：createDrainPipeline提供批量、重试、超时、幂等

适配器实现位于 packages/evlog/src/adapters/，官方清单：apps/docs/content/4.integrate/adapters/

场景选型建议：我该用哪种接入方式？

📌 接完线之后，跑一次npx evlog map可以看到哪些入口还没有日志覆盖；什么都不显示时用npx evlog doctor诊断。这两个 CLI 命令的文档在 packages/cli/src/commands/。

写在最后

evlog 的设计哲学很直白：挖日志不等于可观测性，那是祈祷。15 种框架接入方式背后是同一套核心——宽事件、结构化错误、单一 drain 管道，所以从一个框架迁移到另一个框架，你只需要换「接入方式」，日志编写习惯完全不变。

🚀 想动手试试？克隆仓库git clone https://gitcode.com/gh_mirrors/ev/evlog，每个框架在 examples/ 下都有可运行的最小示例。