后端【免费下载链接】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 的实体发现discovery过程需要解析实体类的类型信息而使用TsMorphMetadataProvider时还需通过ts-morph读取 TypeScript 源文件这一过程在大型项目中代价高昂。元数据缓存Metadata Cache正是为消除这一启动开销而设计本文将基于 MikroORM 7.2 的官方文档与仓库源码系统讲解元数据缓存的启用时机、自动失效机制、常用配置项、cache:generateCLI 命令以及如何通过自定义SyncCacheAdapter如基于 Redis 的实现和GeneratedCacheAdapter完成生产级部署。为什么要缓存元数据discovery 的开销来源MikroORM 提供多种获取实体元数据的方式。其中TsMorphMetadataProvider会使用ts-morph读取所有实体的 TypeScript 源文件以推断每个属性的类型。这种读源码推断类型的方式在开发期非常便利——定义类型即可完成运行时校验但也意味着每次进程冷启动都要重新解析源文件性能开销大且耗时长。从源码结构看元数据缓存正是为这一场景量身定制的。在 MetadataProvider.ts 中基类MetadataProvider定义了static useCache(): boolean默认返回false而TsMorphMetadataProvider会覆盖该方法返回true因此缓存对TsMorphMetadataProvider是自动启用的对于其他元数据提供者如默认的ReflectMetadataProvider、EntitySchemaMetadataProvider缓存仅在显式配置时启用一般并无必要。一个完整的工作流程如下实体发现discovery过程结束所有实体元数据被序列化写入缓存默认使用FileCacheAdapter将缓存以 JSON 文件形式存放在./temp目录下次启动时discovery 先尝试从缓存加载元数据命中后跳过开销最大的类型解析环节。缓存如何被存储FileCacheAdapter 的底层实现默认的FileCacheAdapter定义于 packages/core/src/cache/FileCacheAdapter.ts它实现了SyncCacheAdapter接口。从源码可以看出其关键设计默认目录构造函数中this.#options.cacheDir ?? process.cwd() /temp即未指定时缓存落在进程工作目录下的temp文件夹FileCacheAdapter.ts。文件组织每个实体一个 JSON 文件路径为${cacheDir}/${name}.json文件名由实体类名派生FileCacheAdapter.ts。写入内容set()写入{ data, origin, hash, version }四元组其中version来自Utils.getORMVersion()用于保证不同 ORM 版本之间的缓存不互相污染FileCacheAdapter.ts。命中校验get()会做两层校验——先比较origin源文件绝对路径是否与当前一致避免同名类来自不同源文件造成的错乱再计算源文件内容的哈希与存储的hash比对哈希基于源文件内容 ORM 版本生成FileCacheAdapter.ts。这即是下文自动失效机制的实现基础。自动失效Automatic Invalidation缓存条目与源文件的修改时间/内容哈希绑定存储。每次请求缓存时适配器都会重新校验若源文件内容发生变化哈希不再匹配缓存条目被判定失效并返回nulldiscovery 重新走完整解析流程并回写新缓存若源文件内容未变缓存直接命中启动速度显著提升。因此在绝大多数场景下你无需关心缓存的存在——它像一层透明的加速垫。唯一需要手动清理缓存的典型场景是在多个 git 分支间切换且各分支的实体目录内容不同。此时旧分支生成的缓存与当前分支的源文件不匹配若哈希校验因文件路径/内容差异而失效不彻底最稳妥的做法是删除./temp目录后重新生成。禁用元数据缓存当不需要缓存例如使用ReflectMetadataProvider且元数据开销可忽略时可通过metadataCache.enabled显式关闭await MikroORM.init({ metadataCache: { enabled: false }, // ... });在 Configuration.ts 中metadataCache配置项的完整字段包括字段类型默认值说明enabledboolean取决于元数据提供者的useCache()是否启用缓存combinedboolean \| string未设置是否将所有元数据合并进单个缓存文件可传true默认路径或自定义路径字符串prettybooleanfalse是否美化 JSON 输出adapterSyncCacheAdapter构造器FileCacheAdapter异步init()时自动加载缓存适配器类optionsDictionary{ cacheDir: process.cwd() /temp }传给适配器构造函数的参数配置解析逻辑还包含一个保护性校验若缓存启用但未指定adapter且使用的是同步MikroORM.init()会抛出Please fill inmetadataCache.adapteroption or use the async MikroORM.init() method which can autoload it的错误Configuration.ts提示用户改用异步init()以自动装载默认适配器。美化输出Pretty Printing默认情况下缓存文件是一行紧凑的 JSON 字符串不利于人工排查。开启pretty后FileCacheAdapter在JSON.stringify时传入缩进参数2输出为易读的多行格式await MikroORM.init({ metadataCache: { pretty: true }, // ... });修改缓存目录FileCacheAdapter通过options.cacheDir读取目录配置await MikroORM.init({ // defaults to ./temp metadataCache: { options: { cacheDir: ... } }, // ... });该路径会与 baseDir 一起参与origin绝对路径的归一化比较FileCacheAdapter.ts因此建议传入绝对路径或相对项目根目录的稳定路径避免因工作目录变化导致缓存频繁失效。使用 CLI 生成缓存mikro-orm cache:generate基于文件夹folder-based的实体发现方式下缓存内容与运行环境强相关如果你通过swc、tsx等工具直接运行 TypeScript 源码discovery 处理的是.ts文件生成的缓存也以 TS 文件为源生产环境通常运行编译后的 JavaScript源文件路径与内容都已改变。因此需要显式生成面向生产的缓存。CLI 命令定义在 packages/cli/src/commands/GenerateCacheCommand.ts# 生成 JS 生产缓存默认 npx mikro-orm cache:generate # 生成面向 .ts 源文件的开发缓存 npx mikro-orm cache:generate --ts # 生成合并后的单文件缓存包可选指定输出路径 npx mikro-orm cache:generate --combined npx mikro-orm cache:generate --combined ./path/to/cache.json该命令的内部流程对应 GenerateCacheCommand.ts读取 CLI 配置并以metadataCache: { enabled: true, adapter: FileCacheAdapter, options }覆盖默认配置强制启用缓存先调用config.getMetadataCacheAdapter().clear()清空旧缓存构造MetadataDiscovery实例并执行discovery.discover(args.ts ?? false)根据--ts标志决定面向 TS 还是 JS 源文件若指定了--combined调用combine()将内存中的所有条目写入单个 JSON 文件并输出生成路径。生产部署GeneratedCacheAdapter 与预构建缓存包针对生产环境不携带 TS 源码、甚至不依赖mikro-orm/reflection的部署诉求官方推荐先本地生成合并缓存包再在生产配置中使用GeneratedCacheAdapternpx mikro-orm cache:generate --combined该命令会生成./temp/metadata.json路径可通过--combined参数自定义随后在部署文档中给出标准用法import { GeneratedCacheAdapter, MikroORM } from mikro-orm/core; await MikroORM.init({ metadataCache: { enabled: true, adapter: GeneratedCacheAdapter, options: { data: require(./temp/metadata.json) }, }, // ... });GeneratedCacheAdapter的源码位于 packages/core/src/cache/GeneratedCacheAdapter.ts它把options.data的键值对装载进内部Mapget()时按className去掉.ts/.js后缀直接取用静态数据完全不依赖文件系统、ts-morph或new Function从而显著缩小生产依赖面并提升启动确定性。同时它实现了CacheAdapter的全部方法get/set/remove/clear可无缝接入 ORM 生命周期。自定义缓存适配器实现 SyncCacheAdapter若默认的文件缓存不满足需求如多实例共享、分布式环境可提供自定义实现。MikroORM 要求自定义适配器实现SyncCacheAdapter接口其完整定义在 packages/core/src/cache/CacheAdapter.tsexport interface SyncCacheAdapter extends CacheAdapter { getT any(name: string, origin?: string): T | undefined; set(name: string, data: any, origin: string, expiration?: number): void; remove(name: string): void; combine?(): string | void; }各方法职责get(name, origin?)按name键读取缓存origin用于失效判定——适配器应忽略来自不同源文件的同名缓存条目FileCacheAdapter正是据此避免同名类串扰set(name, data, origin, expiration?)写入缓存origin反映数据来源源文件路径expiration为可选过期时间remove(name)删除指定条目combine?()可选将所有条目合并为单个缓存串供cache:generate --combined使用。一个基于内存对象模拟的示例实现export class RedisCacheAdapter implements SyncCacheAdapter { ... }接入方式为在metadataCache.adapter传入适配器类并通过options传递构造参数await MikroORM.init({ metadataCache: { adapter: RedisCacheAdapter, options: { ... } }, // ... });处理异步操作的适配器初始化前后手动读写缓存SyncCacheAdapter的所有方法都是同步的而 Redis 等存储的读写通常是异步的。官方推荐的应对策略是在 ORM 初始化之前异步预取缓存、初始化之后异步回写class RedisMetadataCache implements SyncCacheAdapter { constructor(private readonly cache: Recordstring, any) {} getT any(name: string): T | undefined { return this.cache[name] as T | undefined; } set(name: string, data: any, origin: string, expiration?: number): void { this.cache[name] { data, origin, expiration }; } remove(name: string): void { delete this.cache[name]; } combine?(): string | void { return JSON.stringify(this.cache); } } const existingCache await fetchFromRedis(...) ?? {}; const orm await MikroORM.init({ metadataCache: { adapter: RedisCacheAdapter, options: { existingCache } }, // ... }); // ... await saveToRedis(..., existingCache);要点归纳启动前用await fetchFromRedis(...)将既有缓存拉入内存再通过metadataCache.options注入适配器实例RedisMetadataCache在内存对象上执行同步读写异步 I/O 只发生在 ORM 生命周期之外ORM 初始化完成后将更新过的existingCache一次性写回 Redis供下一次进程复用。缓存合并与加载细节源码中的两个易忽视点从 MetadataProvider.ts 可以观察到两个与缓存正确性相关的实现细节值得在自定义适配器或排查缓存问题时留意函数表达式无法被 JSON 序列化索引/唯一约束中的expression若为函数会随 JSON 缓存丢失。loadFromCache()在合并缓存前会把当前元数据中的函数表达式按名称暂存合并后再按名恢复MetadataProvider.ts保证缓存命中后索引表达式依然可用。缓存加载与_id冲突规避_id是进程内运行时的计数器缓存值来自另一次 discovery直接合并可能导致不同实体 ID 折叠。因此loadFromCache()首先Reflect.deleteProperty(cache, _id)删除缓存中的_id字段MetadataProvider.ts。这两个细节解释了为什么官方文档建议大多数情况下忘记缓存机制即可——框架已经替你把跨进程、跨版本的边界情况处理妥当。小结MikroORM 的元数据缓存是一个默认正确、按需定制的机制开发期TsMorphMetadataProvider自动启用FileCacheAdapter基于源文件内容哈希自动失效几乎无需人工干预多分支/环境切换遇到缓存错乱时删除./temp或重新运行mikro-orm cache:generate即可生产部署通过cache:generate --combined生成合并缓存包配合GeneratedCacheAdapter摆脱对ts-morph与 TS 源文件的运行时依赖深度定制实现SyncCacheAdapter同步方法 初始化前后异步预取/回写即可接入 Redis、S3 等任意存储并可通过metadataCache.options注入配置。相关配置项与源码均可直接在本仓库中查阅配置定义、FileCacheAdapter 实现、SyncCacheAdapter 接口、GeneratedCacheAdapter、cache:generate 命令以及部署指南。赞分享后端【免费下载链接】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 元数据缓存Metadata Cache完全指南原理、配置与生产部署MikroORM 元数据缓存Metadata Cache完全指南原理、配置与生产部署 MikroORM 支持多种获取实体元数据metadata的方式后端MikroORM Metadata Cache 完全指南原理、配置与生产级缓存方案MikroORM Metadata Cache 完全指南原理、配置与生产级缓存方案 导读 本文围绕 MikroORM 的 Metadata Cache实体元后端MikroORM 元数据缓存Metadata Cache完整指南原理、自动失效与自定义缓存适配器MikroORM 元数据缓存Metadata Cache完整指南原理、自动失效与自定义缓存适配器 MikroORM 的实体元数据entity metad后端上一篇如何用WeChatMsg打造你的个人数字记忆库三步实现聊天记录永久保存下一篇Harvey LAB架构揭秘:三阶段评估管线深度解析与新手入门指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考