后端【免费下载链接】mikro-ormTypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.项目地址https://gitcode.com/gh_mirrors/mi/mikro-orm点击查看免费下载MikroORM 内置了一套功能完备的日志与调试体系开启debug: true即可让 ORM 把每一条 SQL/Mongo 查询、事务边界与实体发现过程实时输出到控制台帮助开发者快速定位问题同时通过logger、loggerFactory、Logger接口、LoggerNamespace命名空间与可插拔的Highlighter你可以对日志的格式、输出目标、颜色与细粒度开关进行完全掌控。本文以 v5.9 官方文档 为核心骨架结合 packages/core/src/logging 下的源码实现完整讲解从一键开启到自定义 Logger 实现的每一层用法读完即可在真实项目中落地一套符合自己需求的 ORM 日志方案。开启 debug 模式对于开发阶段来说打开调试与日志是排查问题最直接的手段。只需在MikroORM.init()的配置中设置debug: truereturn MikroORM.init({ debug: true, });开启之后MikroORM会默认使用console.log()输出所有查询包括事务的begin/commit。例如一次典型的写入流程会看到类似下面的输出[query] select e0.* from author as e0 where e0.name ? limit ? [took 2 ms] [query] begin [took 1 ms] [query] insert into author (name, email, created_at, updated_at, terms_accepted) values (?, ?, ?, ?, ?) [took 2 ms] [query] commit [took 2 ms]从源码看这条日志链路的核心位于 packages/core/src/logging/DefaultLogger.ts 的logQuery()方法查询语句本身由可选的highlighter高亮随后按took耗时毫秒、results结果行数、affected受影响行数拼装元信息再经由log()输出。debug模式本质上是给 Logger 设置了debugMode这在 packages/core/src/utils/Configuration.ts 中可以看到ORM 初始化时会把debug配置、ignoreDeprecations、highlighter与loggerwriter 一并注入loggerFactory构建的 Logger 实例。debug 模式对排查实体发现entity discovery问题同样非常有用——开启后你会看到每一个被处理的实体包括是否命中了元数据缓存[discovery] ORM entity discovery started [discovery] - processing entity Author [discovery] - using cached metadata for entity Author [discovery] - processing entity Book [discovery] - processing entity BookTag [discovery] - entity discovery finished after 13 ms按命名空间Logger Namespaces细粒度控制输出与其一次性输出所有日志MikroORM 支持按LoggerNamespace精确指定需要记录的类别其余类别则保持静默。只需把debug配置成一个命名空间数组return MikroORM.init({ debug: [query], // 现在只记录查询日志 });v5.9 中一共有 4 个命名空间后续版本扩展到了 7 个见 packages/core/src/logging/Logger.ts 中的类型定义命名空间含义query实际执行的 SQL / Mongo 查询语句与事务语句query-params查询参数的绑定值需配合query使用discovery实体发现过程的进度信息info常规信息日志注意如果你提供了query-params则必须同时提供query才会生效——参数日志是作为查询日志的一部分输出的。从源码实现看命名空间过滤逻辑集中在DefaultLogger.isEnabled()packages/core/src/logging/DefaultLogger.ts当debugMode是数组时只有数组内包含该命名空间才输出而当debugMode为true时所有命名空间均启用。Configuration中debug的默认值是falsepackages/core/src/utils/Configuration.ts。自定义 Logger除了默认的console.log输出MikroORM 提供了从简单替换输出函数到完全接管日志实现的三种自定义层级。1. 通过logger选项替换输出函数如果只是想换一个日志出口比如接入自己的日志库直接提供logger回调即可return MikroORM.init({ debug: true, logger: msg myCustomLogger.log(msg), });配置中的logger默认值是console.log.bind(console)packages/core/src/utils/Configuration.ts它会作为LoggerOptions.writer注入 Logger 实例。2. 通过loggerFactory使用自定义的Logger实现想要对日志行为拥有更多控制权可以使用loggerFactory提供自己的Logger接口实现import { Logger, LoggerOptions, MikroORM, Configuration } from mikro-orm/core; class MyLogger implements Logger { // ... } const orm await MikroORM.init({ debug: true, loggerFactory: (options: LoggerOptions) new MyLogger(options), });Logger接口定义如下与 packages/core/src/logging/Logger.ts 一致interface Logger { log(namespace: LoggerNamespace, message: string, context?: LogContext): void; error(namespace: LoggerNamespace, message: string, context?: LogContext): void; warn(namespace: LoggerNamespace, message: string, context?: LogContext): void; logQuery(context: LogContext): void; setDebugMode(debugMode: boolean | LoggerNamespace[]): void; isEnabled(namespace: LoggerNamespace): boolean; } type LoggerNamespace query | query-params | discovery | info; interface LogContext { query?: string; params?: unknown[]; took?: number; level?: info | warning | error; connection?: { type?: string; name?: string; }; }3. 继承DefaultLogger而非从零实现如果不想实现全部接口可以直接继承DefaultLogger它同样从mikro-orm/core导出。DefaultLogger的log()方法会做三件事packages/core/src/logging/DefaultLogger.ts先调用isEnabled()判断当前命名空间是否启用随后清理消息中的换行与多余空格再根据context.level用红色error、黄色warning着色并用青色渲染可选的label最后交给writer输出。此外其logQuery()还会附加took、results、affected等性能元信息并支持经由副本连接的标注usesReplicas配置开启时。继承后你只需覆写关心的个别方法其余行为全部复用。如果你的部署环境不需要彩色输出比如日志要写入文件或进入日志收集系统可以直接使用同样由 core 导出的SimpleLogger——它是DefaultLogger的无色版本packages/core/src/logging/SimpleLogger.ts输出格式为纯文本的[namespace] message。关闭彩色输出默认日志带 ANSI 颜色若要关闭可通过以下环境变量控制NO_COLORMIKRO_ORM_NO_COLORFORCE_COLOR颜色开关的判定逻辑位于 packages/core/src/logging/colors.tsNO_COLOR与MIKRO_ORM_NO_COLOR会禁用颜色FORCE_COLOR与MIKRO_ORM_COLORS则强制启用。此外在配置初始化时packages/core/src/utils/Configuration.ts若颜色被禁用highlighter也会被自动替换为NullHighlighter避免高亮与着色产生不一致的输出。Highlighters语法高亮早期版本使用 Highlight.js 对 CLI 中的 SQL、Mongo 查询、迁移或生成的实体进行高亮。虽然功能正常但该库体积巨大对于通过 webpack 打包或使用 lambda 部署的场景造成了明显的性能问题。因此从 v4 开始高亮默认关闭并提供两个可选的、体积更小的高亮器需要先自行安装import { SqlHighlighter } from mikro-orm/sql-highlighter; MikroORM.init({ highlighter: new SqlHighlighter(), // ... });MongoDB 场景则使用mikro-orm/mongo-highlighter包中的MongoHighlighter。在未配置高亮器时Configuration的默认值是NullHighlighterpackages/core/src/utils/Configuration.ts它的highlight()方法原样返回文本packages/core/src/utils/NullHighlighter.ts从而保证默认情况下零性能开销。高亮只在DefaultLogger.logQuery()中对查询字符串生效packages/core/src/logging/DefaultLogger.ts不影响其它命名空间的日志。结合源码理解完整日志链路把上面几节串起来MikroORM 的日志体系可以概括为一条清晰的调用链MikroORM.init()读取Options在Configuration中确定debug、ignoreDeprecations、highlighter、logger等配置用loggerFactory默认是DefaultLogger.create构建 Logger 实例并把writer默认console.log注入其中驱动层与EntityManager在执行查询、事务、实体发现时调用logger.logQuery(context)或logger.log(namespace, message, context)DefaultLogger依据debugMode命名空间数组或true决定是否输出按level着色并附上耗时、行数等元信息。以上实现均可在 packages/core/src/logging 目录下找到对应的源码文件Logger.ts定义接口与命名空间、DefaultLogger.ts提供带颜色与查询元信息的默认实现、SimpleLogger.ts提供无色实现、colors.ts处理颜色开关配置默认值与校验逻辑则在 packages/core/src/utils/Configuration.ts。小结开发阶段直接debug: true即可获得查询、事务与实体发现的完整日志生产环境建议按需开启命名空间如[query, discovery]并配合slowQueryThreshold等性能类日志控制噪音需要接入既有日志体系时优先用logger回调替换输出函数需要深度定制格式与过滤逻辑时继承DefaultLogger或SimpleLogger必要时再自行实现Logger接口关注 bundle 体积时保持高亮关闭需要可读性时再按需引入SqlHighlighter或MongoHighlighter。掌握以上能力后你可以让 MikroORM 的日志完全服务于自己的开发调试、线上问题定位与日志采集流程。赞分享后端【免费下载链接】mikro-ormTypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.项目地址https://gitcode.com/gh_mirrors/mi/mikro-orm点击查看免费下载相关推荐Realm Swift SDK 日志系统完全指南日志级别、自定义 Logger 与性能调优Realm Swift SDK 日志系统完全指南日志级别、自定义 Logger 与性能调优 本文以 Realm Swift SDKrealm swift 仓数据库移动开发嵌入式数据库Puppeteer 日志通道与自定义 Logger 机制详解从 Logger 类型到协议调试实践Puppeteer 日志通道与自定义 Logger 机制详解从 Logger 类型到协议调试实践 导读 Puppeteer 内置了基于调试通道debug浏览器控制测试网页爬虫开发工具Redux-logger高级用法自定义日志格式和输出策略Redux logger高级用法自定义日志格式和输出策略 Redux logger是Redux开发者工具中不可或缺的中间件它能让你在控制台中清晰查看状态变化开发工具前端上一篇终极指南Visual C运行库合集完整安装与配置教程下一篇Iosevka 25.1.0 发布说明深度解析新增字符、字符变体覆盖扩展与风格集赋值修复创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MikroORM 日志与调试完全指南：debug 模式、Logger Namespaces、自定义 Logger 与语法高亮
后端【免费下载链接】mikro-ormTypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.项目地址https://gitcode.com/gh_mirrors/mi/mikro-orm点击查看免费下载MikroORM 内置了一套功能完备的日志与调试体系开启debug: true即可让 ORM 把每一条 SQL/Mongo 查询、事务边界与实体发现过程实时输出到控制台帮助开发者快速定位问题同时通过logger、loggerFactory、Logger接口、LoggerNamespace命名空间与可插拔的Highlighter你可以对日志的格式、输出目标、颜色与细粒度开关进行完全掌控。本文以 v5.9 官方文档 为核心骨架结合 packages/core/src/logging 下的源码实现完整讲解从一键开启到自定义 Logger 实现的每一层用法读完即可在真实项目中落地一套符合自己需求的 ORM 日志方案。开启 debug 模式对于开发阶段来说打开调试与日志是排查问题最直接的手段。只需在MikroORM.init()的配置中设置debug: truereturn MikroORM.init({ debug: true, });开启之后MikroORM会默认使用console.log()输出所有查询包括事务的begin/commit。例如一次典型的写入流程会看到类似下面的输出[query] select e0.* from author as e0 where e0.name ? limit ? [took 2 ms] [query] begin [took 1 ms] [query] insert into author (name, email, created_at, updated_at, terms_accepted) values (?, ?, ?, ?, ?) [took 2 ms] [query] commit [took 2 ms]从源码看这条日志链路的核心位于 packages/core/src/logging/DefaultLogger.ts 的logQuery()方法查询语句本身由可选的highlighter高亮随后按took耗时毫秒、results结果行数、affected受影响行数拼装元信息再经由log()输出。debug模式本质上是给 Logger 设置了debugMode这在 packages/core/src/utils/Configuration.ts 中可以看到ORM 初始化时会把debug配置、ignoreDeprecations、highlighter与loggerwriter 一并注入loggerFactory构建的 Logger 实例。debug 模式对排查实体发现entity discovery问题同样非常有用——开启后你会看到每一个被处理的实体包括是否命中了元数据缓存[discovery] ORM entity discovery started [discovery] - processing entity Author [discovery] - using cached metadata for entity Author [discovery] - processing entity Book [discovery] - processing entity BookTag [discovery] - entity discovery finished after 13 ms按命名空间Logger Namespaces细粒度控制输出与其一次性输出所有日志MikroORM 支持按LoggerNamespace精确指定需要记录的类别其余类别则保持静默。只需把debug配置成一个命名空间数组return MikroORM.init({ debug: [query], // 现在只记录查询日志 });v5.9 中一共有 4 个命名空间后续版本扩展到了 7 个见 packages/core/src/logging/Logger.ts 中的类型定义命名空间含义query实际执行的 SQL / Mongo 查询语句与事务语句query-params查询参数的绑定值需配合query使用discovery实体发现过程的进度信息info常规信息日志注意如果你提供了query-params则必须同时提供query才会生效——参数日志是作为查询日志的一部分输出的。从源码实现看命名空间过滤逻辑集中在DefaultLogger.isEnabled()packages/core/src/logging/DefaultLogger.ts当debugMode是数组时只有数组内包含该命名空间才输出而当debugMode为true时所有命名空间均启用。Configuration中debug的默认值是falsepackages/core/src/utils/Configuration.ts。自定义 Logger除了默认的console.log输出MikroORM 提供了从简单替换输出函数到完全接管日志实现的三种自定义层级。1. 通过logger选项替换输出函数如果只是想换一个日志出口比如接入自己的日志库直接提供logger回调即可return MikroORM.init({ debug: true, logger: msg myCustomLogger.log(msg), });配置中的logger默认值是console.log.bind(console)packages/core/src/utils/Configuration.ts它会作为LoggerOptions.writer注入 Logger 实例。2. 通过loggerFactory使用自定义的Logger实现想要对日志行为拥有更多控制权可以使用loggerFactory提供自己的Logger接口实现import { Logger, LoggerOptions, MikroORM, Configuration } from mikro-orm/core; class MyLogger implements Logger { // ... } const orm await MikroORM.init({ debug: true, loggerFactory: (options: LoggerOptions) new MyLogger(options), });Logger接口定义如下与 packages/core/src/logging/Logger.ts 一致interface Logger { log(namespace: LoggerNamespace, message: string, context?: LogContext): void; error(namespace: LoggerNamespace, message: string, context?: LogContext): void; warn(namespace: LoggerNamespace, message: string, context?: LogContext): void; logQuery(context: LogContext): void; setDebugMode(debugMode: boolean | LoggerNamespace[]): void; isEnabled(namespace: LoggerNamespace): boolean; } type LoggerNamespace query | query-params | discovery | info; interface LogContext { query?: string; params?: unknown[]; took?: number; level?: info | warning | error; connection?: { type?: string; name?: string; }; }3. 继承DefaultLogger而非从零实现如果不想实现全部接口可以直接继承DefaultLogger它同样从mikro-orm/core导出。DefaultLogger的log()方法会做三件事packages/core/src/logging/DefaultLogger.ts先调用isEnabled()判断当前命名空间是否启用随后清理消息中的换行与多余空格再根据context.level用红色error、黄色warning着色并用青色渲染可选的label最后交给writer输出。此外其logQuery()还会附加took、results、affected等性能元信息并支持经由副本连接的标注usesReplicas配置开启时。继承后你只需覆写关心的个别方法其余行为全部复用。如果你的部署环境不需要彩色输出比如日志要写入文件或进入日志收集系统可以直接使用同样由 core 导出的SimpleLogger——它是DefaultLogger的无色版本packages/core/src/logging/SimpleLogger.ts输出格式为纯文本的[namespace] message。关闭彩色输出默认日志带 ANSI 颜色若要关闭可通过以下环境变量控制NO_COLORMIKRO_ORM_NO_COLORFORCE_COLOR颜色开关的判定逻辑位于 packages/core/src/logging/colors.tsNO_COLOR与MIKRO_ORM_NO_COLOR会禁用颜色FORCE_COLOR与MIKRO_ORM_COLORS则强制启用。此外在配置初始化时packages/core/src/utils/Configuration.ts若颜色被禁用highlighter也会被自动替换为NullHighlighter避免高亮与着色产生不一致的输出。Highlighters语法高亮早期版本使用 Highlight.js 对 CLI 中的 SQL、Mongo 查询、迁移或生成的实体进行高亮。虽然功能正常但该库体积巨大对于通过 webpack 打包或使用 lambda 部署的场景造成了明显的性能问题。因此从 v4 开始高亮默认关闭并提供两个可选的、体积更小的高亮器需要先自行安装import { SqlHighlighter } from mikro-orm/sql-highlighter; MikroORM.init({ highlighter: new SqlHighlighter(), // ... });MongoDB 场景则使用mikro-orm/mongo-highlighter包中的MongoHighlighter。在未配置高亮器时Configuration的默认值是NullHighlighterpackages/core/src/utils/Configuration.ts它的highlight()方法原样返回文本packages/core/src/utils/NullHighlighter.ts从而保证默认情况下零性能开销。高亮只在DefaultLogger.logQuery()中对查询字符串生效packages/core/src/logging/DefaultLogger.ts不影响其它命名空间的日志。结合源码理解完整日志链路把上面几节串起来MikroORM 的日志体系可以概括为一条清晰的调用链MikroORM.init()读取Options在Configuration中确定debug、ignoreDeprecations、highlighter、logger等配置用loggerFactory默认是DefaultLogger.create构建 Logger 实例并把writer默认console.log注入其中驱动层与EntityManager在执行查询、事务、实体发现时调用logger.logQuery(context)或logger.log(namespace, message, context)DefaultLogger依据debugMode命名空间数组或true决定是否输出按level着色并附上耗时、行数等元信息。以上实现均可在 packages/core/src/logging 目录下找到对应的源码文件Logger.ts定义接口与命名空间、DefaultLogger.ts提供带颜色与查询元信息的默认实现、SimpleLogger.ts提供无色实现、colors.ts处理颜色开关配置默认值与校验逻辑则在 packages/core/src/utils/Configuration.ts。小结开发阶段直接debug: true即可获得查询、事务与实体发现的完整日志生产环境建议按需开启命名空间如[query, discovery]并配合slowQueryThreshold等性能类日志控制噪音需要接入既有日志体系时优先用logger回调替换输出函数需要深度定制格式与过滤逻辑时继承DefaultLogger或SimpleLogger必要时再自行实现Logger接口关注 bundle 体积时保持高亮关闭需要可读性时再按需引入SqlHighlighter或MongoHighlighter。掌握以上能力后你可以让 MikroORM 的日志完全服务于自己的开发调试、线上问题定位与日志采集流程。赞分享后端【免费下载链接】mikro-ormTypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.项目地址https://gitcode.com/gh_mirrors/mi/mikro-orm点击查看免费下载相关推荐Realm Swift SDK 日志系统完全指南日志级别、自定义 Logger 与性能调优Realm Swift SDK 日志系统完全指南日志级别、自定义 Logger 与性能调优 本文以 Realm Swift SDKrealm swift 仓数据库移动开发嵌入式数据库Puppeteer 日志通道与自定义 Logger 机制详解从 Logger 类型到协议调试实践Puppeteer 日志通道与自定义 Logger 机制详解从 Logger 类型到协议调试实践 导读 Puppeteer 内置了基于调试通道debug浏览器控制测试网页爬虫开发工具Redux-logger高级用法自定义日志格式和输出策略Redux logger高级用法自定义日志格式和输出策略 Redux logger是Redux开发者工具中不可或缺的中间件它能让你在控制台中清晰查看状态变化开发工具前端上一篇终极指南Visual C运行库合集完整安装与配置教程下一篇Iosevka 25.1.0 发布说明深度解析新增字符、字符变体覆盖扩展与风格集赋值修复创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考