一位长期写 Visual Basic、后来转向 C#/.NET 的开发者 EvilGenius，在个人博客上问了一个很窄的问题：真正用 VB6 做过生产系统、现在又写现代 .NET/C# 的人，能不能说说 VB6 到底哪里好，现代 .NET、C# 和 Visual Studio 又哪里让人累。

这个问题有意思，因为它不在问“VB6 是不是过时”。答案太容易。它问的是另一件事：为什么一种 1990 年代的业务软件工作流，到了今天还会被一批开发者认真想起。

我的判断是，VB6 这次被提起，不是怀旧滤镜。它指向的是业务软件开发里很现实的一笔账：工具链越强，未必越快交活；框架越多，未必越容易做出一个能跑、能改、能交付的内部系统。

问题缘起：VB6 经验正在变成稀缺工程记忆

EvilGenius 给出的背景很具体。

1995 年到 2010 年间，他用 VB3、VB4、VB5、VB6 交付了约 100 个 line-of-business 业务系统。2010 年后，他转向 C#/.NET。

他这次征集反馈，是为了写一段从 VB 到现代 .NET 的迁移史。对象限定得很窄：用 VB6 做过真实生产系统，如今也在写现代 .NET/C# 的开发者。

这条边界很重要。它排除了两类噪音：只用过 VB6 玩具项目的人，以及只凭印象批评 VB6 的人。

他要的不是情绪，是工作流细节。比如：

问题需要的不是更有价值的是
VB6 哪里好“简单”“好用”表单设计器、双击事件、写处理器、打包 EXE、交付给业务部门的具体过程
现代 .NET 哪里累“太复杂”UI 路线选择、项目结构、绑定/MVVM、依赖部署、Visual Studio 工作流里的具体摩擦
迁移史怎么写怀旧结论哪些效率来自语言，哪些来自 IDE，哪些来自当时企业软件生态

这类记忆正在变少。

很多 VB6 系统不是公开产品，而是企业内部系统、数据录入工具、报表工具、审批小应用。它们不一定光鲜，但常常用了很多年。写过它们的人离开岗位后，剩下的不是一段产品史，而是一堆还能运行、但很难解释清楚的工程选择。

对维护老系统的人来说，这不是考古。它会直接影响预算和节奏：到底是继续维持 VB6 系统，还是找理由重写；如果重写，是照着旧流程复制，还是顺手把架构翻新。

很多争论就卡在这里。

业务方看到的是“还能跑”。开发团队看到的是维护风险、人员断层和迁移成本。两边都不全错，只是算的账不一样。

核心对比：VB6 省的是路径，现代 .NET 强的是能力

VB6 让人念念不忘的地方，往往不是语言本身。

更关键的是路径短：打开表单设计器，拖控件，双击事件，写处理器，打包 EXE，交付。这个流程对小团队和内部工具很友好。它少了很多前置解释。

现代 .NET 的能力当然更强。安全、性能、工程化、跨平台、大型团队协作，这些不是 VB6 能轻松承担的东西。

但能力变强之后，选择也变多。选择一多，心智负担就上来了。

维度VB6 常见路径现代 .NET 常见变量对业务团队的影响
UI 开发表单设计器直接搭界面WinForms、WPF、MAUI、Avalonia 等路线并存立项前要先解释选型
事件处理双击控件，写事件处理器事件、绑定、MVVM、项目分层等做法并存小工具也可能先背上架构成本
交付方式打包 EXE，发给使用部门运行时、依赖、部署模型更多交付前沟通和测试环节变多
适用目标内部业务系统、录入和报表工具跨平台、云端、服务化、复杂企业架构能做更大的系统，但不一定更快做小系统

这张表不说明 VB6 全面赢了。

它只说明一个限制：如果目标只是尽快做一个内部业务工具，现代工具链的“正确姿势”可能会显得太重。尤其是小团队、单人维护项目、预算有限的部门系统，很多高级能力用不上，但学习和部署成本会先到。

这也是 WinForms 仍会被提起的原因。

原文提到，微软在 VB6 之后推出过多个 UI 框架，但 2002 年随 .NET Framework 推出的 WinForms，至今仍是很多业务应用的低阻力路径。这个判断并不新潮，却很贴近桌面业务软件的现实。

很多企业桌面系统要的不是“最先进”。它们要的是接数据库、画表单、处理按钮事件、导入导出、稳定运行。大道至简，前提是这条道真的能走通。

WPF 表达能力更强，但学习和项目结构更重。Silverlight 曾服务富互联网应用，后来退场。UWP、MAUI 承担过跨设备和跨平台想象，但对传统企业桌面系统来说，迁移收益未必能覆盖改造成本。

所以，开发者下一步不该只问“要不要离开 VB6”。更实际的问题是：现有系统最危险的是哪里。

如果风险来自老旧依赖、部署环境和人员断层，那要优先做维护边界和替换计划。若风险主要来自界面难改、流程难扩展，可以先挑一小块业务，用 WinForms、WPF 或其他路线做原型，不要一上来就全量重写。

对采购和技术负责人来说，这会影响动作：重写项目可以延后，但不能没有盘点；迁移可以分阶段，但不能只靠“新框架更现代”立项。

讨论边界：这不是新项目，也不是怀旧宣言

目前能确定的事实很少。

这是一篇征集反馈的博客文章，不是微软官方表态，也不是新工具发布。原文没有证明现代 .NET 失败，也没有说 VB6 应该复兴。

这条边界必须守住。否则讨论很容易滑向两个极端：一边把 VB6 说成“玩具语言”，一边把它说成“神作 IDE”。这两种说法都省事，但都绕开了真正的问题。

真正该看的，是反馈会集中在哪些地方。

接下来观察点如果反馈集中在这里能说明什么
表单设计器、事件模型、打包交付开发者反复提到“少步骤、快交付”VB6 的价值主要来自低阻力工作流
Visual Studio 工作流、项目结构、依赖管理开发者抱怨现代工具链摩擦问题不只在语言，而在工具链心智负担
COM、数据库访问、企业内部部署反馈转向旧生态默认配置VB6 的效率来自当时整套企业软件环境
维护风险和迁移成本反馈谈人员断层、预算、兼容性讨论会落到现实治理，而不是语言喜好

最受影响的其实就两类人。

一类是还在维护老 VB6 系统的开发者。他们需要把“还能跑”和“可继续维护”分开讲。系统能跑，不等于风险可控；但风险存在，也不等于必须立刻重写。

另一类是做内部工具的小团队。他们要警惕把简单问题做重。报表、录入、审批、导出这些活，先看交付闭环，再谈架构漂亮。

我不太买账的是，把所有低阻力都归结为“旧时代简单”。旧时代也有旧时代的问题，VB6 也有它的限制。但一个工具能让普通业务软件快速从需求走到交付，这件事本身就值得被记录。

回到开头那个问题：VB6 到底留下了什么？

它留下的未必是一套该被复制的技术栈，而是一种该被认真衡量的开发体验。少一步配置，少一次解释，少一层不必要的抽象，对业务软件来说，可能就是一天交付和一周扯皮的差别。