我给一个公共库里的方法把可选参数的默认超时从 30 秒改成了 60 秒、只重新编译发布了这个库的 dll、本以为所有调用方不用动就自动用上新默认值,结果线上一查那些没重新编译的调用方还在用 30 秒的旧默认,排查很久才搞懂 C# 里可选参数的默认值是编译时常量、早被内联进了调用方的程序集里的深度复盘

这次踩的坑,颠覆了我一个根深蒂固的直觉:"我改了库里的默认值,用这个库的人当然就用上新值了"。可 C# 用一个我没注意的细节告诉我——那个默认值,根本不在库里,它早就被复制到调用方那边去了。

故障现场:改了库的默认值,调用方却没变

我维护一个被很多服务依赖的公共库,里面有个方法,带一个可选参数(默认超时):

// 公共库 MyLib 里的方法
public static class HttpHelper {
    public static Response Send(Request req, int timeoutSeconds = 30) {  // 默认 30
        // ... 用 timeoutSeconds 发请求
    }
}
// 调用方本来这么调(没传 timeout, 用默认):
var resp = HttpHelper.Send(req);   // 期望用默认超时

后来发现 30 秒超时太短,我把库里的默认值改成了 60 秒,重新编译、发布了这个库的新版 dll。我以为:所有调用 Send(req) 的地方,不用改任何代码、甚至不用重新编译,只要换上新 dll,就自动用上 60 秒了。可上线后:

• 有的调用方变了,有的没变:重新编译过的那些服务,确实用上了 60 秒;可只是替换了库 dll、自己没重新编译的那些服务,还在用 30 秒!
• 库里明明写的是 60:我反编译那些"没变"的服务,发现它们调用处赫然写着 Send(req, 30)——那个 30 不知怎么被硬塞进了调用方的代码里,根本没去读库里的 60。
• 显式传参的都正常:凡是调用时显式传了 timeout(如 Send(req, 45))的,都按传的值,没问题——只有用默认值的才出岔子。
• 重新编译一下就对了:我把那些没变的服务重新编译一遍,它们就用上 60 秒了。

"改了库的默认值,只换 dll 不重编的调用方不生效、调用处被塞进了旧的 30、重编就好"——这几条合起来,指向一个我从没想过的事实:那个 30(可选参数的默认值),不是在运行时从库里读的,而是在调用方编译的那一刻,就被"复制"进了调用方自己的程序集里;库里改成 60,调用方那份复制的 30 纹丝不动。我得去搞清楚,C# 的可选参数默认值,到底是怎么工作的。

第一件事:搞懂可选参数默认值是编译时常量,在调用点被内联进调用方

带着"默认值被复制进了调用方"这条线去查 C# 的规范,我才算真正理解了一件天天用却从没深究的事——C# 里可选参数的默认值,是一个编译时常量;当编译器编译调用方的代码时,如果调用处省略了这个可选参数,编译器会把那个默认值直接"填"到调用点,生成的就好像你显式写了那个默认值一样。

也就是说:

• 我写 HttpHelper.Send(req)(省略 timeout);
• 编译器在编译我的代码(调用方)时,去看 Send 的定义、发现 timeout 默认 30,于是把调用编译成了 HttpHelper.Send(req, 30)——那个 30 被烤进了我的程序集;
• 所以运行时,我的程序集里调用的就是 Send(req, 30),它压根不会去问库现在的默认值是多少;
• 当库把默认值改成 60、只更新库的 dll、而我没重新编译时,我程序集里那个烤死的 30 还在,自然还用 30。

关键的认知是:可选参数的默认值,不是被调用方(库)在运行时提供的,而是由调用方在编译时"嵌入"自己代码里的;它是一种编译时绑定,而非运行时绑定。这就解释了为什么"改库不重编调用方"不生效——默认值这个"约定",在调用方编译那一刻就已经固化进了调用方,后续改库,改的只是库里那个"源定义",而调用方早已带着自己那份复制品跑路了。我把这个编译期内联看清楚:

// 库:Send(Request req, int timeoutSeconds = 30)
// 调用方源码:
HttpHelper.Send(req);

// 编译调用方后, IL 里实际生成的(默认值被内联进来):
HttpHelper.Send(req, 30);   // 这个 30 来自编译时, 烤进了调用方程序集!

// 库后来改成 = 60 并只更新库 dll:
//   - 重编了的调用方: 重新内联, 变成 Send(req, 60)  ✅ 用新值
//   - 没重编的调用方: IL 里还是 Send(req, 30)        ❌ 还用旧值

真相大白:不是 dll 没更新,而是可选参数的默认值是编译时常量、在调用方编译时就被内联进了调用方的程序集;我改库里的默认值,只改了"源头的定义",改不动早已被各个调用方复制并固化的那些旧默认值——除非这些调用方重新编译。这是一种典型的"编译时绑定"行为,而我误以为它是"运行时去库里读"的。

