Helm全局值为何被频繁推荐？与YAML引用对比探讨

在编程语言里，全局变量曾是组件间共享状态的早期方案，但如今多数现代语言都限制其使用，开发者只会谨慎使用（注：全局变量多遭规避，全局常量用途有限，Helm全局值的用途更偏向全局常量）。但在Helm模板中，全局值是教程常提及的重要选项，却少见谨慎使用的建议。

我认为，当多Chart需要共享值时，依赖Helm全局值相比YAML引用没有明显优势：全局值会让库Chart的依赖关系变得不透明，得遍历所有子Chart才能知道哪些Chart在用这个值，而YAML引用在values文件里一目了然；而且修改全局值调整子Chart时，可能会因为其他子Chart依赖原有定义而受到限制。

我总结了两种方案的核心特点：

全局值 #

• 可在多Chart间共享值，仅需在父Chart的values文件中设置一次
• 要求所有使用该值的Chart对定义达成一致
• 修改全局值影响某一子Chart时，可能对其他子Chart造成意外影响
• 分散了影响同一子Chart的配置项位置
• 可“强制”多Chart使用同一值
• 但可能与其他Chart冲突，部分Chart可能为图方便使用同一全局值，即便并非始终需要相同值

YAML引用 #

• 可在多Chart间共享值，仅需在父Chart的values文件中定义一次，但需为每个子Chart添加引用
• 各Chart的值定义相互独立
• 修改单个子Chart的值简单直接，且不会影响其他子Chart
• 影响同一子Chart的所有配置项集中管理（至少可通过引用找到原始定义）
• 支持多Chart使用同一值，但多Chart作者无法强制父Chart为不同Chart的同一属性设置相同值
• 各Chart相互隔离

我的疑问是：是否遗漏了Helm全局值的某些优势或适用场景？尤其是和YAML引用对比时，或是存在更适合全局值的其他场景？

我的使用场景：维护少量库Chart（几个），部分用于自有部署，部分封装外部工具，也会使用第三方Chart；单个父Chart通常包含不超过10个子Chart，当前需共享的内容为标签和名称片段，既可用全局值也可用YAML引用。

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