小村软件有限公司
联系我们
菜单

Windows 应用不适合 Web 化的情形 ── 判断表与「拆分」这一现实解法

· · Windows开发, Web迁移, 现代化改造, 业务应用, 判断表, 设计, 技术咨询

「差不多想把公司内部用的 Windows 应用 Web 化了」——这样的咨询逐年增加。虽然这往往是合理的动机，但深入了解之后会发现，不少团队正准备把一款一旦 Web 化反而会变得更难用、成本更高的应用，直接推向全面 Web 化。

先说清楚：本文并不是在主张「不要 Web 化」。多据点使用、减少终端管理负担等场景下，Web 化明显是正确的选择，这样的情况有很多。真正的问题在于，把本来不适合 Web 化的应用，也一概套用「现代化＝Web 化」这一公式。本文整理了我们在 Windows 委托开发一线实际用来判断「哪些情形最好不要 Web 化」的方法，并提出拆分这一不把「全部 Web 化」还是「全部保留 Windows」当作非此即彼选择的现实方案。

1. 先说结论（判断表）

关键在于，不是对整个应用做判断，而是针对应用所具备的每一项功能或特性逐一判断。

应用特性 与 Web 化的契合度 理由
需要从多个据点、公司外部查看相同数据 ◎ 适合 只要有浏览器即可使用，无需在终端上安装
以查看、检索、汇总、报表为主 ◎ 适合 浏览器的标准能力足以实现，是 Web UI 的强项
终端更换、增减频繁 ○ 适合 无需客户端分发，减少配置作业
与串口、USB 设备、检测仪器、生产设备直接通信 × 不适合 浏览器沙箱会限制对本地资源的访问1
监控/批量处理本地文件，与其他应用（Excel 等）进行进程间联动 × 不适合 浏览器无法自由访问文件或启动其他进程
用于网络不稳定的现场，且不能中断的业务 × 不适合 Web 应用在离线状态下功能会受到很大限制2
以键盘为主的高速、大批量数据录入 △ 需谨慎 每次操作的响应延迟，以及重现桌面级表格控件的成本，往往成为问题
除了『技术老旧』之外没有其他 Web 化动机 △ 需谨慎 Web 化是接近重建的投资。如果动机仅仅是技术新旧，应与保持 Windows 应用形态的现代化方案进行比较

下面先给出结论。

  • 『想 Web 化』这样的需求，通常混杂了三个不同的问题。 分发的麻烦、使用场所的限制、技术的过时。这三者的解决方案各不相同，只有其中一部分只能靠 Web 化来解决（第2章）。
  • 带有设备联动、本地文件处理、离线运行的应用，至少那部分功能不 Web 化会更安全。 浏览器出于安全考虑，有意限制对本地资源的访问，这不是 Web 的缺陷，而是其设计理念本身1。虽然存在变通方案，但会带来支持浏览器受限、运维复杂化等新的成本（第3～5章）。
  • Web 化是『重建』而不是『移植』。 现有的界面资产无法直接搬过去，而且完成之后还会新增服务器运维这一持续性成本。如果估算的前提没有建立在这一点上，计划就会在中途崩溃（第7章）。
  • 现实的解法是拆分。 把查看、汇总、报表放到 Web 上，把设备联动、现场录入保留在 Windows 上，通过共用的 API 和数据库连接起来。相比全面 Web 化，可以从更小的规模开始，并按收益大小依次推进（第8章）。

2. 拆解「想要 Web 化」这句话背后的内容

在接到 Web 化的咨询时，我们最先做的是拆解这个需求。「想 Web 化」这句话的背后，通常隐藏着以下三者之一（或多个）。

