Action<T>参数场景下，.NET Core 2.0中RazorPagesOptions如何实例化？

嘿，这个问题抓得很准！我当初第一次看这类扩展方法的时候也有过同样的疑惑——明明没看到new RazorPagesOptions()的代码，怎么就能直接在委托里操作这个对象呢？其实答案藏在.NET Core的依赖注入（DI）和配置系统里，我给你一步步拆解：

1. 框架提前帮你注册并实例化了对象 #

当你在项目中调用AddRazorPages()（或者类似的服务注册方法）时，ASP.NET Core框架已经在背后把RazorPagesOptions这个配置类注册到了DI容器中。它会以单例模式创建这个类的实例——也就是说，整个应用生命周期里只会有一个RazorPagesOptions对象。

2. AddRazorPagesOptions只是让你修改已有的实例 #

你看到的这个方法：

public static IMvcBuilder AddRazorPagesOptions( this IMvcBuilder builder, Action<RazorPagesOptions> setupAction) { }

它的核心作用不是创建对象，而是提供一个入口让你配置已经存在的RazorPagesOptions实例。当你调用这个方法并传入配置委托时：

• 框架会从DI容器中取出已经创建好的RazorPagesOptions对象
• 把这个对象传入你的setupAction委托里，让你可以修改它的属性（比如根目录、路由规则等）
• 最后把修改后的实例放回容器，供后续的Razor Pages组件使用

举个实际代码的例子，你平时可能会这么写：

builder.Services.AddRazorPages()
    .AddRazorPagesOptions(options =>
    {
        // 这里的options就是框架已经实例化好的对象
        options.RootDirectory = "/CustomPages";
        options.Conventions.AddPageRoute("/Home", "");
    });

这里的options完全不需要你自己new，框架已经帮你搞定了实例化的步骤。

3. 这是.NET Core配置的通用模式 #

其实这种“框架负责实例化，开发者负责配置”的模式在.NET Core里非常常见，比如MvcOptions、AuthenticationOptions、CorsOptions等配置类，都是用同样的逻辑处理的。底层是通过DI容器的Configure<T>扩展方法实现的，AddRazorPagesOptions本质上就是对Configure<RazorPagesOptions>的一层封装，让API调用更直观。

总结一下：你不需要显式实例化RazorPagesOptions，ASP.NET Core框架在注册Razor Pages服务的时候已经完成了这个工作，AddRazorPagesOptions只是给你一个修改这个预实例化对象的机会~

内容的提问来源于stack exchange，提问作者Bill