Jenkins中`load`与`library`函数的设计原理差异探究

1. 核心定位的本质区别 #

• load 的设计初衷：作为轻量的单脚本级别动态加载工具，针对临时或自定义小脚本的执行场景。每调用一次load，会创建独立的Groovy脚本实例，返回的对象就是该实例的引用。这种设计天然支持作用域隔离——可通过不同返回对象调用同名方法，完全不会互相干扰，正好适配插件式扩展需求。
• library 的设计初衷：面向团队级稳定共享代码管理。共享库的目标是让通用流水线逻辑、工具类在所有流水线中统一复用，因此加载后会将库中全局变量、方法直接挂载到Jenkins流水线的全局作用域。为避免冲突、保证执行一致性，加载完成后的全局内容会被缓存，后续再加载同名（或含同名变量）的库也不会覆盖已加载内容——这是刻意设计的，防止不同库的同名方法互相干扰，导致流水线出现不可预期的问题。

2. 作用域与生命周期的设计逻辑 #

• load 的作用域逻辑：每次load会初始化独立的Groovy脚本上下文，脚本内的变量、方法均属于该上下文实例，外部只能通过返回对象访问，不会污染全局作用域。这种独立实例设计，就是为了支持多脚本动态加载，让你能实现插件式机制——每个加载的脚本都是独立的插件实例，同名方法各自独立运行。
• library 的作用域逻辑：共享库加载时，会将vars、src目录下的内容注入流水线的全局命名空间。其中vars下的全局变量本质是单例，加载后会被Jenkins缓存，后续调用library加载其他含同名变量的库时，Jenkins直接复用已缓存的实例，不会重新加载——这是为了兼顾性能和稳定性，避免重复加载带来的开销，同时防止动态替换导致的状态不一致。

3. 针对不同使用场景的优化 #

• 若需要动态、隔离的脚本执行（比如插件式扩展、按需加载不同逻辑的脚本），load就是为这种场景量身定做的，返回对象的机制正好满足需求。
• 若需要统一、稳定的复用代码（比如团队通用的构建步骤、工具方法），library的全局挂载和缓存机制更合适——它能确保所有流水线使用同一版本的可靠代码，不会因动态覆盖出现混乱。

关于共享库call()方法无法覆盖的补充 #

你遇到的共享库call()方法不生效的问题，本质是共享库全局变量的单例缓存机制导致的。哪怕加载不同的共享库，只要vars目录下有同名全局变量，Jenkins只会保留第一次加载的实例，后续加载不会替换——这不是bug，是刻意的设计，目的是防止意外命名冲突破坏流水线稳定性。

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