在构建需要频繁变更业务规则的系统时，把规则从编译后的程序集中剥离出来，以脚本形式加载执行，是降低发布成本的有效手段。.NET 从 4.0 开始引入的动态语言运行时（Dynamic Language Runtime，简称 DLR）位于公共语言运行时之上，为动态类型语言提供了统一的寄宿和执行环境。借助 DLR，开发者可以用 C# 或 VB.NET 编写宿主程序，而在运行时载入 Python、Ruby 等动态语言写成的脚本，实现逻辑热插拔。
DLR 的核心机制与脚本宿主搭建
DLR 的本质是一组位于 System.Dynamic 命名空间下的类型与运行时服务。它包含三个关键部分：表达式树共享、动态分发缓存以及语言绑定器。当脚本访问一个 .NET 对象时，DLR 不会每次都走昂贵的反射，而是将调用编译成 Lambda 表达式并缓存，后续同签名调用直接执行委托，性能接近静态代码。动态分发缓存以调用站点（CallSite）为核心，每个动态操作对应一个站点，站点记住了之前解析出的目标方法。
要在 .NET 程序中应用 DLR，最常见的方式是引用 IronPython 这类基于 DLR 实现的动态语言引擎。下面代码展示了一个最小宿主：创建 ScriptRuntime，获取 Python 引擎，并执行一段简单脚本，同时将宿主中的一个静态方法暴露给脚本使用。
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
public class HostApi
{
public static int Add(int a, int b)
{
return a + b;
}
}
class Program
{
static void Main()
{
ScriptRuntime runtime = Python.CreateRuntime();
ScriptEngine engine = runtime.GetEngine("python");
ScriptScope scope = engine.CreateScope();
// 将 .NET 类型注入脚本环境
scope.SetVariable("HostApi", typeof(HostApi));
string code = "result = HostApi.Add(3, 4)nprint(result)";
ScriptSource source = engine.CreateScriptSourceFromString(code);
source.Execute(scope);
Console.WriteLine(scope.GetVariable("result"));
}
}
上述代码中，ScriptRuntime 是 DLR 提供的顶层对象，管理所有语言引擎与共享状态；ScriptScope 相当于脚本的全局命名空间，通过 SetVariable 可以把任意 .NET 对象或类型传递给脚本。这种机制让脚本不仅能调用静态方法，也能实例化 .NET 类、订阅事件、操作集合，和宿主程序深度交互。
从工程角度看，DLR 宿主搭建成本很低。只需要引入对应语言包（如 IronPython 的 NuGet 包），无需额外服务进程。不过需要注意，DLR 脚本默认拥有与宿主相同的权限上下文，因此在加载外部脚本时应配合沙箱或代码访问安全策略，避免脚本执行危险操作。
在规则引擎与插件系统中的实战模式
脚本场景的典型落地之一是规则引擎。假设电商系统需要根据运营配置计算订单折扣，若把规则写死在 C# 里，每次改规则都要重新发版。使用 DLR 后，运营人员编写的 Python 片段可以直接存入数据库，系统在订单创建时拉取并执行。下面的例子演示脚本如何读取订单对象并输出折扣率。
# 脚本输入变量 order 由宿主注入
def calc_discount(order):
if order.total > 1000:
return 0.8
elif order.total > 500:
return 0.9
return 1.0
discount = calc_discount(order)
在宿主侧，我们需要将订单实体传入作用域。由于 DLR 支持动态绑定，脚本里访问 order.total 时，DLR 会自动匹配 C# 对象的属性，无需任何序列化。这种无缝互操作显著降低了系统复杂度。当规则数量膨胀时，还可以为每个规则创建独立 ScriptScope，避免变量污染。
插件系统则是另一类常见场景。传统插件用反射加载程序集，容易遇到版本冲突。基于 DLR 的脚本插件不依赖编译，只需约定一组接口对象注入作用域，插件脚本实现对应函数即可。宿主在启动时扫描脚本目录，逐个执行并收集返回的插件描述。这种模式的优势是插件可以用非 C# 语言编写，降低扩展门槛，也方便非专业开发者参与。
当然，脚本方案也有代价。DLR 首次执行某调用站点会有编译开销，高并发下建议预热常用脚本。此外，脚本错误只能在运行时发现，因此宿主必须捕获 ScriptEngine 抛出的异常，并记录详细堆栈，否则排错会非常困难。
DLR 与 Roslyn 脚本的对比及选型建议
提到 .NET 动态执行，很多团队也会考虑 Roslyn 提供的 C# 脚本引擎（Microsoft.CodeAnalysis.CSharp.Scripting）。两者定位不同：DLR 面向多动态语言统一运行时，强调语言互操作；Roslyn 脚本则是 C# 代码片段的原生编译执行，类型安全更好。下面从几个维度做对比。
| 维度 | DLR (IronPython) | Roslyn C# Script |
|---|---|---|
| 语言支持 | Python、Ruby 等 | 仅 C# |
| 类型检查 | 运行时动态 | 编译期静态 |
| 与 .NET 互操作 | 动态绑定，无需转换 | 直接引用程序集 |
| 启动开销 | 较低，解释+缓存 | 较高，需编译 |
如果业务方希望用接近自然语言的脚本来配置策略，且团队成员熟悉 Python，DLR 是更顺手的选择。Roslyn 则适合需要严格类型约束、脚本即 C# 片段的内部工具。性能方面，Roslyn 在长脚本、复杂计算上通常更快，因为生成的是优化后的 IL；DLR 在大量短小脚本、频繁创建作用域时更轻量。
选型时还应考虑维护成本。DLR 生态相对静止，IronPython 目前主要维护在 2.7 和 3.x 的社区分支，对最新 .NET Core 的支持需验证。Roslyn 作为官方编译器组件，与 .NET 版本同步更新。若项目已全面转向 .NET 6 以上且要求长期支持，建议先评估 IronPython 的兼容包；若无法保证，可用 Roslyn 替代部分脚本需求，或采用两者混合架构：用 DLR 处理外部动态语言脚本，用 Roslyn 处理内部 C# 规则片段。
综合来看，DLR 在脚本场景下的价值在于“多语言 + 低门槛 + 热更新”。只要控制好安全边界与异常隔离，它依然是企业应用中值得保留的动态能力方案。
DLR IronPython 动态脚本修改时间：2026-08-16 06:42:15