第二件事:正解——想运行时可改的默认值,用重载在被调用方运行时决定

根因是"可选参数默认值是编译时常量、内联进调用方",那正解的核心就一句话:如果你希望"改默认值、调用方不重编就生效",就别把默认值放在可选参数上,而要用方法重载——让默认行为在被调用方(库)运行时决定。

// ❌ 可选参数默认值:编译时内联进调用方, 改了不重编不生效
// public static Response Send(Request req, int timeoutSeconds = 30) { ... }

// ✅ 正解:用重载, 无参版本在"库运行时"补默认, 改库即生效
public static Response Send(Request req) {
    return Send(req, DefaultTimeout);     // 默认值在库运行时取, 不内联到调用方
}
public static Response Send(Request req, int timeoutSeconds) {
    // ... 真正的实现
}
private const int DefaultTimeout = 60;    // 改这里, 调用方不重编也跟着变
// 调用方 Send(req) 调的是无参重载, 运行时才进库里拿默认值 -> 改库即生效

区别的关键在于"默认值在哪里、何时被决定":可选参数默认值是在调用方编译时被填进调用方;而方法重载里,无参版本只是转调有参版本并补上默认,这个"补默认"的动作发生在库的代码内部、运行时执行——调用方调的是那个无参重载,它运行时才进到库里去拿默认值,所以改库就生效。

另外的判断:如果默认值是一个稳定、几乎不会变的契约(比如 StringComparison.Ordinal),用可选参数没问题、更简洁;但如果它是一个你预期将来可能调整、且希望调整后所有使用方都自动跟进的值,就别用可选参数默认值,改用重载(或从配置读)。核心就一条:分清这个默认值是"编译时固化的常量"还是"运行时可变的策略",按需选可选参数还是重载。

第三件事:同一类"以为改源头就生效、其实使用方早把它复制固化了"的坑,我后来又撞见好几个

这次踩坑让我警觉起一类隐蔽的坑:有些值/定义,看起来是"放在源头、大家去引用"的,可实际上,使用方在某个时刻(编译、构建、首次读取)把它复制了一份固化在自己这边;之后你改源头,使用方那份复制品不会自动更新,你以为改了源头大家就变了,其实没有。这种坑不止可选参数:

• 编译进调用方的常量 const:C#/Java 里 public const(编译时常量)被内联进引用方,改了常量值不重编引用方不生效——要用 static readonly(运行时读)。
• 构建时打进产物的环境变量/配置:前端构建时把环境变量打进 bundle,改了环境变量不重新构建不生效。
• 客户端缓存了的配置/版本:客户端首次拉取后缓存了配置,服务端改了配置,没刷新缓存的客户端还用旧的。
• DNS/连接缓存了旧地址:改了 DNS 解析,可缓存了旧 IP 的一方还连旧地址。
• 快照/副本数据没跟源更新:从主数据做了快照/物化视图/冗余副本,源数据改了,快照不刷新就一直是旧的。

它们的内核是同一个:当一个值从"源头"被复制到"使用方"那里(无论是编译内联、构建打包、缓存、快照),"源头"和"使用方那份副本"就解耦了;此后改源头,只改了源头那一份,使用方手里的副本是独立的、不会自动同步的;你以为的"一处定义、处处引用、改一处全变",实际是"一处定义、处处复制、改源头副本不变"。所以,面对任何"改了某个定义/值、期望使用方跟着变"的场景,都要先问:使用方是运行时实时去读源头,还是早把它复制固化在自己这边了?如果是后者,改源头之后还得让使用方重新复制(重编、重建、刷缓存、刷快照)才生效。我把这套判断画成了一张图(见后文)。

第四件事:可选参数默认值 vs 重载 vs 配置——一张对照表

这次事故逼我把"默认值放哪里、何时决定"的几种方式摆成一张表,以后定默认行为前先对照:

看清这张表,选择就有了准绳:默认值是稳定不变的契约,用可选参数/const 简洁就好;默认值预期将来要改、且希望改后所有使用方自动跟进,就用重载、static readonly 或配置——让默认值在运行时、被调用方那边决定,而不是编译时烤进使用方。

第五件事:我曾经对可选参数默认值想当然的几个误区

这场"改库默认值不生效"的事故,把我对可选参数和默认值的一堆想当然照得清清楚楚:

这些误区的根子是同一个:我默认"定义在一处、被别处引用"的东西,就是别处运行时实时去那一处读取的;我完全没意识到,有些"引用"其实是编译时的一次性复制——使用方在编译那一刻,把源头的值抄了一份固化进自己,之后就各过各的了。正因为我把"编译时复制"误当成了"运行时引用",我才会以为"改了源头、别处自动跟着变"。把"编译时被复制固化"的东西,误当成"运行时实时引用"的,以为改源头使用方就自动更新,是这类"改了不生效"问题的共同根源。

