文章反对GitHub Actions支持YAML锚点功能，认为这会增加复杂性且无实际益处，反而使CI/CD流程更难以理解和分析，进一步强化了该平台默认不安全的特性。

文章标题：致GitHub：请勿支持YAML锚点

核心观点：

作者强烈反对GitHub Actions新增对YAML锚点（YAML anchors）的支持，认为这一功能存在三大问题： 1. 冗余性：现有机制（如工作流级env）已能实现配置复用，锚点反而模糊了工作流、任务和步骤的抽象层级。 2. 非局部性与复杂性：锚点引入的跨文件引用会降低人类和机器对工作流的理解与分析能力，破坏YAML的一对一对象模型假设。 3. 功能残缺：GitHub未支持锚点唯一有价值的场景——合并键（merge keys），导致该功能彻底失去实用意义。

关键论据：

• 安全风险：GitHub Actions近年频发安全事件，本应简化而非增加复杂度以方便漏洞分析。
• 工具兼容性：主流YAML解析器（如serde_yaml）会复制锚点值，导致静态分析工具（如作者维护的zizmor）难以追踪源码位置。
• 替代方案：共享环境变量应通过工作流级env或拆分架构实现，而非依赖锚点。

作者建议：

GitHub应立即撤回对YAML锚点的支持，避免生态工具（如actionlint、poutine）因适配新数据模型而瘫痪。

（注：原文中的代码示例、脚注及社交媒体链接等辅助内容已精简，保留核心论证逻辑。）

以下是评论内容的总结：

支持YAML锚点的观点

1. 减少冗余：多位用户认为YAML锚点能有效减少重复代码，提高工作流可维护性。

   • "YAML anchors are a welcome feature and will allow us to DRY some of our uglier workflows" (baobun)
   • "We have what is essentially the same setup/teardown for three jobs within one workflow. I’d love to be able to factor that stuff out" (a_t48)

2. 安全优势：锚点可以避免全局变量带来的安全风险。

   • "given that env variables are often used for secrets data, you really don't want them to set them at the top level" (theamk)

3. 标准兼容性：支持标准YAML特性比使用自定义语法更合理。

   • "it's surprising and confusing if you start saying 'actually, it's a proprietary subset of YAML'" (OJFord)

反对或质疑的观点

1. 可读性问题：部分用户认为锚点增加了复杂性，降低了可读性。

   • "OPs main argument seems to be 'I don't have a use for it and find it hard to read'" (baobun)

2. 非标准实现：GitHub使用的自定义YAML实现可能带来兼容性问题。

   • "The complaint is Github using a non-standard, custom fork of yaml" (kpcyrd)
   • "merge keys are not part of the YAML spec" (beder)

3. 配置语言局限性：有用户认为YAML本身不适合用于复杂配置。

   • "Can YAML go away entirely and instead allow pipelines to be defined with an actual language?" (pacoWebConsult)
   • "Once you allow setting and reading of variables in a configuration file, you lose the safety that makes the format useful" (devmor)

中立/其他观点

1. 工具支持不足：现有工具对锚点的支持不完善。

   • "if you tell it to edit a node that is actually from a yaml anchor, it updates the original anchor without warning" (danudey)

2. 渐进式复杂化：数据导向的配置最终会演变成编程语言。

   • "any data-orient approach would inevitably evolve into a programming language given enough time" (raincol)

3. 替代方案不足：当前替代方案（如全局变量）存在明显缺陷。

   • "his example alternative is wrong: it would set variables for all steps, not just those 2" (imcritic)