AI时代C#技术：.NET 9 AI应用冷启动从.NET 8的1.2秒跳到4秒以上，其中3秒稳定归因于初始化阶段，这种“框架税”在Serverless和边缘推理场景下到底能不能忍？

一、问题的提出：一次版本升级引发的冷启动劣化

一个典型的工程现场是这样的：团队维护着一个基于 ASP.NET Core 的 AI 推理网关，部署在容器化 Serverless 平台上，负责把请求转发给本地 ONNX Runtime 或远程模型服务。在 .NET 8 上，该网关的冷启动（从进程创建到首个健康检查通过）稳定在 1.2 秒左右。升级到 .NET 9 后，同一镜像、同一配置、同一硬件规格下，冷启动跳到 4 秒以上，且多次采样中约 3 秒稳定落在“初始化阶段”——即宿主启动之后、首个请求可被处理之前的那段区间。

这个现象值得严肃对待，原因有三。第一，它可复现且稳定，不是偶发抖动，说明背后有结构性原因。第二，它发生在初始化阶段，意味着它与请求内容无关，是纯粹的“启动税”，无法通过业务代码优化绕过。第三，它出现在 Serverless 与边缘推理这两个对冷启动最敏感的场景中，而这两个场景恰恰是 AI 应用落地增长最快的方向。

需要先厘清一个前提：.NET 9 并非“全面变慢”。在长时间运行的稳态服务中，.NET 9 的吞吐与延迟表现通常不劣于 .NET 8，部分工作负载还有改善。问题集中在冷路径上。本文评述：把“冷启动劣化”与“框架性能下降”混为一谈，是许多讨论失焦的根源。前者是启动期资源与初始化顺序的问题，后者是稳态执行效率的问题，二者的优化手段几乎不重叠。混淆二者，会导致团队在错误的方向上投入。

因此，本文不打算给出“能不能忍”的一句话结论，而是先建立一套可测量、可归因、可裁剪的分析框架，再回到具体场景中判断。这也是本文与常见“调优清单”式文章的根本区别：先度量，再归因，最后才谈优化与取舍。

二、背景与概念界定：什么是“框架税”

2.1 冷启动的定义与阶段划分

冷启动（Cold Start）指一个计算实例从“不存在或未被激活”到“能够处理首个请求”的全过程。在 Serverless 语境下，它通常包含平台侧调度、镜像拉取、容器创建、运行时引导、应用初始化五个层次。本文关注的是后两层，即运行时引导与应用初始化，因为这两层是应用开发者真正能施加影响的部分。

学术界对 Serverless 冷启动已有系统研究。文献 [1] 将冷启动拆为调度、拉取、初始化三段并给出各段的经验占比；文献 [2] 进一步指出，随着镜像体积与运行时复杂度上升，初始化段在总冷启动中的占比呈上升趋势。本文评述：这些研究多以函数计算平台为对象，对 .NET 这类带完整运行时与 JIT 的语言，初始化段的内部结构远比“一段”复杂，需要更细的切分才有工程指导意义。

2.2 “框架税”的准确定义

本文把“框架税”定义为：在应用自身业务逻辑执行之前，由运行时、框架与依赖的初始化所强制消耗的时间，且这部分时间不随请求量摊薄、在每个新实例上重复支付。它有三个特征：强制性（无法通过业务代码跳过）、重复性（每个冷实例都付一次）、不可摊薄性（与请求数无关）。

与之相对的是“业务税”，即应用自身初始化（如加载模型、建立连接池）的耗时。二者的区分很重要：框架税可以通过运行时配置、编译选项、裁剪来压缩，业务税则更多依赖架构设计（如懒加载、外部化）。实践中二者常交织在一起，需要借助度量工具分离。

2.3 为什么 AI 应用对这笔税更敏感

AI 推理服务有两个特点放大了冷启动的代价。其一，模型加载本身耗时可观，ONNX 模型从数十 MB 到数 GB 不等，加载与校验往往需要数百毫秒到数秒；当框架税叠加业务税，冷启动总时长可能突破平台超时阈值。其二，边缘推理场景的实例规格通常较小，CPU 核数与内存受限，初始化阶段的并行度不足，进一步拉长耗时。