（1）想消除分发和更新的麻烦。 典型的烦恼是「每次升级版本都要跑遍所有终端去安装」。Web 化确实能解决这个问题，但不 Web 化也同样能解决。只要切换成 ClickOnce 或 MSIX 这类具备自动更新机制的分发方式，即使继续保持 Windows 应用的形态，分发工作也几乎可以降为零。详情请参见「Windows 应用发布方式怎么选」。如果分发的麻烦是唯一的动机，那么 Web 化就是过度投资。

（2）想在任何地方、任何终端上都能使用。 多据点使用、从客户现场或家中访问、在平板上查看——这正是 Web 化真正擅长的领域。但即便如此，也要区分清楚是「想在任何地方使用全部功能」，还是「只是想在任何地方查看数据」。实务中往往是后者，这种情况下，只把查看、汇总部分放到 Web 上的拆分架构（第8章）就已经足够。

（3）想摆脱老旧技术。 这类动机通常是「当初开发的人已经离职」「一直用 .NET Framework 让人不安」。这是正当的问题意识，但解决方案未必是 Web 化。既然反正要重建，如果业务性质更适合桌面场景，也可以选择用最新的 .NET 重建为 Windows 应用（「Windows Forms、WPF、WinUI 该怎么选」）。此外还应该认识到，Web 化并不能让你摆脱技术过时的命运。为 IE 专用而搭建的公司内部 Web 系统，随着 IE 停止服务而陷入困境的案例，正是记忆犹新的典型（「摆脱 IE 模式依赖系统的实践指引」）。Web 应用同样需要持续维护，以跟上框架和浏览器的变化，「Web 化」并不等于「摆脱维护」。

经过这样的拆解，就能看清哪些问题只能靠 Web 化解决、哪些问题用其他方式也能解决、哪些问题即使 Web 化也解决不了。在此基础上，再确认应用中是否存在下文所述「最好不要 Web 化」的功能。

3. 情形一：与设备、外围设备直接相连

与生产设备的通信、从检测/检查仪器采集数据、串口（RS-232C）连接的秤或条码枪、专用打印机的精细控制——具备直接与硬件对话的功能的应用，在结构上就不适合把这部分 Web 化。

原因很简单：运行在浏览器中的代码，是在名为沙箱的隔离环境中执行的。如果仅仅打开一个网页，就能随意触碰终端内的文件或设备，那会造成安全隐患，因此浏览器有意阻断了对本地资源的访问。这不是 Web 的缺陷，而是安全设计本身。例如，即使是可以用 C# 编写 Web 客户端的 Blazor WebAssembly，代码也运行在浏览器的安全沙箱内，文件系统访问或建立任意网络连接的操作都会抛出 PlatformNotSupportedException1。能做的事情被限制在浏览器自身支持的范围之内2。

也许有人会反驳说「Web Serial API 或 WebUSB 不是可以让浏览器进行串口通信吗」。这确实存在，但支持的浏览器有限。Web Serial API 目前由 Chrome、Edge 等 Chromium 系浏览器支持，2026 年 5 月发布的 Firefox 151 也让桌面版 Firefox 加入了支持，但Safari 仍未支持（移动端方面，Android 版 Chrome 也仅部分支持通过蓝牙进行的串口通信），而 WebUSB 则至今仍仅限 Chromium 系3。这不仅限制了 Web 化最大的优势——「任何浏览器都能用」，而且在连接设备时（至少是首次连接或每次新增设备时），用户还必须在浏览器弹出的对话框中选择并授权设备，因此作为业务系统的设备联动手段，实际上往往不划算。

此外，也可以用「Web 应用 + 常驻在各终端上的联动代理」这样的架构来规避上述问题，但这种做法最终仍然会留下一个需要分发和更新的 Windows 程序。这本身并不是坏事——实际上它正是第8章所述拆分架构的一种形式——但需要在规划阶段就明确告知：这与「Web 化之后终端上就不用装任何东西了」这一最初的期望并不是一回事。

关于设备联动部分的设计，也请参见「外部设备状态检查与显示的最佳实践」。

4. 情形二：与本地文件、其他应用深度联动

