先说个场景你就知道这个题目值不值得看下去了上个季度我把 FUI 框架里的组件装配逻辑从“启动时扫程序集 反射建表”整套搬到了编译期 Source Generator 生成注册代码。搬完之后最直观的体验是 IDE 里 CtrlF5 一按页面秒开启动日志里再也没出现过那几百次 Assembly.Load 和 Activator.CreateInstance 的调用记录。这套改完不只是快了是整个框架的初始化路径清晰到能一眼看穿。如果你也在维护一个二三十个页面起步的 FUI 应用或者正琢磨怎么把反射注册改成编译期生成这篇文章就是按我实际踩坑的顺序写的。从最初的反射注册怎么设计到它到底慢在哪里再到 Source Generator 的实现细节、坑点、数据对比全部给你摊开。1. 背景FUI 里的“装配”到底在解决什么问题FUI 这类框架通常不是单页应用那种一切靠路由懒加载的玩法它更像是把整个客户端拆成若干个可独立注册的“功能单元”。在实际工程里我指的是这些页面Page与视图模型ViewModel的绑定关系依赖注入容器里需要注册的服务生命周期Singleton/Transient/Scoped导航路由表哪个 URL 对应哪个页面事件订阅器、消息处理器的收集模块初始化器应用启动时需要按顺序执行的那些 Init 方法这些内容如果每个都手动在 Startup 里写一行注册代码一开始没什么等页面到 50 个以上注册代码本身就成了一座屎山。所以最初设计的时候我选择了反射注册。做法很直接定义特性标记代码启动时扫一遍自动建表。[FuiPage(dashboard/main)] public partial class DashboardPage : FuiPage { }启动的逻辑大致长这样var assemblies AppDomain.CurrentDomain.GetAssemblies() .Where(a a.FullName.StartsWith(MyApp.)); foreach (var assembly in assemblies) { foreach (var type in assembly.GetTypes()) { var attr type.GetCustomAttributeFuiPageAttribute(); if (attr ! null) { RegisterPage(attr.Route, type); } } }这套方案最舒服的地方是“少写代码”。新加一个页面贴个特性就完事框架自己去发现、去注册。但等你真的把它跑在一个大型项目上问题就一点一点现出原形了。下面细说。2. 反射注册的三个真实痛点我在生产环境挨过的打2.1 启动耗时Assembly.GetTypes() 不是免费的程序集扫一遍到底多慢取决于你的程序集里有多少类型。我的项目是个中大型客户端本地调试时装了大概 40 多个程序集其中最大的业务程序集里有 3000 多个类型。全部 GetTypes() GetCustomAttribute() 扫描一遍实测耗时在 200 毫秒到 500 毫秒之间波动。注意这只是纯扫描耗时的量级还没有算上后续 Activator.CreateInstance 创建注册表所需元数据的开销。更麻烦的是这个耗时会随着项目变大线性增长。200 毫秒对桌面端来说还能忍但如果你做的是移动端或者 WebAssembly 目标这个时间会被放大得很难看。我在 UWP 平台上实测过同样的逻辑跑下来接近 1 秒。还有一个隐性成本AppDomain.CurrentDomain.GetAssemblies() 拿到的集合并不保证只有你自己项目的程序集可能包含很多第三方库的装载结果。如果你没有老老实实加 Where 过滤Scan 范围会被无限放大。2.2 AOT 与裁剪兼容性反射是 NativeAOT 的头号敌人这是反射方案最致命的问题。当你打开 PublishTrimmed 或者使用 NativeAOT 发布时反射用的元数据通常会被裁剪掉。因为裁剪器是静态分析代码的它看到你只是在字符串里传给 GetCustomAttribute 或者 Activator.CreateInstance根本没法判断你到底需要在运行时保留哪些类型。结果就是本地运行好好的一发布就各种 “Cannot resolve type” 或者干脆某个页面找不到直接白屏。要修这个问题你只能去配 rd.xml一个类型一个类型地留工作量能把你劝退。也许你现在会说“我暂时只做普通 .NET 发布不考虑 AOT”。但做框架的人必须考虑框架的适应场景。等平台要求来了再改代价是你得重构核心注册代码不是改个配置的事。我后来提前做 Source Generator 迁移有一部分原因就是为 NativeAOT 铺路。2.3 重构与维护编译器帮不了你反射注册最大的“软伤”在于它绕开了编译期检查。我犯过一个特别低级的错误给某个 ViewModel 重命名的时候IDE 全自动重命名了类名和文件但是 FuiPage 特性里的字符串路由没有改。系统启动的时候注册逻辑照样跑不会报编译错等到用户点某个菜单才提示找不到页面。这种问题你没法在编译期发现只能靠人工测试去怼。页面少还行页面一多漏掉一两个太正常了。我当时就在团队里立了一条不成文的规矩“所有字符串路由必须加单元测试覆盖”但你想想靠测试去兜一个本来编译器就能帮你查出来的问题本身就是在给自己挖坑。还有一类问题是动态代理和 DI 生命周期注册写错。比如应该注册成 Singleton结果反射扫到一个 Transient 特性扫描的那套代码只在启动的时候跑一次你根本没机会在代码审查的时候发现异常。反射注册不是不能跑是它把太多“本该编译器管的事”往后拖到了运行时。Source Generator 的方向就是把这些事从运行时拉回编译期。3. 编译期装配的思想为什么是 Source Generator先厘清概念Source Generator 是 Roslyn 编译器提供的一种代码生成机制。它不是一个独立的命令行工具而是作为一个 Analyzer 参与进编译流程在你写代码、按 CtrlShiftB 的时候编译器会先运行它把它生成的代码一并编进当前编译单元。它对 FUI 这类框架的意义在于它让你能把“扫描 注册”这个流程从运行时的 200 毫秒压缩到编译期的一次性能开销。运行时装配变成了零开销因为注册表已经是编译产物的一部分。为什么不用 T4 模板或者 MSBuild Task因为这两种方案都做不到“随写随算”。你加了一个新页面T4 模板不会自动感知得手动点一下“运行自定义工具”MSBuild Task 则是在编译前跑一段脚本它需要你额外编写项目文件配置而且拿不到类型语义信息比如它不知道 FuiPageAttribute 到底是什么只看到一堆 .cs 文件文本。Source Generator 最大的优势是它拿到的不是文件是语法树 语义模型它能真正“理解”你的代码精确知道哪些类型标了特性、哪些接口被继承了。换句话说Source Generator 做的事是你在代码里用特性或接口表达你的“意图”生成器在编译期读懂你的意图直接生成具体的注册表代码。错误能在编译期暴露类型安全由编译器保证运行时的开销约等于零。编译前你看到的 - 标记 [FuiPage(dashboard/main)] 的类 - 继承 IFuiModule 的类 编译时生成器做这些 - 扫描所有语法树查找标记类型 - 解析特性的构造参数拿到 route 字符串、生命周期枚举、依赖类型 - 验证重复项、验证路由合法性 - 生成一个 RegisterAll() 方法里面是一长串硬编码的注册调用 运行时的状态 - 框架直接调用 RegisterAll()一次循环完成全部注册4. 实操从反射注册迁移到 Source Generator 的完整过程4.1 项目结构设计生成器必须独立成程序集这是 Source Generator 的第一个硬性规则生成器代码必须放在一个单独的类库项目里TargetFramework 必须是 netstandard2.0因为编译器进程是 .NET Framework 或 .NET 5 都有可能netstandard2.0 是兼容性最稳的选择。我当时的项目结构是这样的Fui.Compiler/ - Fui.Compiler.csproj // netstandard2.0 - FuiPageGenerator.cs // 主生成器 - FuiModuleGenerator.cs // 模块初始化器生成器可选 Fui/runtime/ - FuiPageAttribute.cs - IFuiModule.cs MyApp/ - Pages/DashboardPage.cs - Modules/StartupInitModule.cs注意 Fui.Compiler 项目本身不能被主程序集直接引用只能通过Analyzer的方式间接引入。下面这个 csproj 片段是标准配置Project SdkMicrosoft.NET.Sdk PropertyGroup TargetFrameworknetstandard2.0/TargetFramework LangVersionlatest/LangVersion Nullableenable/Nullable /PropertyGroup ItemGroup PackageReference IncludeMicrosoft.CodeAnalysis.CSharp Version4.8.0 PrivateAssetsall / /ItemGroup /Project而在使用方的主程序中你要这样引用Project SdkMicrosoft.NET.Sdk ItemGroup ProjectReference Include..\Fui\Fui.csproj / !-- 关键把编译器项目当 Analyzer 引用而不是普通引用 -- ProjectReference Include..\Fui.Compiler\Fui.Compiler.csproj OutputItemTypeAnalyzer ReferenceOutputAssemblyfalse / /ItemGroup /Project如果漏了ReferenceOutputAssemblyfalse你会把生成器项目本身也编进主程序集导致各种 IO 错误或者编译器崩溃事故。如果漏了OutputItemTypeAnalyzer生成器根本不会执行。4.2 生成器的核心代码从扫描到生成下面我写一个简化但完整的生成器示例功能是找出所有标记了[FuiPage]特性的类生成一个FuiPageRegistry.RegisterAll()方法。先看运行时的特性定义这个放主类库// Fui/FuiPageAttribute.cs namespace Fui; [AttributeUsage(AttributeTargets.Class, AllowMultiple false, Inherited false)] public sealed class FuiPageAttribute : Attribute { public string Route { get; } public FuiPageAttribute(string route) { Route route; } }再来看生成器本体using System.Collections.Generic; using System.Linq; using System.Text; using Microsoft.CodeAnalysis; using Microsoft.CodeAnalysis.CSharp.Syntax; using Microsoft.CodeAnalysis.Text; namespace Fui.Compiler; [Generator(LanguageNames.CSharp)] public sealed class FuiPageGenerator : IIncrementalGenerator { public void Initialize(IncrementalGeneratorInitializationContext context) { // 1. 注册一个语法提供器只筛选类声明语法节点 var classDeclarations context.SyntaxProvider .CreateSyntaxProvider( predicate: static (node, _) node is ClassDeclarationSyntax, transform: static (ctx, _) GetClassSymbol(ctx)) .Where(static symbol symbol is not null); // 2. 把收集到的符号直接用于生成 context.RegisterSourceOutput(classDeclarations, static (spc, symbol) { if (symbol is null) return; var code GeneratePage(symbol); spc.AddSource($FuiPage_{symbol.MetadataName}.g.cs, SourceText.From(code, Encoding.UTF8)); }); } private static INamedTypeSymbol? GetClassSymbol(GeneratorSyntaxContext context) { var classSyntax (ClassDeclarationSyntax)context.Node; var symbol context.SemanticModel.GetDeclaredSymbol(classSyntax); if (symbol is null) return null; // 语义层面检查是否带有 FuiPage 特性这一步比字符串匹配可靠得多 var attr symbol.GetAttributes() .FirstOrDefault(a a.AttributeClass?.Name FuiPageAttribute); return attr is null ? null : symbol; } private static string GeneratePage(INamedTypeSymbol symbol) { var route symbol.GetAttributes() .First(a a.AttributeClass?.Name FuiPageAttribute) .ConstructorArguments[0].Value as string; var ns symbol.ContainingNamespace.IsGlobalNamespace ? string.Empty : symbol.ContainingNamespace.ToDisplayString(); return $// auto-generated / #nullable enable namespace Fui.Generated {{ public static class FuiPageRegistry {{ public static void RegisterAll() {{ Fui.Routing.RouteTable.Register{symbol.ToDisplayString()}({((route is null) ? null! : $\{route}\)}); }} }} }} ; } }这个例子为了好理解省略了“收集全部类再一次性生成单文件”的做法而是每个类生成一个单独的文件。生产中我更建议用这种“每个标记类生成一个 partial 方法片段”或者“集中一个文件包含全部注册”看你的整合需求。每个类一个文件的好处是增量编译缓存粒度细改动一个页面不会导致整个大文件重新生成。你可能会问为什么用IIncrementalGenerator而不是老的ISourceGenerator因为增量生成器能做缓存和依赖跟踪只有真正影响生成结果的输入变了才触发重跑。老的接口是每次编译全量跑一遍项目大了以后编译速度受影响。我后来在 200 多个页面的项目里实测过增量生成器单次编译只比“完全不跑生成器”多花不到 100 毫秒而旧接口动辄多 1-2 秒。4.3 收集全部类还是逐类生成我建议分步走在上面代码里我偷懒了每遇到一个标记类就 AddSource 一个文件。在代码生成内容完全独立的前提下这是最理想的方式增量生成器的缓存优势能最大化。如果你的注册逻辑需要做全局校验比如路由重复检测就必须把“收集”和“生成”拆成两步// 第一步收集所有带特性的类型 var allPages context.SyntaxProvider .CreateSyntaxProvider(predicate, transform) .Where(symbol symbol is not null) .Collect(); // 关键把 IEnumerable 变成 ImmutableArray // 第二步等收集完成后统一生成一个文件 context.RegisterSourceOutput(allPages, static (spc, pages) { var source GenerateCombinedRegistry(pages); spc.AddSource(FuiPageRegistry.g.cs, source); });.Collect()是增量生成器里一个非常核心的操作符。它表示我不急着一个一个生成等这一轮编译里所有匹配项都拿到了我再统一处理。统一处理的好处是能做交叉校验。例如var seen new HashSetstring(StringComparer.OrdinalIgnoreCase); foreach (var page in pages) { var route GetRoute(page); if (!seen.Add(route)) { // 直接提供一个编译期错误报错信息带路由值 spc.ReportDiagnostic(Diagnostic.Create( new DiagnosticDescriptor(FUI001, Duplicate route, $Route {route} is registered more than once in FUI pages, Fui, DiagnosticSeverity.Error, true), page.Locations.FirstOrDefault())); } }这就能把我前面说的“字符串路由只能靠人工测试兜底”的问题从根上解决重名路由在编译期就会报错IDE 里直接红波浪线。4.4 生成代码的形态设计生成代码的设计其实决定了整套方案的体验。我的建议是尽量生成“笨代码”——就是把所有注册逻辑写成最直观的连续调用不要搞花活。用统一文件方案时生成结果大致长这样// auto-generated / // Generated by Fui.Compiler. DO NOT MODIFY. #nullable enable namespace Fui.Generated { public static class FuiPageRegistry { public static void RegisterAll() { Fui.Routing.RouteTable.RegisterMyApp.Pages.DashboardPage(dashboard/main); Fui.Routing.RouteTable.RegisterMyApp.Pages.SettingsPage(settings); Fui.Routing.RouteTable.RegisterMyApp.Pages.ProfilePage(profile); } public static int Count 3; } }注意我在生成代码里加了Count属性纯粹是为了方便写测试的时候断言“注册数量符合预期”。这是个很小的细节但实测下来对排查“生成器漏扫了某个类”非常有帮助。你只需要在单测里 Assert.Equal(3, FuiPageRegistry.Count)就能立刻看出生成器有没有漏掉某个页面。在代码里“ ”里的类型是完整的语义全名MyApp.Pages.DashboardPage这意味着这个类型必须在可访问范围内。如果这个类是 internal生成代码又不在同一个程序集就会报编译错误。所以要么页面类全公开要么生成器里给生成的代码也加上[assembly: InternalsVisibleTo(...)]或者做成生成一个同程序集内部类。我这里为了省事直接建议所有注册相关的类型都设计为 public这本身就是一种架构约束让框架结构更扁平。4.5 从反射切换过来的运行时改动生成器做完运行时装配逻辑要从“扫描 反射调用”改成“直接调用生成的注册方法”。原来的启动代码var assemblies AppDomain.CurrentDomain.GetAssemblies(); foreach (var asm in assemblies) { foreach (var type in asm.GetTypes()) { // 反射注册逻辑... } }替换成Fui.Generated.FuiPageRegistry.RegisterAll();启动逻辑从十几行变成一行这个对比太直观了。实际项目里FuiModule 的初始化也是类似的生成器收集所有IFuiModule实现类按优先级排序后生成FuiModuleInitializer.InitializeAll()方法运行时直接调用。我在真实项目里保留了一个if (enableReflectionFallback)开关用于在调试特殊问题时候临时退回旧逻辑。但从上线后的数据看这个开关一次都没被打开过。反而因为旧代码长期没有测试覆盖后来我直接把它删了。5. 迁移过程中的常见坑与排查实录5.1 生成器没跑起来配了 Analyzer 但看不到任何生成代码这是最常遇到的问题。很多人配置完 csproj 之后发现 FuiPageRegistry 这个类根本不存在。排查路径如下检查输出窗口有没有生成器相关的报错信息检查 .csproj 里的 ProjectReference 是否带OutputItemTypeAnalyzer少了这个一定不生效在生成器Initialize或RegisterSourceOutput里临时加一个Debugger.Launch()看调试器是否被唤起。如果没调起来说明生成器根本没被加载注意 SDK 版本IIncrementalGenerator需要 Microsoft.CodeAnalysis 4.0 以上.NET 6 SDK 自带的是 4.0 或 4.3.NET 7 以后没问题。如果你用的是老 SDK升级一下还有个小坑如果你改了生成器源码后重新编译主项目报错说找不到某些新生成的文件80% 的情况是 Visual Studio 的 Roslyn 编译器进程没重启。关掉 VS 重启一次或者用 dotnet build 从命令行跑一把通常能解决。5.2 生成器内部抛异常整个编译挂掉源生成器代码一旦有未处理的异常编译进程会直接报错而且错误信息往往很难看因为它是编译器内部的 Crash而不是你的代码报出来的编译错误。所以在生成器内部所有处理逻辑都要包一层 try-catch。开发期间可以包一个#if DEBUG的Debugger.Launch()方便定位。发布版则直接吞掉异常并把错误信息转成一个 Diagnostictry { // 核心生成逻辑 } catch (Exception ex) { context.ReportDiagnostic(Diagnostic.Create( new DiagnosticDescriptor(FUI999, Generator internal error, ex.ToString(), Fui, DiagnosticSeverity.Error, true), location)); }注意最后还要把这个异常继续抛出去不然你就没有错误可看了。这块我花的时间不少大部分是因为某些不常见的语法结构比如 record class、文件作用域命名空间导致的解析异常。5.3 缓存导致生成结果不更新用增量生成器最麻烦的一件事是缓存失效没做好。刚开始写时我把“读取 csproj 的某个属性”放在了transform里结果就是改了 csproj 配置生成结果却不更新。因为增量生成器认为语法树没变输入没有变化直接复用了上一次的输出。解决办法如果生成逻辑依赖编译选项或 MSBuild 属性必须用context.AnalyzerConfigOptionsProvider并手动加入缓存键var optionsProvider context.AnalyzerConfigOptionsProvider; context.RegisterSourceOutput(optionsProvider, static (spc, options) { options.GlobalOptions.TryGetValue(build_property.MyFlag, out var flag); // 生成逻辑依赖 flag });AnalyzerConfigOptionsProvider自带缓存键MSBuild 属性变化会导致重新执行这是标准做法。千万别为了省事去读File.ReadAllText()那会破坏缓存同时带来路径可靠性的问题。5.4 生成代码撞上 nullable 与 namespace 坑生成代码默认不带#nullable指令时会继承主项目的 context可能导致明明不会为 null 的代码却出现CS8603之类的警告甚至在某些设置了 TreatWarningsAsErrors 的项目里直接编译失败。我的建议是生成代码的第一行固定输出#nullable enable同时生成代码里对可能出现 null 的字符处用?? 兜底。还有一个小细节生成的代码不要带 file-scoped namespace因为namespace Foo;这种语法在老版本编译器里不可用而生成器是跑在编译进程里的万一主项目用的还是 C# 9 以下的 LangVersion你的生成代码里用了 file-scoped namespace它直接就编不过。稳妥起见生成代码里一律用 block-scoped namespacenamespace Fui.Generated { // ... }这算是给生成代码的“最低公倍数”写法牺牲一点点美观换取兼容性。5.5 类型可见性问题internal 类生成后无处引用如果你的页面类声明为 internal生成器注释里说它可以生成但生成的代码如果跟页面类不在同一个程序集里比如生成器生成的 FuiPageRegistry 放在了 Fui.Generated 命名空间下编译时就会报“类型不一致”错误。我当时遇到的情况是某个模块的 ViewModel 是 internal我在做测试工程引用时它提示找不到这个类型。为什么因为生成的代码和 internal 类不在同一个程序集。解决方式有两种把你需要注册的类型全改成 public这是最简单最直接的方案用[InternalsVisibleTo(Shared)]把生成的程序集暴露给内部类型我从实用主义出发最后直接规定凡是参与 FUI 注册的实体类都必须是 public。这个约束反过来提升了代码的可审查性因为一眼看过去就知道哪些类会暴露给框架做装配。6. 迁移后的收益数据与体验对比说点干货数据。我用的项目是内部管理系统页面总数大概在 180 个左右Module 62 个事件订阅器 40 个。改造前后的对比指标反射注册Source Generator提升幅度启动装配耗时冷启动380ms0ms编译期完成100%首次页面导航耗时420ms120ms71%路由重复检测运行时不检测编译期拦截彻底解决页面漏注册运行时白屏编译期无感知由测试兜底发布裁剪兼容性不支持原生兼容可发布生成器编译耗时增量0约 120ms可接受这里启动装配耗时直接归零不是玄学是因为那 380ms 的动作确实被移到了编译期执行运行时只是执行一个已经生成好的方法调用几百次注册瞬间完成。首次页面导航耗时下降是因为路由表不再是启动后异步构建而是程序集加载时就绪导航在首次事件循环里就能触发。还有一项不太好量化但体感明显的收益代码评审的时候不再需要去看“启动注册”那段几百行反射代码了。新的代码长这样FuiPageRegistry.RegisterAll(); FuiModuleInitializer.InitializeAll();所有细节都藏在生成的 .g.cs 文件里审查者只需要关注业务类上的特性标得对不对。7. 迁移中已有的坑与排查技巧速查表现象可能原因处理方法生成类找不到没配置 OutputItemTypeAnalyzer检查 csproj添加 analyzer 引用生成器跑了但没输出transform 返回 null 被过滤检查 predicate 与 transform 逻辑生成代码报 CS0234 命名空间不存在主项目没引用运行时库生成代码引用的所有类型都要能被主项目解析生成代码总报 nullable 警告没在生成内容里声明 #nullable enable生成文件头追加 #nullable enable改完生成器不生效VS 编译器进程缓存重启 VS 或命令行 build编译抛异常直接断掉生成器内部没 catch给生成器代码补 try-catch 转 Diagnostic生成结果不更新但改了配置没有使用 AnalyzerConfigOptionsProvider改用 optionsProvider 传递 MSBuild 属性路由字符串重名没被检测生成器没做全局校验用 Collect() 统一生成检测重复Generated 代码没有 auto-generated 头生成器没写头注释默认生成的代码都要带auto-generated /这张表是我花了两个星期在生产环境里一条一条攒出来的真实记录。里面每一个问题我都在 stack overflow 或者 GitHub issue 里看到过属于 Source Generator 新手必经的关卡提前给你省掉试错时间。8. 哪些场景不建议迁移到 Source Generator这不是一个“万能银弹”方案。我在动手做之前也认真想过是不是所有反射注册都应该换。有几个场景用 Source Generator 反而可能不太划算。动态类型/插件系统如果 FUI 允许外部插件在运行时动态加载插件里的类型在编译期根本不存在Source Generator 无能为力。这种场景你必须保留反射或者使用 AssemblyLoadContext 运行时注册。类型数量极少如果项目只有三五个页面反射扫描一次的耗时根本感知不到迁移完全没有必要。Source Generator 的复杂度不低为三五个类型不值得。生成逻辑高度动态如果注册行为严重依赖运行时配置比如读取数据库里的路由表编译期生成只能做到静态部分动态部分你还是得写运行时逻辑这时引入生成器会增加系统复杂度。团队不熟悉 Roslyn 编译原理源生成器调试门槛不低如果团队里没有熟手遇到问题很容易卡死。哪怕是我自己在最初两天也被各种莫名其妙的现象折腾到自闭。9. 从反射到生成器的启发装配的本质是编译期约定写到最后不说空话讲一个我个人实践后的体会。反射注册的核心问题不是性能而是它把“类型之间的关系”推迟到了运行时原本编译器能够帮你做的事全都变成了运行时猜谜。Source Generator 之所以有效是因为它把你已经写进代码的约定特性、接口重新提升为了编译期事实让编译器帮你做检查、做校验、做编译期报错。具体到我这边迁移完成后一个比较大的感受是生成器给了框架设计一个新的自由度。以前为了反射注册我不得不给所有组件定义一套通用的基类或接口现在我可以让生成器去做模式匹配哪怕参与者之间没有共同的基类只要特性标记正确照样能生成注册代码。这让代码的组织方式变得更贴近业务意图而不是为了迁就框架的装配机制。最后再分享一个小技巧我在生成器里加了DEBUG环境变量触发的源代码生成信息打印通过编写一个FuiGenDebug.txt文件来记录生成器扫描到的所有类型和特征值。遇到奇怪的线上问题对着这个文件排查远比翻日志高效。如果你正在做类似的迁移我的建议是先从一个最不重要的注册类型比如事件订阅器开始跑通全链路后再逐步扩大。这套方案的收益是实打实的但前提是你得给它留足学习和踩坑的时间。