COBOL 迁移到 Go：英国企业指南

当简洁性、快速构建和轻松部署比庞大的企业框架生态系统更重要时，将 COBOL 迁移到 Go 是一个务实的选择。它编译为单个静态二进制文件，没有运行时依赖，随处可运行，其内置的并发模型天然适合将 COBOL 批处理现代化为并行工作负载。

本指南阐述 COBOL 迁移到 Go 实际涉及哪些内容、英国企业可采用的方法、成本几何，以及你必须提前规划的那一个精度问题。

摘要

• Go 适合那些看重简洁性、快速编译、单一二进制部署和轻松并发，而非厚重企业框架栈的 COBOL 迁移
• Go 没有原生十进制类型：COBOL 压缩十进制（COMP-3）字段默认映射为 float64，因此金融计算需要一个十进制库，例如 shopspring/decimal
• 三种主要方法（自动转换、并行重写和渐进式"绞杀榕"迁移）具有不同的风险与成本特征
• 中等规模的迁移通常花费 200,000 至 800,000 英镑，历时 一 至 两 年；十进制精度决策和数据访问层是关键的规划事项

为何为 COBOL 迁移选择 Go

Go 并非最大的企业生态系统，但它是一门有意为之、专注的语言，非常适合某些 COBOL 现代化场景：

简洁性与可读性。 Go 拥有一套小而一致的特性集。转换后的 COBOL 逻辑保持可读，新团队成员能够快速上手，从而降低长期维护风险。

单一二进制部署。 Go 编译为一个无需安装运行时的自包含可执行文件。对于从大型机迁移到 Linux 服务器或容器的团队，部署变得轻而易举。

内置并发。 goroutine 和通道使得并行化主导 COBOL 系统的顺序化、逐记录批处理变得简单。曾在大型机上串行运行的夜间批处理作业，通常可以重构为并发处理各个分区。

快速编译与云原生契合。 Go 的快速构建和小型容器镜像契合现代 CI/CD 以及在 Azure、AWS 或 GCP 上的云部署。

你必须尽早做出的十进制精度决策

这是 COBOL 迁移到 Go 中最重要的规划要点。COBOL 的 PIC 9 和 COMP-3 字段保存精确的十进制（以 10 为基数）数值，这正是金融系统所依赖的。Go 没有原生十进制类型。十进制字段的默认映射是 float64，它使用 IEEE 754 二进制浮点，可能在货币计算中引入舍入误差。

对于任何金融或对十进制敏感的逻辑，正确的做法是使用一个十进制包，例如用 shopspring/decimal 代替 float64。优秀的转换器会将这一决策显性化，而非悄然处理：Mecanik COBOL 迁移到 Go 工具 默认将十进制字段映射为 float64，但会在其 Migration Report 中标记每一个字段，让你可以逐字段决定何处需要精确的十进制运算。切勿在未经该审查的情况下将基于 float64 的金额代码上线。如果在不引入任何额外库的前提下追求精确十进制精度是优先事项，那么 C# （原生 decimal）或 Java （BigDecimal）可能更为合适。

需要真正翻译的 COBOL 结构

安全的迁移是将 COBOL 的语义翻译为符合习惯的 Go，而非文本：

• 组项（01-49 层级结构） 变为带有导出的 PascalCase 字段的 Go struct 类型（ACCOUNT-BALANCE 变为 AccountBalance）。
• PIC 子句 映射到正确的 Go 类型：字母数字用 string，数值按位数用 int16 / int32 / int64，十进制字段用 float64（或一个十进制包）。
• PERFORM 范围 变为函数调用；段落和节分解为函数。
• EVALUATE / WHEN 映射为 switch 语句。
• COPY 和 REPLACE（复制簿）必须被解析，包括嵌套的复制簿。
• EXEC SQL（DB2）、EXEC CICS 和 VSAM 需要重新设计到 Go 的 database/sql、sqlx 或诸如 GORM 之类的 ORM，以及现代服务模式之上。
• EBCDIC 编码和定宽布局 需要显式转换为 Unicode 和带类型的模型，通常使用带缓冲的（bufio）I/O。

迁移方法

主要有三种方法，每种都有不同的风险与成本特征。

1. 自动转换

工具解析 COBOL 并生成带有包结构、带类型的结构体、定长整数和带缓冲文件 I/O 的 Go。它能迅速消除机械性工作，但不会替你做出架构决策。

最适合： 优先目标是快速消除 COBOL 依赖的大型代码库。