其次常见的情形是，与终端内的文件或其他应用程序的联动，成为业务的核心。

  • 监控共享文件夹或本地文件夹，对放入其中的文件自动进行处理
  • 批量转换、重命名、分类数百上千个文件
  • 启动 Excel，通过 COM 组装报表，或与既有的 Excel 宏联动
  • 通过文件或进程间通信，与其他业务应用交换数据

浏览器文件访问的原则是，仅限于「用户当次通过对话框选择的文件」。既无法在没有用户操作的情况下进行批量访问，也无法实现在浏览器关闭后仍持续运行的常驻式监控。近年来的 File System Access API 可以实现对用户所选文件夹范围内的访问，甚至出现了在页面打开期间监控所选文件夹内变化的实验性 API（FileSystemObserver），但这些都仅限于 Chromium 系浏览器4，存在与设备联动相同的「被绑定在特定浏览器上」的问题。至于从浏览器启动并操作 Excel 这类本地其他进程的手段，则根本不存在。

要把这类功能 Web 化，就需要把业务流程改为「让用户把文件上传到服务器，由服务器端处理」的形式。如果业务能够以这种方式成立，这不失为一种选择；但如果存在日常需要处理 GB 级文件、需要在本地完成不能外传的数据处理、与 Excel 资产紧密耦合等情况，那么把这部分保留为 Windows 应用（如果是文件夹监控、批量处理这类无人值守处理，则可以是 Windows 服务）会让开发方和使用方都更加轻松。不过，有一点需要特别注意存放位置：与 Excel 的 COM 联动。微软并不推荐、也不支持从服务等无人值守、非交互式环境中自动化操作 Office5，因此自动操作 Excel 的处理应放在有用户登录使用的桌面应用一侧，或者改用不启动 Office 的 Open XML 系类库进行读写。关于 Excel 联动的实现方法，请参见「Excel 报表输出的实现方法」；关于文件夹监控，请参见「FileSystemWatcher 实务指南」。

5. 情形三：用于网络不稳定的现场、且不能中断的业务

从结构上讲，Web 应用以网络连接始终存活为前提。服务端渲染型的 Web 应用自不必说，就连 C# 系中颇受欢迎的 Blazor Server 也是如此——所有 UI 操作都要通过与服务器的持续连接来处理，因此一旦连接中断，应用就会停止工作。官方文档明确写明其不提供离线支持2。

这在以下环境中会成为问题：

  • 工厂、仓库、户外现场：Wi-Fi 信号被金属货架或机械遮挡，瞬时断线是家常便饭
  • 不能停止的生产线：记录或指示画面哪怕只停顿几分钟，也会影响生产或出货
  • 线路细而不稳定的据点：依赖移动网络的临时办公室、船上、山区等

原生 Windows 应用可以很自然地做到把数据保存在本地、离线状态下继续工作、待网络恢复后再同步。离线运行甚至是微软自己列出的、建议选择原生应用的理由之一6。使用 PWA（Service Worker）或将数据保存在客户端的设计，从技术上也能让 Web 应用具备离线能力，但要把包括同步、冲突解决在内的机制做扎实，需要相当规模的额外投入，这与「Web 化会更便宜」的最初期望正好相反。

判断的关键在于：「如果网络中断 30 分钟，这项业务能不能等？」如果不能等，至少承担这项业务的画面应该做成能在本地运行的形式。

6. 情形四：以键盘为主的高速、大批量数据录入是业务核心

