开发者对 .NET MAUI 很不满意，但团队里没人关心

.NET MAUI 的现状

• 许多评论者称 MAUI 不稳定且不成熟：跨平台布局不一致、基础控件行为异常、集合视图卡顿、随机的构建和部署失败，以及 MAUI 内部本身的崩溃或内存泄漏。
• 有些人描述，像下拉刷新、视频流、带视频的列表视图这类看似简单的功能，要花上数周却仍然失败，最后在其他框架里几天就重写完成。
• 具体坑点包括：Windows/iOS/macOS 构建中的路径问题、经常失效的调试、缓慢的迭代速度，以及带有模糊错误信息的长期存在的 bug。
• 底层原生绑定（尤其在 iOS 上）被认为不完整；较新的 Apple 框架和 Swift 库并没有得到完全支持。
• 一些人认为不支持 Linux 是立刻就会让人放弃的致命问题。

Microsoft 的策略和 dogfooding

• 反复出现的担忧是，Microsoft 并没有把 MAUI（或之前的 GUI 框架）用于自己主要的应用，而是大量依赖 Electron、React + WebView，或 Qt。
• 不少人把这看作一种模式：Microsoft 会宣传新的 UI 技术栈（WinForms、WPF、Silverlight、UWP、Xamarin、MAUI），但很少长期投入，也很少在内部广泛使用。
• 有人认为，如果 MAUI 没有处在 Microsoft 自己的“关键路径”上，它就不太可能得到足够稳健的资金支持或维护。

替代方案与建议

• 很多人强烈建议避免 MAUI，通常也避免在新项目中使用所有 Microsoft UI 框架。
• 推荐的替代方案包括：
  • Web 技术（纯 Web + MDN、Electron、React 等），因为它们演进最活跃，生态最丰富（CSS、JS API、d3 风格工具链）。
  • 面向 .NET 的 Avalonia 和 Uno Platform；如果只做 Windows 桌面，则可选 WPF。
  • Flutter、React Native、Qt，以及其他方案，具体取决于需求。
• 一些团队放弃 Xamarin/MAUI，转而使用原生移动应用或其他跨平台技术栈，并报告总体节省了时间。

社区关系与 issue 处理

• 有人抱怨严重的基础 bug 会挂上好几年却几乎看不到进展；PR 据称长期无人审查。
• 一个高关注度的 GitHub issue 被移到 “Discussions”，被视为轻慢，即使底层 bug 仍然在别处被跟踪。
• 讨论中的分歧：
  • 一方认为抱怨的语气没有建设性，而且团队不可能同等关注成千上万个 issue。
  • 另一方则认为，用户等待多年后提出不满是合理的，尤其当 MAUI 被宣传为可用于生产，并且背后有一家巨头公司支持时。

更广泛的 Microsoft 工具与 QA 担忧

• 一些评论者把 MAUI 的问题泛化到 Microsoft 更大的生态：
  • 过去对 Windows Phone、UWP、Xamarin、Blazor Server、Azure DevOps 以及各种 API 的体验，都被认为是半成品或已被放弃。
  • 有人声称某些 Microsoft 产品（例如 Azure DevOps）似乎正在停滞，因为注意力转向了重叠的产品（例如 GitHub）。
• 有一条讨论提到，Microsoft 过去裁掉了大量 QA，转而依赖外包人员和敏捷流程；这被归咎于 bug 漏网，同时缺少探索式测试或对开发者体验的倡导。

跨平台 UI 的挑战

• 有人指出，跨平台原生 UI 框架本来就很难：额外的抽象层会增加 bug 的可能性，尤其是在小团队中。
• 建议是：在语言无关的库中共享业务逻辑，并尽可能保持 UI 原生或更简单。
• 少数人询问 React Native 或其他技术栈是否也会遇到类似痛苦；回应不一，但在这条讨论中，MAUI 普遍被认为比竞争对手更糟。