@FakerLeung 当然我也不推荐 Electron. 因为他这边涉及音频处理, 必定涉及到大量内存数据运算. 而 Node 在这方面是很弱的. 效率也非常差. 一般像他这种都是 C++ 做算法, 前端套个漂亮的界面来实现相关的功能. 但是既然楼主对 C++ 也不了解，那这种方式显然也不是最优解。

@FakerLeung 你是不是没听说过一个叫 Cordova 的东西？

@bluearc 啊，那涉及到音频处理的话，那可能就只能推荐 Avalonia 了。。能做高效数据处理，能跨端跨平台，开发简单，就只有这一个选择。

js 处理音频比较扯.

不过也可以 C++ 负责处理音频，提供接口给 electron / cordova 调用。跟 QQNT 一样。。。。。不过既然你对 C++ 也不熟，学 C++ 起码半年，我也就不推荐了，

通盘 Node 是最合适的.

Node 做客户端, Electron 自动跨平台. 而且 Electron 已经是十年的框架了, 已经非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常成熟了. 任何你需要的功能都可以做. 至于移动端, Cordova 了解一下? 我们现在就有 Electron + Cordova 的案例. 一套代码, PC + 移动端 + H5 都有了.

@lujiaxing 剩下的 WinForms / MFC / WPF 等都是只支持 Windows

我发现好多人好像根本不看内容只看标题就回答了?
---------------------------------------------------------------------


@gyinbj 如果是这样的话，那基本上就只有 QT 跟 Avalonia 符合你的要求了.
Electron 理论上最合适但是被你针对性的排除了.
Flutter 桌面端目前还处于半成品阶段.
JavaFX 做界面非常丑, 而且缺少组件支持.
...
...
...
剩下的 WinForms / MFC / WPF 等都是

1. 跨平台, Mac / Win 都能用
2. 一次编写, 到处使用.
3. 免费开源.

但是如果论易上手, 那可以直接排除 QT 了. QT 是基于 C++ 的. 如果你没有 C++ 基础, QT 就是难于登天.
那就只剩下 Avalonia 可以选了啊...

C# + AXAML.
C# 相对比较好学, axaml 如果你做过前端的话是很好理解的. 原理上跟 css + html 没啥区别. 只是写起来比 CSS + html + mvvm 更复杂一点.

@duan602728596 人家说的多清楚. 不考虑套壳子浏览器.

这种非互联网企业是几乎不会把软件技术相关的东西拿出来分享的。不光 12306 ，宝洁，三一重工这类企业都未必没有自研的 IT 系统，难度也许远比互联网企业的 CURD 高，但人家是几乎不会拿出来显摆的。只有互联网企业特别喜欢显摆自己 IT 方面的成就罢了。

我们当时是 .NET 8 + 兆芯 CPU + 统信 UOS 做服务器, 客户端用的深度 Deepin 操作系统, 界面用 Avalonia 做的.
数据库用的应该是人大金仓 (别提有多 sb 了, EFCore 支持不全). 整套从软件到硬件都是信创友好的.. 客户挑不出一点毛病....

买点儿黄瓜回去腌了。

@dufu 可以考虑鱼大的 SimpleUpdater. https://github.com/iccfish/FSLib.App.SimpleUpdater

Electron 可以考虑 electron-updater

@Nosub C# 客户端生态差？？？？？？？？？你这又是从哪儿听到的逆天言论？ 还 Java ？？？？？？大哥你认真的？？？？如果说 C# 做客户端生态还叫 "差" 的话，那 Java 那就可以视为没有了啊！怎么还有推荐用 Java 做客户端的？你怎么想的？

FFMpeg 、OpenCV 、SDL 、WebRTC 这些 nuget 上都有相关库啊？？？你到底用过没啊？我前段时间给自己家用树莓派做门禁的时候就用到了 FFMpeg 跟 OpenCV 。如果这些 C# 都不支持那我怎么做的？？

Electron 是首选。
别关心什么内存占用的问题。那不是你该关心的问题。除非涉及到 C++ 交互，否则 Electron 永远是不二之选。界面美观开发简单。没什么比 Electron 更合适的。

然后其次是 Avalonia 。性能强悍内存占用低，可 AOT 所以也不需要什么 .NET 环境。打包好了到处都能用。尤其涉及到界面复杂或者带动效/3D/图表的情况下，Avalonia 基本上可以说是唯一选择。

最后是 QT 。老牌 GUI 开发框架了。性能极其强悍，但是绑定 C++。对 C++ 熟悉的可以考虑。

没有可能.

只要你们公司存在人员流动, 功能更迭, 代码的腐化就是不可避免的. 任何的规范和制度都只不过是延缓其发生而已, 不可能避免. 很多很多的功能其实开发的时候, 功能描述里说的可能只是一个很简单的需求, 但是实际上开发的时候, 隐藏在里面的逻辑却可能是相当复杂的. 而这种复杂并不是一句两句话能说得清的. 而一旦编写这种复杂业务逻辑代码的人离职, 这段代码很可能就会变得难以维护. 就算是留下交接文档, 这种编写于几年前的复杂业务逻辑代码, 当事人也不一定会记得当时的逻辑细节. 更何况很多情况下人员并不是主动离职而是被辞退/优化掉的, 这种更是连交接的过程都不会有. 这种过程多来几次, 你的代码就基本没法儿看了.

@lujiaxing 效率。打错了

@jinxjhin 是的，直接位运算就可以了。不需要 IN. 单字段运算的线路永远是 IN 所不能比的，尤其 IN 的数量大时候

不是, CEF 是能独立存在的么? 它总有个宿主吧? 不是 WinForms 就是 WPF 啊!! 你要单独搞一个界面显示 WPF 的图表那你就单独建窗体呀! 跟 CEF 有什么关系呢?? 你们是用 CEFSharp 还是 chromiumfx ??

但无论如何这些都不是单独存在的, 都是要有宿主的...

你这不是 "+" "-" "=", 是 "从 '+' 到 '='"....

'1'.match(/[+\-=]/) 才对

@sadfQED2 那如果确实是已经 100% 完善了, BUG 清零了, 客户跟产品方面也暂时没有提到过什么新的需求, 那你们又要发什么