单据录入、检验/发货登记、客服中心的应答画面——整天面对这个画面、以键盘为主大量录入数据的这类业务。这是桌面 UI 完成度极高、Web 化容易明显拉低体验的领域。

  • 响应延迟：在 Blazor Server 这类依赖服务器连接的模式下，每一次用户操作都要经过一次网络往返，导致 UI 延迟升高2。即使每次操作只有几十毫秒，在一天数千次操作的录入业务中，也会被明确感受为「卡顿感」。
  • 键盘操作的还原：用 Enter 键移动光标到下一项、功能键的分配、输入过程中的即时校验——这些录入业务中理所当然的行为，在实现时会与浏览器的默认行为（Enter 提交表单、F1 打开帮助等）发生冲突，需要一一克服才能实现。并非做不到，但意味着要额外付出成本，才能追上桌面框架和表格控件本来就具备的完成度。
  • 大数据量表格：要用 Web 实现能对数万行数据流畅进行虚拟滚动，并支持单元格编辑、列冻结、复制粘贴等桌面级表格控件的能力，需要采用功能强大的商业组件，并投入相应的调优工作。

如果只是查看、审批、偶尔录入，Web 表单就足够了。但对于录入速度本身直接关系到业务生产率的画面，请冷静确认：你是否真的能享受到 Web 化「随处可用」这一优势——这个画面最终是不是只会在办公室的固定工位上使用？如果使用地点是固定的，Web 化就没有任何收益，只会带来损失。

7. 情形五：用「移植」的估算方式，实际做的却是「重建」

到目前为止讨论的是功能和使用方式，最后一点则是成本结构的问题。Web 化计划在中途崩溃的典型模式是：按照「把现有的东西搬到 Web 上」这种移植的思路做估算，事后才发现实际上是一次重建。

  • 界面资产无法搬迁。 没有现实可行的手段能把 WinForms 或 WPF 的界面定义和界面逻辑自动转换到 Web 上，UI 必须逐屏重新设计并重建。屏幕数量乘以复杂度，直接就等于工作量估算。
  • 需要先盘点业务逻辑。 在长年运行的应用中，规格书里没有记载、只存在于代码中的业务规则并不罕见。Web 化包含了把这些全部挖掘出来并重新实现的工作。这一点与「VB6 / Access 业务应用的续用与迁移」中所写的「不要一上来就全面重写」这一原则完全一致。
  • 完成后的运维成本会结构性增加。 桌面应用的运维是照看终端设备，而 Web 应用则会新增持续性的工作：服务器（或云环境）的搭建、监控、备份，以及证书和安全更新。如果公司内部没有相应的体制，就需要每月支付外包费用。比较 Web 化的成本时，不能只看初期开发费，还必须把这部分持续运行成本一并纳入。
  • 安全的前提会发生变化。 原本只在公司内网中运行的应用，一旦 Web 化并允许公司外部访问，那么身份验证、授权、通信加密、攻击防护的要求水平就会提升一个层级。这也是「Web 化成本」的一部分。

再次强调，以上这些并不是否定 Web 化的理由，而是用正确的前提进行估算所需的材料。如果把重建成本和持续运行成本都算进去之后，Web 化的收益依然更大，那就应该推进。如果不是，就应该先考虑保持 Windows 应用形态的现代化方案（升级到最新 .NET、改善分发方式、刷新 UI）能否以更小的投入满足大部分的动机。

8. 现实的解法：不要把「全部 Web 化」和「全部保留 Windows」当作非此即彼的选择

把以上判断落实到实务中，多数情况下答案既不是「全面 Web 化」，也不是「维持现状」，而是拆分。

思路很简单：把第1章的判断表，不是套用在整个应用上，而是逐个功能地套用。

  • 放到 Web 上的部分：多据点、多人需要查看的数据的浏览、检索、汇总，报表下载，审批等轻量操作。主数据维护通常也归入这一类。
  • 保留在 Windows 上的部分：与设备、外围设备的联动，本地文件的监控与批量处理，即使离线也不能中断的现场业务，高速录入的画面。
  • 共用的部分：数据库与业务逻辑。将数据统一管理，让 Web 应用和 Windows 应用共同引用同一个 API（或数据库）。只要把这部分共用起来，就能实现「现场用 Windows 应用录入，总部用浏览器立即查看确认」这种能满足大部分 Web 化动机的架构。