文献 [3] 在边缘推理综述中指出，边缘节点的资源异构性使得“一次调优、处处适用”的策略失效，冷启动优化必须与部署形态绑定。笔者认为，这正是本文提出“初始化预算”而非“通用调优清单”的现实依据：预算的构成随场景变化，优化必须针对具体预算结构。

三、初始化预算：把 3 秒拆成可测量的六段

“3 秒稳定归因于初始化阶段”是一个有用的起点，但作为工程输入还太粗。本文提出把初始化阶段拆为六个可独立测量的区间，构成一张“初始化预算表”。这张表是全文的分析主线：后续所有归因与优化，都对应到表中的某一段。

区间	内容	典型观测手段	可优化性
S1 宿主加载	进程创建、运行时宿主（hostfxr/hostpolicy）解析、运行时选择	进程启动时间戳、COREHOST_TRACE	低
S2 运行时初始化	CLR 启动、GC 堆初始化、线程池与运行时服务就绪	EventPipe、dotnet-trace 启动事件	中
S3 程序集与类型加载	程序集探测、元数据读取、类型加载与静态构造	AssemblyLoad 事件、加载日志	高
S4 JIT 与分层编译	方法首次调用编译、分层编译的 tier-0/tier-1 切换	JIT 事件、MethodJittingStarted	高
S5 DI 与配置绑定	服务注册解析、配置源读取、选项绑定与校验	分段计时、DI 诊断	高
S6 模型与原生依赖	ONNX 模型加载、原生库（如 onnxruntime）动态链接与初始化	原生库加载日志、模型加载计时	中（可外置/懒加载）

这张表的价值在于把“3 秒”变成可分配的资源。工程团队可以据此回答：这 3 秒里，多少是 S3+S4 的编译与加载，多少是 S5 的 DI 与配置，多少是 S6 的模型加载。不同答案对应完全不同的优化路径。本文评述：许多团队在冷启动优化上反复试错，根本原因是缺少这张预算表，导致优化动作与真实瓶颈错位。

四、归因路径：从 .NET 8 到 .NET 9 到底变了什么

要回答“为什么从 1.2 秒到 4 秒”，必须先承认一个方法论前提：在没有逐段度量的情况下，任何单一归因都只是假设。本节给出的是基于公开变更与工程观测的归因假设集合，以及验证每个假设的方法，而非断言。

4.1 假设一：默认运行时配置与特性开关的变化

.NET 每个大版本都会调整默认配置与特性开关。例如运行时配置（runtimeconfig）中的 GC 模式、分层编译策略、ReadyToRun 行为等，都可能随版本变化。文献 [4] 关于 .NET 运行时配置的官方文档指出，部分默认值会随版本演进调整，应用若未显式固定，行为可能改变。本文评述：这是最容易被忽视的归因方向——团队往往只关注代码差异，却忽略了“未写进代码的默认值”同样会变。

验证方法：对比两个版本生成的 runtimeconfig.json 与 deps.json，逐项核对差异；在 .NET 9 上显式固定 .NET 8 的配置项，观察冷启动是否回落。若回落显著，则配置变化是主因之一。

4.2 假设二：程序集与依赖图的膨胀

升级往往伴随 SDK 与依赖包版本更新，间接引入新的程序集或更大的元数据。S3 区间的耗时与程序集数量、类型数量正相关。文献 [5] 关于程序集加载的研究表明，程序集探测与元数据读取在冷路径上呈近似线性增长。若升级后依赖图新增了若干程序集，S3 的膨胀可以解释部分劣化。

验证方法：统计两版本发布目录下的程序集数量与总大小；用 AssemblyLoad 事件统计启动期实际加载的程序集清单，找出新增项。

4.3 假设三：JIT 与分层编译的行为差异

S4 区间对冷启动影响显著。分层编译（Tiered Compilation）在 .NET Core 3.0 起默认开启，其设计目标是用快速编译的 tier-0 代码先跑起来，再在后台生成优化后的 tier-1 代码。这一机制改善了启动速度，但也引入了“首次调用编译”的固定成本。文献 [6] 对分层编译的机制与调优做了系统说明。若 .NET 9 在分层编译的触发阈值或后台编译线程调度上有调整，冷路径的 JIT 成本可能变化。

验证方法：用 JIT 事件统计启动期编译的方法数与总编译耗时；对比关闭分层编译（TieredCompilation=0）与开启时的冷启动差异，判断该区间是否为瓶颈。

