从 .NET + Angular 到 Go + React：一次真实的技术转型决策

我们团队长期都在做传统企业内部系统，更准确地说，是以 ERP / 后台管理类系统为主。

团队规模一直在 10 人左右，过去主要使用的技术栈是：

• 后端：.NET
• 前端：Angular
• 运行环境：Windows Server

这套组合在过去很多年里一直支撑着团队的稳定交付。对于传统内部系统来说，这也是一条很常见、很务实的路线。

但最近，随着上层开始明确推动技术转型，这件事已经不再只是技术团队内部的技术偏好选择。作为承接这项要求、需要把方向变成落地方案的人，我必须认真回答一个问题：

我们接下来要面对的问题，已经不是“原来的技术还能不能用”，而是“当工程模式开始变化时，原来的技术路径是否还适合继续承载下一阶段”。

再往前看，它是否还能为团队未来 3-5 年的组织演进留下空间。

一、为什么旧模式开始不再适合

先说清楚一点：.NET + Angular + Windows Server 不是不能用。对于内部管理系统开发来说，这套组合到今天依然是很多传统企业的可选方案。

过去我们的开发方式，很符合传统内部系统团队的典型路径：系统偏 ERP / 流程 / 后台管理，团队规模不大，开发与部署环境相对固定，以 Windows Server 作为默认基础设施，整体目标更偏“稳定交付”。

但现在，情况开始变化了。

第一，AI 编程工具已经在改变团队的开发方式。它带来的不只是编码速度更快，而是原型搭建更快、重复劳动更少、跨语言成本更低。编码效率提高之后，真正的瓶颈会越来越集中到系统架构、部署方式和环境统一这些更上层的问题。

第二，我们也需要运行环境具备更高的迁移灵活性。无论是出于合规、成本，还是部署策略调整，服务都应该更容易在公有云与本地环境之间迁移。

在这种背景下，容器化、持续交付和云原生已经越来越成为主流方向。从整体工程实践看，Linux + Docker + Nginx + CI/CD 这套链路会更顺。

更重要的是，技术栈不再只是开发效率问题，而开始影响团队未来怎么扩、怎么分工、怎么协作。过去一套技术方案是否成立，更多取决于“能不能稳定交付”；而下一阶段是否继续成立，还取决于它能不能支持多人协作、规范复制、环境统一，以及未来进一步扩张时的组织成本。

二、为什么最终是 Go + React

我们最终转向 Go + React，不是因为它们“最先进”，而是因为它们更适合我们这个阶段的团队规模，也更符合接下来的工程方向。

对我们来说，这不是一次单点技术替换，而是一次为了匹配新工程链路而做出的整体调整。Go + React 的开源生态更大、社区样本更多，在 AI 辅助开发场景下也更容易获得成熟的参考实现。与此同时，Go 在部署轻量、资源占用和并发处理上也有明显优势，这让它更容易兼顾性能与成本。再往上看，这套组合不仅影响代码怎么写，也影响团队以后怎么协作、怎么招人、怎么沉淀规范，以及怎么把工程能力复制给后续新增成员。

1. Go 适合小团队做云原生方向的工程落地

Go 的价值，不在于它“新”，而在于它有几个很现实的优点：

• 语言简单，团队更容易统一写法
• 更适合 Linux 环境下的服务开发与部署
• 和 Docker、容器化、云原生实践天然更顺
• 部署轻量，运行模型清晰，资源占用低，并发处理能力强
• 开源生态更大，在 AI 辅助开发场景下更容易获得成熟参考和代码建议

我们需要的不是“能力最强的语言”，而是“更适合小团队长期交付的语言”。

2. React 更适合前端后续持续演进

前端从 Angular 转向 React，也不是因为 Angular 不行，而是因为 React 更适合我们当前的前端演进方向。它在现代前端生态中的案例、组件、脚手架和社区范式都更丰富，在 AI 辅助开发场景下，也更容易获得成熟的参考实现和代码建议。对需要持续演进的后台系统来说，这一点尤其重要。

3. 真正重要的是整条链路能连起来

这次转型里，我最看重的不是 Go 或 React 单独有多强，而是它们能不能和未来的工程链路自然拼起来：

• Go 做后端服务
• React 做前端界面
• MySQL / Redis 做基础数据层
• Linux 作为基础运行环境
• Docker 负责容器化交付
• Nginx 负责入口与代理
• Git + CI/CD 负责持续交付
• AI 编程作为开发效率放大器

只有当这条链路能够顺畅地连起来，技术栈才真正有意义。