这种架构相比全面 Web 化，具备实务上的优势：一次性需要重建的范围更小、可以从收益最大的部分（查看类）开始分阶段推进、并且不会降低现场的使用体验。反过来说，也需要一个能够同时维护 Windows 应用和 Web 应用这两套系统的体制，因此如果目标应用规模较小、功能又以查看为主，直接全面 Web 化可能反而更合适。这同样不是非此即彼，而是程度问题。

另外需要补充一点：对于「界面想用 Web 技术来做，但又需要触及本地资源」这样的需求，还有 Electron 或 Blazor Hybrid（WebView2）这类混合型方案可供选择。它们可以在不受浏览器沙箱限制的情况下，使用 Web 技术编写的界面，但请注意，这仍然是需要分发的桌面应用，并不能满足「只想用浏览器来使用」这一需求。

9. 决定 Web 化之前的检查清单

在提交询价或走公司内部审批流程之前，先确认以下几点，可以减少返工：

  1. 拆解动机：分发的麻烦、使用场所的限制、技术过时，究竟哪一个才是真正的问题？如果只是分发问题，更换分发方式是否就足够了？
  2. 是否存在硬件联动：是否有直接与串口/USB 设备、检测仪器、专用打印机通信的功能？如果有，先确定这部分的处理方式（保留在 Windows 上 / 采用代理架构）。
  3. 对本地资源的依赖：是否存在文件夹监控、文件批量处理、与 Excel 等的进程联动？业务流程能否改为服务器处理型？
  4. 离线需求：如果网络中断 30 分钟，这项业务能不能等？
  5. 录入业务的比重：是否存在整天用键盘录入数据的画面？这个画面是否真的需要「随处可用」？
  6. 使用者与场所的实际情况：谁在什么地方想查看/录入什么内容？是「所有人都要在公司外部使用全部功能」，还是「总部只是想查看数据」？
  7. 运维体制：由谁来负责服务器的搭建、监控、安全更新？每月的费用是多少？
  8. 业务逻辑的所在位置：规格书是否与代码一致？盘点所需的时间是否已经纳入估算？

如果第2至5项中有符合的情况，我们建议以拆分架构为主轴来考虑，而不是全面 Web 化。关于下单前的整体梳理，也请参见「委托开发 Windows 应用程序前该梳理的事项」。

结语

Web 化是工具，而不是目的本身。它对多据点使用、减少终端管理确实有明显效果；而设备联动、本地文件处理由于源自浏览器的安全设计约束，很难通过框架选型或做工来推翻；离线运行、高速录入虽然在技术上可以实现，但其开发和运维成本，往往与「Web 化会更轻松」这一最初的目标背道而驰。而且，Web 化是重建而不是移植，完成之后还会新增服务器运维这一新的持续成本。

正因如此，实务中的判断不应该是「Web 化还是不 Web 化」，而应该是一个设计问题：「哪些功能放到 Web 上、哪些功能保留在 Windows 上、哪些部分要共用」。从对现有应用的盘点，到 Web 化可行性的判断，再到拆分架构的设计，往往需要结合代码与运维的实际情况进行判断，如果拿不定主意，欢迎随时咨询我们。

相关文章