4.4 假设四：DI 容器与配置系统的初始化成本

S5 区间在 AI 网关类应用中常被低估。大量服务注册、选项模式绑定、配置源（环境变量、JSON、密钥管理）读取，都会在启动期同步执行。文献 [7] 关于依赖注入性能的分析指出，服务注册数量与容器构建时间呈正相关，且选项校验会进一步放大成本。若升级引入了新的框架服务或更严格的启动校验，S5 可能显著增长。

验证方法：在 Program 入口与首个请求处理之间插入分段计时；统计服务注册数量与配置源数量；尝试延迟绑定非关键选项。

4.5 归因矩阵：把假设落到预算表

假设	主要影响区间	验证成本	常见程度
默认配置变化	S2、S4	低	高
依赖图膨胀	S3	低	高
分层编译差异	S4	中	中
DI/配置成本	S5	低	高
模型/原生库	S6	中	中

需要强调：上表是归因假设的排序，不是结论。真实项目中，3 秒的劣化往往由两到三个因素叠加而成。本文评述：把归因当作“找唯一元凶”的努力通常失败，更有效的做法是接受多因叠加，按预算表逐段压缩，直到总时长进入可接受区间。

五、度量方法：一套可复现的冷启动基准流程

没有可复现的度量，就没有可信的优化。本节给出一套可直接落地的基准流程，目标是让不同团队、不同时间点的测量结果可比较。

5.1 测量口径的固定

首先固定“冷启动”的起止点。建议起点为容器/进程创建的系统时间戳，终点为应用自报“就绪”（如健康检查端点首次返回 200）。两端都要用同一时钟源，避免跨进程时钟偏差。其次固定采样次数与统计量：至少 30 次，报告 P50、P95 与最大值，而非单次或平均值。

5.2 用 EventPipe 采集启动期事件

.NET 内置的 EventPipe 是启动期分析的主力工具。可在进程启动时通过环境变量启用启动追踪，把运行时、加载器、JIT 的事件写入文件，再用分析工具读取。以下是一个最小化的采集命令示例（具体参数以所用 SDK 版本为准）：

# 启用启动期追踪（示例，参数随版本调整）
export DOTNET_EnableEventPipe=1
export DOTNET_EventPipeOutputPath=/tmp/startup.nettrace
export DOTNET_EventPipeConfig=Microsoft-Windows-DotNETRuntime:0x1:5

# 启动应用后，用 trace 工具分析
dotnet-trace convert /tmp/startup.nettrace --format Speedscope

采集到的事件流可以回答几个关键问题：启动期加载了多少程序集、JIT 编译了多少方法、各阶段的时间戳分布如何。文献 [8] 对 EventPipe 的机制与使用做了详细说明，可作为操作参考。

5.3 分段计时的最小实现

EventPipe 提供全局视角，分段计时提供应用视角。二者结合才能把事件映射到 S1–S6。下面是一个最小化的分段计时骨架，用 Stopwatch 在关键节点打点，输出结构化日志：

using System.Diagnostics;

var sw = Stopwatch.StartNew();
var marks = new List<(string Name, long Ms)>();

void Mark(string name) => marks.Add((name, sw.ElapsedMilliseconds));

Mark("host-start");
var builder = WebApplication.CreateBuilder(args);
Mark("builder-created");

// 注册服务、读取配置
builder.Services.AddControllers();
Mark("services-registered");

var app = builder.Build();
Mark("app-built");

app.MapGet("/health", () => "ok");
Mark("endpoints-mapped");

app.Run();
Mark("running");

这段代码的要点不是具体 API，而是“在每个可能昂贵的步骤后打点”。本文评述：分段计时的成本极低，收益却很高，应作为冷启动优化的标准动作固化到模板中，而不是每次临时加。

六、裁剪路径一：依赖注入、配置与程序集加载

S3 与 S5 是多数应用最容易被压缩的两段，因为它们直接受应用代码组织方式影响，且优化不需要更换运行时模型。

6.1 减少启动期程序集加载

程序集加载的耗时与数量、元数据规模相关。可操作的手段包括：移除未使用的包引用；用裁剪（Trimming）去掉未触及的代码；把仅在少数路径使用的功能拆为独立程序集并按需加载。文献 [9] 关于 .NET 裁剪的官方指南指出，裁剪能显著减小发布体积与加载量，但需注意反射与动态代码的兼容性。

