请求这个Action，返回结果如下：
options:Blue|ad328f15-254f-4505-a79f-4f27db4a393e,optionsSnapshot:Red|dba5f550-29ca-4779-9a02-781dd17f595a,optionsMonitor:Gray|a799fa41-9444-45dd-b51b-fcd15049f98f
刷新页面，返回结果为：
options:Blue|ad328f15-254f-4505-a79f-4f27db4a393e,optionsSnapshot:Red|a2350cb3-c156-4f71-bb2d-25890fe08bec,optionsMonitor:Gray|a799fa41-9444-45dd-b51b-fcd15049f98f
可见IOptions和IOptionsMonitor两种方式获取到的Name值和Guid值均未改变，而通过IOptionsSnapshot方式获取到的Name值未改变，但Guid值发生了改变，每次刷新页面均会改变。这类似前面讲依赖注入时做测试的例子，现在猜测Guid未改变的IOptions和IOptionsMonitor两种方式是采用了Singleton模式，而Guid发生改变的IOptionsSnapshot方式是采用了Scoped或Transient模式。如果在这个Action中多次采用IOptionsSnapshot读取_optionsSnapshot.Get("ThemeBlue").Guid的值，会发现同一次请求的值是相同的，不同请求之间的值是不同的，也就是IOptionsSnapshot方式使采用了Scoped模式(此验证示例比较简单，请读者自行修改代码验证)。
在这样的情况下，修改三种获取方式对应的配置项的Name值，例如分别修改为“Blue1”、“Red1”和“Gray1”，再次多次刷新页面查看返回值，会发现如下情况：
IOptions方式：Name和Guid的值始终未变。Name值仍为Blue。
IOptionsSnapshot方式：Name值变为Red1，Guid值单次请求内相同，每次刷新之间不同。
IOptionsMonitor方式：只有修改配置值后第一次刷新的时候将Name值变为了Gray1，Guid未改变。之后多次刷新，这两个值均未做改变。
总结：IOptions和IOptionsMonitor两种方式采用了Singleton模式，但区别在于IOptionsMonitor会监控对应数据源的变化，如果发生了变化则更新实例的配置值，但不会重新提供新的实例。IOptionsSnapshot方式采用了Scoped模式每次请求采用同一个实例，在下一次请求的时候获取到的是一个新的实例，所以如果数据源发生了改变，会读取到新的值。先大概记一下这一的情况，在下文剖析IOptions的内部处理机制的时候就会明白为什么会这样。
4.数据更新提醒
IOptionsMonitor方式还提供了一个OnChange方法，当数据源发生改变的时候会触发它，所以如果想在这时候做点什么，可以利用这个方法实现。示例代码：
_optionsMonitor.OnChange((theme,name)=> { Console.WriteLine(theme.Name +"-"+ name); });
5.不采用Configuration配置作为数据源的方式
上面的例子都是采用了读取配置的方式，实际上Options模式和上一章的Configuration配置方式使分开的，读取配置只不过是Options模式的一种实现方式，例如可以不使用Configuration中的数据，直接通过如下代码注册：
services.Configure<Theme>("ThemeBlack", theme => { theme.Color = "#000000"; theme.Name = "Black"; });
6.ConfigureAll方法
系统提供了一个ConfigureAll方法，可以将所有对应的实例统一设置。例如如下代码：
services.ConfigureAll<Theme>(theme => { theme.Color = "#000000"; theme.Name = "Black2"; });
此时无论通过什么名称去获取Theme的实例，包括不存在对应设置的名称，获取到的值都是本次通过ConfigureAll设置的值。
7.PostConfigure和PostConfigureAll方法
这两个方法和Configure、ConfigureAll方法类似，只是它们会在Configure、ConfigureAll之后执行。
8.多个Configure、ConfigureAll、PostConfigure和PostConfigureAll的执行顺序
可以这样理解，每个Configure都是去修改一个名为其设置的名称的变量，以如下代码为例：
services.Configure<Theme>("ThemeBlack", theme => { theme.Color = "#000000"; theme.Name = "Black"; });
这条设置就是去修改(注意是修改而不是替换)一个名为"ThemeBlack"的Theme类型的变量，如果该变量不存在，则创建一个Theme实例并赋值。这样就生成了一些变量名为“空字符串、“ThemeBlue”、“ThemeBlack”的变量(只是举例，忽略空字符串作为变量名不合法的顾虑)”。
依次按照代码的顺序执行，这时候如果后面的代码中出现同名的Configure，则修改对应名称的变量的值。如果是ConfigureAll方法，则修改所有类型为Theme的变量的值。
而PostConfigure和PostConfigureAll则在Configure和ConfigureAll之后执行，即使Configure的代码写在了PostConfigure之后也是一样。
至于为什么会是这样的规则，下一节会详细介绍。