4. 技术栈最终服务的，是未来的组织能力

做技术选型时，不能只看“今天写起来顺不顺”，还要看这套技术会如何影响团队未来的协作方式、规范沉淀和扩张成本。

对我们来说，Go + React 的意义不只是提高开发效率，而是在为接下来 3-5 年的组织能力建设做准备：

• 它更容易形成统一的工程范式，而不是高度依赖个人习惯
• 它更容易支撑新成员加入后的快速上手和规范复制
• 它更容易把前后端协作、部署方式、运行环境收敛到同一套工程语言里
• 它更适合作为未来组件库、服务模板、脚手架和公共能力沉淀的起点

换句话说，这次转型的目标，不只是让当前团队更高效，而是让未来的团队更容易扩张，也更容易保持一致性。

三、这次转型真正解决的，不只是技术问题

表面上看，这是一次技术栈切换；更深一层看，它是在回答团队未来 3-5 年该如何继续做系统。

第一，团队要更适应 AI 编程时代。AI 不会替代工程判断，但会放大开发效率。这意味着小团队以后更应该把精力放在需求理解、模块设计、接口规范、部署流程和复杂度控制上。

第二，部署和运行方式要现代化。过去很多内部系统团队对部署的要求并不高，系统能跑就行；但随着容器化成为趋势，团队也需要逐步从固定服务器思维转向容器思维、从环境依赖转向镜像交付、从手工部署转向自动化交付。

第三，系统后续要更容易演进。如果未来几年还要继续做新系统、改造旧系统、逐步建立统一规范，那么旧模式越往后拖，切换成本越高。

第四，让团队同时具备开发内部系统和更通用 Web 应用的能力。这并不是说 .NET + Angular 不能用于这类场景，也不是说它不能走云原生，而是对我们接下来的方向来说，Go + React 会更容易落地，也更符合未来的工程目标。

第五，这次转型也在提前回答组织层面的问题：未来如果团队从 10 人扩到 20 人、30 人，甚至更大规模，技术栈是否还能支撑协作边界、人才复制、工程治理和公共能力沉淀。真正高质量的技术决策，不只是解决眼前开发问题，还要为未来组织能力建设留下空间。

四、一个重要边界：不是因为 AI，所以必须 Go

这里有一个边界需要明确。

我们不是因为“AI 火了，所以大家都该学 Go”，也不是因为“AI 编程出来了，所以 .NET 不行了”。

更准确的说法是：AI 编程的发展，提高了技术迁移和多栈开发的可行性；容器化和 Linux 环境推动了基础设施切换；在这样的工程背景下，Go 更适合我们这个阶段的小团队去做长期落地。

这三件事是叠加在一起发生作用的，不是单一因果关系。

五、为什么这对小团队尤其重要

大团队和小团队做技术转型，逻辑并不一样。

大团队可以容忍更复杂的技术体系，因为人多、分工细、容错空间大；但小团队不行。对小团队来说，技术决策最重要的不是“追最先进”，而是学习成本是否可承受、部署链路是否可掌控、团队能否快速形成统一规范，以及新系统能否尽快落地。

所以我们这次做转型，真正追求的不是“技术上限”，而是：在 AI 时代，用更适合团队承载能力的方式建立下一阶段的工程基座。Go + React + Linux + Docker 这套组合，正好比较符合这个目标。

但这里还有一个更高一层的判断：小团队今天做的技术选择，往往会直接影响未来团队长大之后的组织成本。技术栈一旦定型，后面影响的就不只是代码风格，还会影响招聘口径、培训成本、协作方式、发布治理和平台能力建设。所以小团队做技术转型，看上去是在选技术，实际上也在提前影响未来组织的扩张方式。

六、写在最后

从表面看，我们只是把：

• .NET 换成 Go
• Angular 换成 React
• Windows Server 换成 Linux + Docker

但本质上，我们真正做的是一件更底层的事：把过去适合传统企业内部系统开发的工程基座，更新成一套更适合 AI 编程、容器化部署、云原生演进，也更适合未来组织扩张的工程基座。

这并不意味着过去全错。恰恰相反，过去那套东西在当时是成立的。只是今天，我们面对的开发效率工具、部署方式、基础设施偏好，以及团队未来要走的方向，都变了。

所以技术转型，不是对过去的否定，而是对下一阶段现实的回应。

说得更直白一点：不是 .NET + Angular 不能继续做系统，而是 Go + React + Linux + Docker 更适合我们这支 10 人左右团队下一阶段的工程未来，也更适合作为未来 3-5 年组织演进的起点。