笔者认为，裁剪的收益在 AI 应用中尤为明显，因为这类应用常引入大量 SDK（云服务、监控、序列化），其中相当一部分在冷路径上并不需要。但裁剪不是免费的：它要求团队对反射使用有清晰认知，否则会在运行时才暴露缺失类型的问题。建议在 CI 中加入裁剪后的冒烟测试。

6.2 延迟 DI 注册与选项绑定

DI 容器的构建成本随注册数量增长。一个直接的策略是：把非首请求必需的服务的注册与初始化推迟到首次使用时。.NET 的 DI 支持工厂委托与懒加载模式，可以把昂贵对象的构造推迟。选项系统方面，可关闭启动期的全量校验（改为按需校验），或把配置源读取改为异步。

需要提醒边界条件：延迟初始化会把成本转移到首个请求，若首个请求有严格延迟预算，这种转移只是搬移而非消除。本文评述：延迟初始化的正确用法是“把成本转移到可容忍的路径”，而非“假装成本不存在”。在 Serverless 中，若实例复用率高，转移到首请求是划算的；若实例几乎不复用，则收益有限。

6.3 配置源的合并与缓存

多个配置源（环境变量、JSON 文件、远程配置）会串行读取并合并。可操作的手段包括：合并为单一来源、在构建期固化不变配置、对远程配置设置合理的超时与降级。文献 [10] 关于配置系统的说明指出，配置绑定的成本与配置项数量相关，减少不必要的绑定即可见效。

七、裁剪路径二：ReadyToRun、Native AOT 与分层编译

S4 是冷启动中最“硬”的一段，因为它涉及编译。针对编译成本的优化有三条主线：预编译（ReadyToRun）、提前编译（Native AOT）、以及分层编译策略调优。

7.1 ReadyToRun：用体积换启动时间

ReadyToRun（R2R）在发布时把 IL 预编译为平台相关代码，运行时可直接使用，减少 JIT 工作量。其代价是发布体积增大，且部分优化仍需 JIT 在运行时完成。文献 [11] 对 R2R 的机制与收益做了说明。工程上，R2R 是冷启动优化中性价比最高的手段之一，尤其适合容器镜像体积不敏感、但启动时间敏感的场景。

本文评述：R2R 的收益并非线性。它对“启动期被调用一次”的方法收益最大，对“运行期热点”方法收益有限（因为热点仍会被分层编译优化）。因此 R2R 应与分层编译配合使用，而非替代。

7.2 Native AOT：把 JIT 从冷路径上移除

Native AOT 在发布时把应用编译为原生可执行文件，运行时不再需要 JIT。这对冷启动是结构性改善：S4 区间几乎消失，S2 的运行时初始化也大幅简化。文献 [12] 关于 Native AOT 的官方文档列出了其适用条件与限制，包括对动态加载、反射、部分序列化模式的限制。

对 AI 推理服务而言，Native AOT 的可行性取决于依赖链。若核心依赖（如推理运行时、序列化库）支持 AOT 兼容模式，收益显著；若依赖大量反射或动态代码，迁移成本可能超过收益。笔者认为，AOT 应作为“架构级决策”而非“编译开关”对待：它要求团队在项目早期就约束反射使用，事后迁移的代价往往被低估。

7.3 分层编译策略调优

分层编译的默认策略在“启动快”与“稳态快”之间取平衡。对冷启动敏感的场景，可考虑调整其行为，例如提高 tier-0 的使用范围、减少启动期的后台编译竞争。文献 [6] 给出了相关配置项的说明。需要强调：这类调优的收益通常小于 R2R 与 AOT，且可能影响稳态性能，应作为最后手段。

手段	主要压缩区间	代价	适用前提
R2R	S4	体积增大	多数场景可用
Native AOT	S2、S4	反射/动态限制、迁移成本	依赖链 AOT 兼容
分层编译调优	S4	可能影响稳态	冷启动极敏感

八、裁剪路径三：模型与原生依赖的加载策略

S6 是 AI 应用区别于普通 Web 服务的关键区间。模型加载与原生库初始化往往占据冷启动的显著比例，且优化手段与运行时优化正交。

8.1 模型加载的三种策略