第六件事:定默认值/共享常量、排查"改了不生效"时,我现在的自检习惯

现在每当我给库定可选参数默认值或共享常量、或排查"改了源头使用方却没变",我都会先问"这个值是编译时被复制走的,还是运行时去读的"。先看清可选参数默认值为什么改了不生效:

然后用这张自检图决定默认值/常量放哪、怎么改:

配套地,我把"可变默认值用重载、稳定常量才用 const"固化成了写库的规范:

// 规范:预期会变的默认值用重载(运行时在库里决定), 不用可选参数默认值
public static class HttpHelper {
    private static readonly int DefaultTimeout = 60;   // 运行时读, 改它即生效
    public static Response Send(Request req) => Send(req, DefaultTimeout);  // 重载补默认
    public static Response Send(Request req, int timeoutSeconds) { /* 实现 */ }
}
// 对比: const(编译时常量)会被内联进引用方, 改了要重编引用方;
//       static readonly(运行时读)改了引用方不重编也生效。
// 经验: 跨程序集共享、且可能变的值, 优先 static readonly / 重载 / 配置, 慎用 const 和可选参数默认值

这套习惯的精髓,是"定默认值/常量先问它是编译时被复制走的还是运行时读的、预期会变的用重载/static readonly/配置让运行时在库这边决定、排查改了不生效先分清编译时复制还是运行时引用"。它让我从"改了库默认值大家就跟着变"的想当然,变成了"分清编译时绑定还是运行时绑定"——核心始终是:在 C# 中可选参数的默认值是一个编译时常量、当编译器编译调用方代码时如果调用处省略了这个可选参数编译器会把那个默认值直接填到调用点、生成的 IL 就好像你显式写了那个默认值一样、即这个默认值在调用方编译的那一刻就被内联复制进了调用方自己的程序集而不是运行时从被调用方库里读取(这是一种编译时绑定);所以当你改了库里某方法可选参数的默认值并只重新编译发布了库的 dll 时只有重新编译过的调用方会重新内联用上新默认值、而那些只替换了库 dll 但自己没重新编译的调用方其 IL 里还是早先烤进去的旧默认值不会跟着变(显式传参的不受影响因为没用默认值);public const 编译时常量同理会被内联进引用方改了不重编不生效;正解是如果你希望改默认值后调用方不重新编译就能生效就别把默认值放在可选参数上而要用方法重载——提供一个无参重载在其内部转调有参版本并补上默认值、这个补默认的动作发生在库的代码内部运行时执行所以调用方调无参重载时运行时才进库拿默认值改库即生效、或用 static readonly 字段(运行时读)、或从配置读;判断依据是这个默认值是稳定几乎不变的契约(用可选参数/const 简洁就好)还是预期将来会调整且希望调整后所有使用方自动跟进的值(用重载/static readonly/配置);更一般地很多看起来是放在源头供大家引用的值或定义其实被使用方在某个时刻(编译内联、构建打包、缓存、快照)复制了一份固化在自己这边、此后改源头使用方那份独立的副本不会自动更新(编译进调用方的 const、构建时打进 bundle 的环境变量、客户端缓存的配置、DNS 缓存的旧 IP、从源做的快照物化视图冗余副本),你以为的一处定义处处引用改一处全变实际是一处定义处处复制改源头副本不变,所以面对任何改了某定义却期望使用方跟着变的场景都要先问使用方是运行时实时去读源头还是早把它复制固化在自己这边了如果是后者改源头之后还得让使用方重新复制(重编重建刷缓存刷快照)才生效。

我立下的几条规矩

这场"改库默认值不生效"的事故,换来了我写库定默认值时,刻进骨子里的几条铁律:

1. 可选参数默认值是编译时常量,内联进调用方,不是运行时读库。
2. 改库的可选参数默认值,没重编的调用方还用烤进去的旧值。
3. 预期会变、想让使用方自动跟进的默认值,用方法重载。
4. 跨程序集共享且可能变的值,用 static readonly 而非 const。
5. 稳定不变的契约才用可选参数默认值/const,图它简洁。
6. 分清值是编译时被复制还是运行时去读,定绑定方式。
7. 改源头不生效,先查使用方是不是早把它复制固化了。

附:一段可选参数默认值 vs 重载的对照与验证

最后留一段我自己整改时照着改的对照代码与验证思路:

// ❌ 可选参数默认值:编译时内联进调用方, 改库不重编调用方不生效
public static Response Send(Request req, int timeoutSeconds = 30) { /*...*/ }
//   调用方 Send(req) 被编译成 Send(req, 30), 30 烤进调用方程序集