风险： 十进制字段、内嵌 SQL、CICS 交互和动态调用都需要人工审查。Migration Report 存在的意义正是揭示这些内容。

2. 并行重写

Go 系统与 COBOL 系统并行运行，二者处理相同的输入，输出相互校验，直到 Go 通过验证且 COBOL 退役。

最适合： 不能冒连续性风险的关键任务系统。

风险： 并行运行两套系统会使迁移期间的运营成本翻倍，并要求严格的对账。

3. 渐进式迁移（绞杀榕）

COBOL 程序被逐个替换为 Go 等价物。系统先变为混合状态，最终成为纯 Go。

最适合： 全面重写不切实际的大型单体 COBOL 系统。

风险： 混合状态可能持续得比计划更久，并且要求精心的接口设计。

对于大多数英国迁移而言，绞杀榕方法结合有选择的自动转换，能在风险与速度之间取得最佳平衡。

英国 COBOL 迁移到 Go 的成本

成本在很大程度上取决于代码库规模、复杂性和方法。英国企业项目的参考区间：

这些数字涵盖分析、迁移、测试和上线支持。它们不包括持续的运营成本、培训，以及常在项目中途浮现的下游集成工作。

Mecanik COBOL 迁移到 Go 服务 专注于英国企业迁移，涵盖评估、转换、数据访问层实现和输出一致性测试。对于正在权衡目标语言的组织，COBOL 迁移概览 列出了完整范围，包括 C#、Java、Python、C++ 和 Rust。对于从 IBM z/OS 的迁移，遗留大型机迁移服务 在代码迁移之外还涵盖基础设施退役。

关键风险及应对方法

十进制精度。 Go 迁移的决定性风险。审查 Migration Report 中标记的每一个映射为 float64 的字段，并在上线前将金融字段切换到一个十进制包。

未记录的业务逻辑。 数十年内嵌的业务规则却没有外部文档。发现与记录是任何迁移中最耗时、风险最集中的部分。

数据访问层。 针对 DB2 的 EXEC SQL 和 VSAM 处理必须重新设计到 database/sql 或一个 ORM 之上。这往往是单项最大的工作量。

性能与并发。 Go 性能良好，其并发能力可以胜过串行的 COBOL 批处理，但将顺序逻辑重构为并行工作负载时，必须保持顺序和正确性保证。

回归测试覆盖率。 通过在真实（脱敏）数据上进行全面的回归测试来证明 Go 输出与 COBOL 一致，并特别关注对十进制敏感的计算。在迁移开始之前构建好测试套件。

切换风险。 一份带有回滚和对账的详细切换计划是必须的。

关键要点

• Go 适合优先考虑简洁性、单一二进制部署和并发的 COBOL 迁移。
• Go 没有原生十进制类型；请为每一个金融字段提前规划 float64 与十进制库之间的决策。
• 大多数英国企业项目采用绞杀榕方法并辅以有选择的自动化。
• 最大的风险是十进制精度、未记录的业务逻辑和数据访问层。

常见问题（FAQ）

为何在 COBOL 迁移中选择 Go 而非 Java 或 C#？ 选择 Go 是为了简洁性、快速编译、单一二进制部署，以及用于并行化批处理工作的内置并发。当你需要更大的企业框架生态系统，或需要更少人工审查的原生／库十进制支持时，选择 Java 或 C#。

Go 如何处理 COBOL 的压缩十进制字段？ Go 没有原生十进制类型，因此十进制字段默认映射为 float64，这可能在金融计算中引入舍入。优秀的转换器会标记每一个十进制字段，让你可以在需要精确运算之处，用诸如 shopspring/decimal 之类的包替换 float64。

COBOL 逻辑能否自动转换为 Go？ 可以，借助工具即可。优秀的转换器生成基于包的 Go，带有带类型的结构体、定长整数和带缓冲的 I/O，并标记内嵌 SQL、CICS 交互、动态调用和十进制精度字段以供人工处理。架构决策仍然是人类的任务。

COMP-3 和 EBCDIC 之类的 COBOL 数据格式会怎样？ COMP-3 默认映射为 float64（需针对精确十进制需求进行审查）。EBCDIC 文本和定宽布局需要显式转换为 Unicode 和带类型的模型，并在投入生产使用前针对真实数据进行测试。

COBOL 迁移到 Go 需要多长时间？ 小型、文档完善的系统需要 三 至 九 个月。中型企业系统需时 十二 至 二十四 个月。大型大型机项目完成全面退役可能需要 三 至 五 年。