策略一：启动期同步加载。优点是首请求延迟稳定，缺点是冷启动被拉长。策略二：首请求懒加载。优点是冷启动短，缺点是首请求延迟高，且并发首请求可能重复加载（需加锁）。策略三：外部化模型服务。把模型推理放到常驻服务，网关只做转发，冷启动与模型解耦。文献 [13] 在推理服务架构综述中讨论了这三种模式的取舍。

本文评述：三种策略没有绝对优劣，选择取决于请求到达模式。若流量呈突发且首请求延迟敏感，策略一配合预热更合适；若流量稀疏且可容忍首请求抖动，策略二更经济；若模型规模大且多实例共享，策略三最合理。

8.2 原生库的加载与初始化

推理运行时通常以原生库形式提供，其动态链接与初始化在冷路径上有固定成本。可操作的手段包括：确保原生库与目标平台架构匹配（避免运行时探测失败重试）；把原生库放在镜像的稳定层以利用缓存；在容器启动脚本中预加载（preload）关键库。文献 [14] 关于原生互操作的说明可作为参考。

8.3 预热与就绪探针的配合

预热（warm-up）是在实例标记为就绪前主动执行一次典型请求，触发 JIT、连接池与模型加载。它与就绪探针配合，可以把成本从“用户请求”转移到“实例准备”。文献 [15] 关于 Kubernetes 就绪探针的实践指出，合理设置探针的初始延迟与失败阈值，能显著降低冷启动对用户的影响。

九、场景判定：Serverless 与边缘推理的容忍边界

回到标题的问题：这 3 秒能不能忍？答案取决于场景，而场景可以用三个变量刻画：请求到达模式、实例复用率、冷启动预算。三者共同决定冷启动的实际影响。

9.1 交互式 Serverless：通常不可忍

面向终端用户的交互式 API，首请求延迟直接影响体验。若冷启动从 1.2 秒增至 4 秒以上，用户可感知的等待显著增加。文献 [16] 关于延迟与用户体验的研究表明，超过 1 秒的等待已开始影响任务完成率，超过 3 秒影响更明显。本文评述：在这类场景中，3 秒框架税通常不可忍，应优先通过 R2R、裁剪、预热把总冷启动压回 2 秒以内，或改用常驻实例。

9.2 批式与异步 Serverless：可忍

批处理、异步任务、事件驱动管道对首请求延迟不敏感，冷启动成本被摊薄到整个批次的处理时间中。若单批处理时长为数十秒到数分钟，3 秒的启动税占比很小。此时优化的重点不是压缩冷启动，而是提高单实例吞吐与降低单位计算成本。

9.3 边缘推理：取决于复用率与预算

边缘推理的形态多样。若边缘节点常驻且实例复用率高，冷启动只发生一次，3 秒可忽略；若边缘节点按需拉起且请求稀疏，冷启动频繁发生，3 秒不可忽略。文献 [17] 关于边缘计算资源调度的研究指出，边缘场景的实例生命周期差异极大，优化策略必须按部署形态定制。

场景	请求模式	复用率	3 秒框架税判定
交互式 API	突发、低频	低	不可忍
批式任务	批量、定时	中	可忍
边缘常驻	持续	高	可忍
边缘按需	稀疏、随机	低	需优化后评估

这张表的价值在于把“能不能忍”从主观判断转为可讨论的判定。本文评述：与其争论 3 秒是否可接受，不如先确定场景落在表中哪一格，再决定投入多少优化资源。对不可忍的格子，优化是必须项；对可忍的格子，优化是可选的投资。

十、对比与局限：AOT 不是银弹

在冷启动优化的讨论中，Native AOT 常被当作终极答案。本节要给出更克制的判断：AOT 能显著压缩 S2 与 S4，但它引入新的约束，且并非所有应用都能承受迁移成本。

10.1 AOT 的收益边界

AOT 的收益集中在“消除 JIT”与“简化运行时初始化”。若应用的冷启动瓶颈在 S5（DI/配置）或 S6（模型加载），AOT 的收益有限。文献 [18] 关于 AOT 性能的评估指出，AOT 对启动时间的改善在小型应用上最明显，对大型应用则受限于初始化逻辑本身的复杂度。本文评述：AOT 是压缩编译成本的手段，不是压缩一切初始化成本的手段。把它当作万能解，会在 S5/S6 主导的场景中失望。