// ✅ 重载:无参版本运行时在库里补默认, 改库即生效
private static readonly int DefaultTimeout = 60;  // 改这里, 调用方不重编也变
public static Response Send(Request req) => Send(req, DefaultTimeout);
public static Response Send(Request req, int timeoutSeconds) { /*...*/ }

// 同理: const vs static readonly
public const int MaxConst = 100;          // ❌ 内联进引用方, 改了要重编引用方
public static readonly int MaxRO = 100;   // ✅ 运行时读, 改了引用方不重编也生效

/* 验证"是否被内联进调用方"的办法:
 * 1. 反编译调用方程序集(ILSpy/dnSpy)看调用处, 默认值若以字面量出现 -> 被内联了
 * 2. 只更新库 dll、不重编调用方, 跑一遍看默认行为有没有变:
 *    - 没变 -> 编译时绑定(可选参数默认值 / const), 需重编调用方
 *    - 变了 -> 运行时绑定(重载 / static readonly / 配置)
 */

这段对照的核心就一句:可选参数默认值和 const 是编译时常量、会被内联进使用方,改了要重编使用方才生效;预期会变、想让使用方自动跟进的值,用重载 / static readonly / 配置,让它在运行时于库这边决定。把"可变默认值塞进可选参数"换成"用重载在运行时补默认",那"改了库却一半调用方没变"的怪事就不会再有了。

写在最后

回头看,这场由"可选参数默认值是编译时常量"引发的"改库不生效"事故,真正教给我的,远不止"用重载代替可选参数默认值"这一个技巧。它让我对"'引用一个东西'这件事,其实暗藏着两种截然不同的关系:一种是'运行时实时去那一处读'(改源头立刻跟着变),另一种是'某一刻把它复制一份揣在自己兜里'(改源头我兜里那份纹丝不动);我们常常把后者,误以为是前者",有了一次刻骨的体会。我栽跟头,是因为我把"调用方用了库里的默认值"这件事,想象成了一种运行时的、活的引用——仿佛调用方每次执行,都会跑到库里去问一句"现在默认值是多少?";于是我笃定,我只要改了库里那一处的答案,所有来问的人下次问到的就是新答案;可现实是,这个"引用"根本不是运行时去问的——它是在调用方编译的那一刻,编译器替调用方问了一次、把答案抄了下来、烤进了调用方的代码里;此后调用方运行时再也不去问了,它只认当年抄下来的那个答案;我改了库里的答案,可那些没重新"抄一遍"(重新编译)的调用方,手里攥的还是旧答案。这让我领悟到一个关于"引用与复制"的深刻认知:当一个值从"定义它的地方"传递到"使用它的地方",中间存在两种本质不同的机制:引用(reference)——使用方保留一个"去哪里取"的指引,每次用时实时去源头取,所以源头一变它就变;复制(copy / snapshot)——在某个时刻把值取出来拷一份留在使用方身边,之后使用方只看自己这份,源头再变也与它无关;这两种机制在"使用"时看起来一模一样(都能拿到值),却在"源头改变"时天差地别:引用会同步,复制不会;而要命的是,很多"复制"行为是隐式发生的——编译时的常量内联、构建时的打包、首次访问时的缓存、生成时的快照——它们悄悄地把"引用"变成了"复制",而我们的心智模型却还停留在"引用",于是当我们改了源头、满心以为大家都会跟着变时,那些手握复制品的使用方,纹丝不动;所以,面对任何"一处定义、多处使用"的值,我都要追问一句:使用方对它,究竟是实时引用还是留了份复制?如果是复制,那"改源头"就远远不够,还得想办法让每一份复制品重新同步。这给了我一种面对"一切'改了某处、期望它处跟着变'之事"时的清醒:每当我改一个被多处使用的值/定义、并期望使用方跟着变,我都会先问"使用方是运行时实时读我这里,还是早把我这个值复制固化在它那边了?如果是后者,光改我这里没用,得让它重新复制(重编/重建/刷缓存/刷快照)"——分清引用还是复制、改源头后让所有复制品重新同步;"分清运行时引用与编译时复制、对复制品要主动重新同步",是用对 C# 可选参数、也是管理一切跨边界共享值的关键。认清可选参数默认值是编译时常量内联进调用方、要可变就用重载、分清编译时绑定与运行时绑定——这,是我用一次"改了库的默认值、一半调用方却没变"的事故,换来的、关于 C#、也关于引用与复制之别的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次给库定一个将来可能会改的默认值时,选择用重载而不是可选参数默认值、或至少记得"改了得让所有调用方重编才生效",那我对着那一半"换了 dll 却还是旧默认"的服务排查的那阵懵,就值了。

—— 别看了 · 2026