参考资料

  1. Microsoft Learn，Blazor app hosting models（Blazor for ASP.NET Web Forms developers）。关于 Blazor WebAssembly 的程序集在浏览器安全沙箱内执行，文件系统访问或建立任意网络连接的操作会抛出 PlatformNotSupportedException 的说明。 ↩ ↩2 ↩3

  2. Microsoft Learn，ASP.NET Core Blazor hosting models。关于 Blazor WebAssembly 的能力被限制在浏览器支持范围之内、Blazor Server 的每次用户操作都伴随网络往返导致 UI 延迟升高，以及连接中断后应用将无法工作、且不提供离线支持的说明。 ↩ ↩2 ↩3 ↩4

  3. MDN Web Docs，Web Serial API 及 USB（WebUSB API）。关于 Web Serial API 的支持仅限于 Chromium 系（Chrome / Edge 等）以及 151 版本以后的桌面版 Firefox、Safari 尚未支持（Android 版 Chrome 也仅部分支持经蓝牙 RFCOMM 的串口通信），以及 WebUSB 至今仍仅限 Chromium 系的说明（详见各页面的 Browser compatibility 部分）。 ↩

  4. MDN Web Docs，File System API 及 FileSystemObserver。关于 showOpenFilePicker / showDirectoryPicker 等访问本地文件、文件夹的扩展功能，以及监控用户所选文件夹变化的 FileSystemObserver（实验性、尚未标准化）目前仅支持 Chromium 系、在 Firefox / Safari 中无法使用的说明。 ↩

  5. Microsoft Learn，Considerations for unattended automation of Office 及 Microsoft Support，Considerations for server-side Automation of Office。关于微软出于不稳定和死锁风险，不推荐也不支持从 ASP.NET、DCOM、NT 服务等无人值守、非交互式客户端自动化操作 Office 应用程序，并建议改为直接编辑 Open XML 文件格式等替代方案的说明。 ↩

  6. Microsoft Learn，Windows App Development Frequently Asked Questions。关于将性能、与 Windows API 的深度集成、离线支持列为选择原生框架（WinUI / WPF / WinForms）的理由的说明。 ↩

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

如果反正要更新老旧的 Windows 应用，顺便 Web 化会更好吗？
我们不建议仅仅因为『应用老旧』这一个理由就决定 Web 化。Web 化所需的工作量更接近于推倒重来，而不是简单移植；而且 Web 应用同样会面临技术过时的问题（长期锁定在 IE 专用模式下的公司内部 Web 系统就是典型例子）。判断的关键不在于技术的新旧，而在于这个应用的实际使用方式。如果是多个据点使用、希望减少终端管理负担，Web 化的优势就会体现出来；但如果核心是设备联动或本地文件处理，那么升级到较新版本的 .NET、改造界面等『保持为 Windows 应用的现代化』方案，往往性价比更高。
Web 化之后，分发与安装的麻烦不就消失了吗？
客户端的分发工作确实会减少，但如果『减少分发麻烦』是唯一的动机，那么有比 Web 化更轻量的解决方案。只要切换成 ClickOnce 或 MSIX 等具备自动更新机制的分发方式，即使继续保持 Windows 应用的形态，也几乎不需要逐台安装了。而如果选择 Web 化，则会新增服务器（或云环境）的搭建、监控与安全更新等持续性的运维成本。请同时权衡消失的成本与新增的成本后再做决定。
可以只把应用的一部分 Web 化吗？
可以，而且在实务中这往往才是现实的解法。典型的做法是：把数据查看、汇总、报表、多据点访问等功能放到 Web 上，而设备联动、现场高速录入、本地文件处理等则保留为 Windows 应用，两者通过共用的 API 和数据库连接起来。相比全面 Web 化，一次性需要重建的范围更小，也可以从 Web 化收益最大的部分开始逐步推进。
Electron、PWA、Blazor Hybrid 这类中间方案怎么样？
这几种性质不同，需要分开考虑。Electron 和 Blazor Hybrid（WebView2）本质上是以桌面应用的形式运行的，因此不受浏览器沙箱的限制，可以访问文件和设备，而界面则用 Web 技术编写。不过它们仍然是需要分发和更新的桌面应用，无法满足『只用浏览器就能使用』这一需求。而 PWA 虽然可以固定到任务栏等，给人一种『已安装』的使用体验，但其本质仍然是运行在浏览器中的 Web 应用，对本地资源的访问限制与普通 Web 应用完全相同。在考虑 Web 化之前，首先要弄清楚自己真正想解决的问题是什么。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表