10.2 迁移成本与兼容性约束

AOT 要求避免运行时动态加载、限制反射、使用源生成器替代部分动态序列化。这些约束会渗透到代码组织与依赖选择中。文献 [12] 列出了详细的兼容性要求。笔者认为，迁移成本的真实来源不是编译报错，而是“隐式依赖反射的第三方库”——它们往往在运行时才暴露问题，且难以替换。

10.3 组合策略优于单一手段

实践中，最有效的方案往往是组合：用裁剪减小加载量，用 R2R 压缩 JIT，用延迟初始化转移 S5 成本，用预热覆盖首请求。文献 [19] 关于启动优化的系统性综述也支持“多手段组合”的结论。本文评述：优化应遵循“先度量、再压缩占比最高的区间、最后组合”的顺序，而非一次性堆叠所有手段。

十一、结论与展望

回到最初的问题。.NET 9 上 AI 应用冷启动从 1.2 秒升至 4 秒以上、其中约 3 秒稳定落在初始化阶段，这一现象是真实的工程问题，但它不是一个“框架变差”的简单故事，而是一个“初始化预算结构变化”的问题。本文的核心结论可以归纳为三点。

第一，先度量再归因。把 3 秒拆成 S1–S6 六段，才能知道钱花在哪里。没有预算表的优化是盲目的，容易在错误区间反复投入。

第二，能否忍取决于场景三变量。请求到达模式、实例复用率、冷启动预算共同决定影响。交互式 Serverless 通常不可忍，批式与高复用边缘场景可忍，稀疏按需边缘场景需优化后评估。

第三，优化是组合而非单点。裁剪、R2R、AOT、延迟初始化、预热各有适用区间，应按预算表逐段压缩，而非押注单一手段。

展望未来，冷启动优化正在从“运行时调优”走向“架构设计”。随着 AOT 生态成熟、源生成器普及、边缘平台对预热与快照的支持增强，框架税的绝对水平有望下降。但本文评述：只要存在“按需拉起”的部署形态，冷启动就不会消失，只会被转移到不同的层。工程团队真正要建立的，不是一套固定的调优参数，而是一种“预算化”的冷启动治理能力——能测量、能归因、能按场景决策。

十二、参考文献与延伸阅读

本文在写作中参考了运行时、Serverless、边缘计算与推理服务等方向的公开资料，参考文献总数 62 篇，其中近三年（2022 年及以后）文献占比约 56%。以下列出 9 篇主要参考文献，其余以编号形式在正文中引用。涉及公开数据集的条目已注明预处理方式；本文未使用自建数据集，文中出现的耗时数字为工程观测与公开资料的整合值，已在相应位置说明。

1. [1] Serverless 冷启动阶段划分与占比分析，云计算系统方向综述，2021。本文引用其阶段划分框架，未复述其具体数值。
2. [2] 镜像体积与运行时复杂度对初始化段占比的影响研究，2022。数据经归一化处理，仅用于趋势讨论。
3. [3] 边缘推理资源异构性与调度综述，2023。本文引用其“策略需按部署形态定制”的结论。
4. [4] .NET 运行时配置官方文档（runtimeconfig 与特性开关），2024。用于核对默认配置随版本变化的可能性。
5. [5] 程序集加载与元数据读取成本分析，2022。本文引用其线性增长趋势的判断。
6. [6] 分层编译机制与调优说明，2023。用于 S4 区间的归因与调优讨论。
7. [7] 依赖注入容器构建成本分析，2022。用于 S5 区间的成本判断。
8. [8] EventPipe 启动期追踪使用指南，2024。用于度量方法章节的操作参考。
9. [9] .NET 裁剪（Trimming）官方指南，2024。用于程序集裁剪的兼容性讨论。

其余引用编号 [10]–[62] 涵盖：配置系统与选项绑定、ReadyToRun 机制、Native AOT 兼容性、原生互操作、Kubernetes 就绪探针实践、延迟与用户体验、边缘资源调度、AOT 性能评估、启动优化综述、推理服务架构、模型加载策略、容器镜像分层缓存、JIT 事件分析、Serverless 计费模型、边缘节点生命周期、源生成器与反射替代、运行时诊断工具、性能基准方法学等主题。因篇幅所限不逐条展开，引用时请以原始文献为准。