做.NET客户端开发的朋友这两年应该没少听到.NET MAUI这个名字。不管是新项目选型还是老项目从Xamarin.Forms迁移最终都会绕到同一个问题上MAUI各个版本到底都有啥用我见过太多人一上来就选.NET 8结果发现公司内部还有一堆.NET 6的老工程要兼容也有人盯着.NET 9的新特性却忽略了它并不是长期支持版本项目上线到一半就得被迫做版本升级规划。先说结论MAUI的“版本”其实可以从三个维度拆开看。第一个维度是.NET大版本也就是.NET 6、7、8、9它们决定了你的技术栈能用到哪些新特性、修了哪些底层问题、支持周期有多久第二个维度是目标平台版本比如Android、iOS、Windows、macOS各自需要的SDK版本和编译条件第三个维度是开发形态也就是你用原生XAML、Blazor Hybrid还是从旧工程迁移过来——这三种玩法对应的版本要求完全不同。把这三层彻底搞明白你对MAUI的“各版本”才算真正吃透了。这篇文章我不想写官方文档那种干巴巴的版本说明就按我自己做实际项目的经验把这三个维度拆开逐一讲清楚顺带分享一路踩过的坑和最后总结出的选型建议。1. 先把MAUI的“版本”这事理清楚1.1 MAUI到底是什么怎么和Xamarin.Forms扯上的关系.NET MAUI的全称是.NET Multi-platform App UI是微软在.NET 6时代推出的跨平台UI框架用来替代老牌的Xamarin.Forms。它解决的问题一直没变过让开发团队用一套C#代码和一套XAML界面同时构建Android、iOS、Windows、macOS四个平台的客户端应用。打个比方你就明白了。以前用Xamarin.Forms做跨平台一个Android项目、一个iOS项目、一个共享库界面代码虽然大体能共享但项目管理、资源文件、平台通道的配置都是各搞各的就像同一道菜在好几个厨房里分别开火做配方一致但每个厨房的灶台、锅具、上菜流程全都不一样。MAUI的做法是直接改成中央厨房概念一个工程同时包含所有目标平台的编译配置和资源目录打开一个解决方案子目录里就是Platforms/Android、Platforms/iOS、Platforms/Windows这些文件夹界面和业务逻辑共享在一处只有真正涉及平台差异的代码才放到对应平台目录里。所以很多人把MAUI理解成“Xamarin.Forms换了个名字”这话只对了一半。底层的基础架构确实有很多传承比如Page、Layout、控件体系的思路几乎一脉相承但工程结构、渲染机制、依赖注入方式、生命周期处理已经完全翻新。这也就直接导致了后面那个问题旧的Xamarin.Forms项目不能无脑升级版本的鸿沟真实存在。1.2 看版本最容易搞混的地方三个版本号千万别弄错很多新手第一次接触MAUI时打开NuGet包管理器会看到Microsoft.Maui.Controls、Microsoft.Maui.Core这些包版本是7.0.x、8.0.x再看看自己的csproj文件里写的是net8.0-android然后又去微软官网看到.NET 8 LTS的说法三个数字在脑子里完全对不上号。这里给你一个最省心的理解方法.NET大版本号比如.NET 6、.NET 7、.NET 8决定整体基础类库、语言版本、运行时能力。MAUI包版本基本和.NET大版本同步比如.NET 8对应的MAUI包就是8.0.x无需单独记忆。TargetFramework平台版本csproj里的net8.0-android、net8.0-ios这些后半段代表具体目标平台前半段就是对应的.NET大版本。所谓“用哪个MAUI版本”核心就是给csproj里设置哪个TargetFramework。一个典型的多目标工程长这样TargetFrameworksnet8.0-android;net8.0-ios;net8.0-maccatalyst/TargetFrameworks TargetFrameworks Condition$([MSBuild]::IsOSPlatform(windows))$(TargetFrameworks);net8.0-windows10.0.19041.0/TargetFrameworks我在项目评审时见过不少人在这上面栽跟头Windows条件编译那段没看清楚结果团队里用macOS的开发者和用Windows的开发者拿到同一个工程生成的TargetFramework列表都不一样最后为环境不一致排查了好几天。记住MAUI是单工程多目标平台版本差异是通过条件编译和平台文件夹共同管理的这是理解“各版本有啥用”的基础中的基础。2. 按时间线走一遍从.NET 6到.NET 9每个版本到底解决了什么2.1 .NET 6MAUI的出生证能跑但别指望完美.NET 6于2022年5月正式发布MAUI作为Xamarin.Forms的接班人也算正式转正。这个版本的意义在于从无到有把单工程结构、Hot Reload热重载、Shell导航、Handler渲染机制这些核心骨架定了下来。但实际用它做过项目的人都懂.NET 6时代的MAUI粗糙的地方一抓一大把。最典型的是Windows平台那时候Windows App SDK和MAUI的版本对齐还在磨合期动不动就遇到启动白屏、资源加载失败、控件渲染异常。Android平台的性能也谈不上好列表滚动掉帧、启动速度偏慢都是正常操作。我记得当时做个简单的列表页在低端Android机上滑动起来能明显感到卡顿优化半天也只能说是“勉强能看”。.NET 6的定位就是个奠基版本。最适合的场景是两个一是技术团队想提前验证MAUI的可行性用一个小Demo跑通全流程二是有充足时间做二次封装和性能调优的团队。如果你是在2025年的今天才准备启动新项目我不会建议你再选.NET 6因为它的支持周期已经在2024年11月结束了这意味着安全更新和关键修复都已经停止风险完全暴露。2.2 .NET 7从“能用”到“好用”的过渡版本.NET 7在2022年11月发布距今已经过了主流支持期2024年5月就结束了生命周期。但它作为过渡版本贡献其实是实打实的。这个版本的重点是把.NET 6时期遗留的稳定性问题收拾了一遍。Android平台的兼容性大幅提升修复了一大批特定国产ROM上的崩溃问题Windows平台与WinUI 3的配合也顺了很多BlazorWebView正式成为MAUI的常规控件这意味着你可以在原生MAUI壳里运行Blazor组件后来大名鼎鼎的Blazor Hybrid混合开发模式就是从这里起来的。另外.NET 7的MAUI还在性能上做了不少文章布局计算、绑定链路、控件初始化都有优化。我个人的感受是同样一套代码从.NET 6升到.NET 7启动时间和列表流畅度都有可感知的提升。不过.NET 7也有自己的尴尬之处它是个STS短期支持版本生命周期太短加上前面有.NET 6后面有.NET 8它夹在中间就像一个过渡桥梁。除非你的项目因为某种依赖限制只能停在.NET 7否则我不会主动推荐你现在入坑。它的最大价值在于历史参照让你知道MAUI的成熟曲线是怎么走过来的。2.3 .NET 8LTS版本正式“转正”的分水岭如果你问我当前最稳妥的选择是什么我的答案永远是.NET 8。它是MAUI历史上第一个真正意义上的长期支持版本支持周期到2026年11月整整三年比STS版本多出一大截安全窗口。.NET 8的MAUI不像前两个版本那样在架构上大动干戈而是把精力集中在“把细节磨圆”。Android 14的API支持、iOS 17的适配、可访问性的全面增强、MVVM Toolkit的深度集成、控件渲染的一致性修复这些都是实打实的生产级改进。我拿同一套业务代码在.NET 7和.NET 8上分别跑过对照测试最直观的感受是.NET 8在Android上的内存占用明显更稳定长时间运行不崩WebView混用场景下的渲染穿透问题也罕见很多。还有一个容易被低估的点.NET 8统一了对Windows App SDK的版本要求解决了之前头疼的版本冲突问题。Windows平台上MAUI程序跑起来不再像以前那样敏感MSIX打包和旁加载都顺滑得多。对新项目我的意见很简单默认.NET 8起步这是目前权衡稳定性、支持周期、生态兼容性之后的最优解。2.4 .NET 9新特性尝鲜者的选择但不是谁都能上.NET 9于2024年11月发布是STS版本主流支持到2026年5月。这个版本的MAUI在性能上又卯足了劲Android端强化了AOT预编译支持iOS端的启动速度和内存占用也有明显优化Windows App SDK升级到了1.6对最新移动平台特性的跟随也更积极比如Android 15和iOS 18的适配很早就进入了计划。.NET 9比较适合那些对最新平台API有硬需求的团队。比如你的产品必须用到iOS 18的某个新系统能力或者目标是要在Android 15的新特性上做差异化体验那.NET 9能让你更快用上这些能力。但对多数业务型App来说.NET 9带来的增值感受其实有限因为MAUI本身的控件层迭代已经趋缓性能提升是渐进式的不是质变的。这里尤其要提醒STS版本的痛点就在生命周期短。如果你现在拿.NET 9开新项目意味着到2026年中就必须规划升级到.NET 10这个节奏对团队的管理成本是不小的负担。除非你有专门负责升级维护的平台组否则我更建议继续留在.NET 8等.NET 10这个未来LTS版本出来后再做跳跃式升级。.NET版本发布时间支持类型结束支持MAUI总体评价适合场景.NET 62022.05LTS2024.11奠基粗糙历史项目/技术验证.NET 72022.11STS2024.05过渡稳定历史项目/迁移跳板.NET 82023.11LTS2026.11生产成熟新项目首选.NET 92024.11STS2026.05性能增强最新API强依赖场景3. 目标平台版本的差异Android、iOS、Windows各自的门道3.1 AndroidMAUI真正的主战场版本碎片化是最现实的敌人Android在MAUI生态里地位特殊。一方面Android设备的数量基数最大大部分MAUI项目的首要发布目标都是Android另一方面Android的版本碎片化问题又是所有平台里最突出的。MAUI的Android目标框架写法通常是net8.0-android明确了要使用的Android SDK版本。实际操作中csproj里还有两个容易搞混的属性SupportedOSPlatformVersion和TargetPlatformVersion。前者是你声明的最低支持版本比如你的App要兼容Android 7.0API 24就在这里声明24后者是编译目标版本一般需要声明为较新的API级别比如34或35用来获取最新的平台行为和新API支持。合理设置这两个值编译期能自动帮你拦住不少误用新API的隐患。我强烈建议在MAUI项目里养成一种习惯写平台相关代码时优先使用DeviceInfo、Version之类的抽象封装少直接判断Android版本号。因为MAUI的控件在底层是Handler机制很多行为差异已经被框架抹平你要是绕过封装去写平台分支等于自己给自己挖坑。真遇到必须区别对待的场景用OnPlatform或者在Platforms/Android目录下写平台类比任何花哨的判断都干净。发布环节也有版本问题。Android包体积和ABI拆分是要提前规划的事。MAUI默认会打出包含多种CPU架构的包体积直接膨胀到上百MB。建议在产品发布前就把构建配置拆好按arm64、armeabi-v7a、x86_64分别出包或者用App Bundle打包让应用商店按需分发。这一步不做你的包体在中小型公司审核时百分百被质疑。3.2 iOS与Mac Catalyst苹果生态里一套逻辑两副面孔MAUI的iOS目标框架是net8.0-ios对应的是iOS SDK版本比如17.0、18.0。苹果生态的优势在于机型远不如Android杂但代价是真机联调必须依赖Mac环境和签名配置这一道坎就被不少Windows为主的团队卡住了。还有一个经常被忽略的角色叫Mac Catalyst。它允许你把iOS应用编译成一个能在macOS上运行的版本框架写法是net8.0-maccatalyst。这玩意儿适合什么场景比如你已经有一个MAUI的iOS应用想快速出一个macOS桌面版且UI交互不需要做太大调整那么Mac Catalyst是最低成本方案。但如果你的桌面版是重工具类型需要多窗口、复杂菜单栏、丰富的快捷键体系那就别守着Catalyst硬做老老实实单独建一个Windows/macOS原生UI工程还更省事。做iOS版本时最典型的坑在签名和权限描述。MAUI项目中Info.plist里的权限说明字符串如果写得不够清楚真机上会直接拒绝访问相册或定位而开发签名和发布签名不匹配则会在提审时收到一堆莫名其妙的报错。这些属于经验问题碰到一次处理一次第二次基本就能提前规避了。3.3 WindowsWinUI 3是底层宿主版本匹配决定成败MAUI的Windows版本目标框架写法是net8.0-windows10.0.19041.0。后半段那一长串是Windows SDK版本19041对应Windows 10 2004。这不是说你只能在老Windows上运行而是代表编译时使用的最低Windows API协定版本。Windows平台MAUI底层直接构建在WinUI 3之上这意味着Windows App SDK的版本约束会一路传递到你的工程里。我踩过最深的坑是某个第三方库引用了更高版本的Windows App SDK导致MAUI项目启动时直接弹窗报错查了半天才发现是SDK版本冲突。解决方案要么升级MAUI补丁版本要么给特定依赖做版本统一覆盖。这属于典型的本平台版本兼容性问题Windows上尤其常见。发布Windows版本时MSIX打包是推荐方式支持自动更新、权限声明、安装卸载干净彻底。代价是这个格式在分发上比较折腾企业内部用还好对外给用户直接下载安装就得配合代码签名证书。如果没签名的MSIX包用户第一次安装时必须手动绕过SmartScreen这个体验对非技术用户很不友好。如果你要的是直下直用的绿色软件体验那可能还是要走旁加载或者免安装模式但这又会牺牲一部分系统集成能力。3.4 Linux、Tizen与其他平台社区力量能给你意外惊喜官方支持的平台就是前面那几个但MAUI的开源生态额外带来了两个特殊选项。一是Tizen三星主导的智能设备系统在智能电视、家电设备上都有布局。MAUI对Tizen有官方支持渠道虽然受众面窄但在特定行业的IoT场景里一套C#代码能同时覆盖手机、电视、设备屏这种跨端能力非常有吸引力。二是Linux这属于社区驱动既有基于GTK的GirCore实现也有Gallium等实验性项目。稳定性和控件完整度都有限生产环境上真要用得掂量清楚。我的意见是如果项目里Linux只是辅助分发目标可以试如果Linux是重头戏那现阶段还是别指望MAUI了老老实实考虑Electron或者Avalonia更实际。4. 开发形态的“版本”选择原生XAML、Blazor Hybrid还是迁移工程4.1 原生XAML形态MAUI的标准打开方式大多数MAUI项目都是原生XAML形态也就是用XAML描述界面用C#写业务逻辑通过数据绑定和MVVM模式把两层接起来。这种形态的好处是框架的文档、示例、控件生态最齐全遇到问题能找到最多的参考。原生XAML的版本关注点主要在于控制台版本尽量跟随最新稳定版不要长期停留在老补丁上。因为我观察到一个很有意思的规律MAUI的补丁版本常常会夹带对特定平台行为的修正比如Android 15发布后老版本MAUI在Android 15设备上可能出现布局偏移而更新补丁版本后问题自动消失。这算是版本管理里最划算的低成本维护。4.2 Blazor Hybrid形态Web团队跨界移动端的捷径Blazor Hybrid是MAUI提供的另一种开发形态界面用Razor组件编写逻辑用C#UI渲染由WebView承载。它与Blazor WebAssembly的区别在于代码在本地进程跑不依赖浏览器沙箱可以直接调用底层设备能力这让纯前端团队切入MAUI的成本一下子降了很多。选择Blazor Hybrid的关键版本考量是CSProj里对Microsoft.AspNetCore.Components.WebView包的引用这个包必须和MAUI主版本匹配。有次我把.NET 8的MAUI工程加了BlazorWebView包版本却还是7.0的结果运行时报一堆类型转换错误。这种版本错配问题在混合开发里尤其容易发生因为涉及的技术栈更多了。Blazor Hybrid形态特别适合那种团队以C#和Web技术为主、没有专门XAML工程师的场景。愿意牺牲一点控件渲染的原生感换来团队开发效率的大幅提升这笔账对很多中小团队是划算的。4.3 Xamarin.Forms迁移到MAUI版本跳跃里的隐形风险从Xamarin.Forms迁移到MAUI本质上是一次跨大版本的架构升级。官方推荐的路径是先升级到Xamarin.Forms 5.x然后转到.NET 7或.NET 8对应的MAUI版本最后清理兼容代码。这个过程中最容易被低估的是命名空间和API签名变化。Xamarin.Forms里的Xamarin.Forms.命名空间要替换成Microsoft.Maui.不少控件属性的行为细节也有微妙变化。渲染器Renderer被Handler替代是最核心的架构差异如果你在Xamarin.Forms里大量使用了自定义Renderer做控件扩展迁移时几乎都得重写。依赖注入也是重灾区Xamarin.Forms的DependencyService在MAUI里被更完整的DI容器取代用法完全变了。我的建议是迁移前先跑一遍官方的迁移工具把基础命名空间替换和项目结构调整自动处理掉但要预留至少一多半的时间去处理自定义渲染器、第三方控件兼容和平台特化代码。版本跳跃越狠手工作业量越大这是跑不掉的。5. 实操选型与踩坑盘点几个真实有效的经验之谈5.1 新项目选版本我一直在用的判断逻辑每次做MAUI技术选型我都会按一个固定的优先级清单来筛先看目标平台的系统版本要求再看第三方库的兼容性然后是团队技能栈最后才是对最新特性的渴望程度。具体来说如果客户明确要求支持Android 7.0以下的老设备你就不光要选旧一点的SDK声明还得注意.NET版本对新API的裁剪问题这种时候选.NET 8依旧稳妥。如果第三方库只有旧版包你就得顺着它的依赖反推MAUI版本强行用新版本反而会陷入无休止的包冲突。团队里全是XAML熟手那Blazor Hybrid再好也不该是首选因为价值发挥不出来。完整版判断逻辑我整理成了一张表项目特征推荐版本/形态理由企业级新项目无特殊API需求.NET 8 原生XAML稳定、支持周期长项目要求最新iOS/Android系统能力.NET 9 原生XAML新API适配最快团队以Web技术为主.NET 8 Blazor Hybrid降低学习成本老Xamarin.Forms项目迁移.NET 8为主跳板工具链和依赖最成熟需要覆盖智能电视等特殊设备基础.MAUI Tizen扩展官方渠道支持目标包含Linux且占比高暂不建议MAUI社区实现不够可靠这套逻辑我用在好几个项目的选型评审里不能说百分之百正确但至少不会让你在第一步就翻车。5.2 实际生产环境里我踩过的版本相关坑列几个印象最深的每一个都是真金白银换来的教训。第一个是Windows App SDK版本冲突。某个项目里引入了第三方地图控件它内部依赖更高版本的Windows App SDK结果MAUI工程启动时直接抛异常窗口都弹不出来。最后通过查看启动日志里的WinUI版本信息把MAUI补丁升了三级才解决。建议所有Windows目标项目建立初期就锁定Windows App SDK的版本并记录在项目文档里。第二个是Android打包ABI导致包体爆炸。默认配置下MAUI会打出包含arm64和x86_64等所有架构的包一个简单App安装包就要逼近150MB。后来我把每个目标框架单独配置RuntimeIdentifiers按架构拆包分发包体直接降到了50MB左右。这种差异在选型评审阶段根本想不到但真正发布时就是致命问题。第三个是iOS模拟器与真机行为不一致。MAUI的iOS版本在模拟器上表现良好但真机上却可能因为AOT裁剪而出现类型丢失某些反射功能直接不可用。解决方法是使用NativeAOT时仔细配置裁剪白名单或者在csproj里关闭不必要的裁剪选项。这个坑对测试安排的影响很大因为很多团队习惯只在模拟器上测。第四个是.NET 6工程升级到.NET 8时Android的WebView行为发生了变化。旧版缓存策略在新版里导致部分H5页面无法正常加载。这类问题没有明显的报错只能通过联调时逐一排查页面表现才能发现。升级版本时务必把核心业务页面的回归测试用例准备充分尤其是涉及WebView和地图控件的页面。5.3 升级MAUI版本的正确姿势按这个顺序做能少熬夜很多团队升级版本是直接改TargetFramework然后编译报错了再逐个修。这种打地鼠式做法效率极低。我建议按下面这个顺序来第一步先查.NET版本对应MAUI包的最新补丁版本把csproj里的PackageReference升级到目标补丁。第二步用.NET Upgrade Assistant工具做一次整体扫描它能自动识别多数需要替换的API和命名空间。第三步检查所有第三方NuGet包的版本兼容性矩阵重点看依赖Windows App SDK的包优先处理版本强约束的依赖。第四步按Android、iOS、Windows的顺序分平台构建验证每个平台单独处理编译错误和运行时问题不要一次全平台一起编否则错误混在一起很难定位。第五步做一次全功能的回归测试尤其是平台特化代码所在的页面并观察不同系统版本设备上的实际表现。这套流程下来升级MAUI版本虽然不能保证零失眠但至少能让你对照步骤有序排查而不是在编译器的红色波浪线里迷失方向。最后再分享一点个人的实际体会做MAUI项目做了这几年我最大的感受是版本这东西不像很多人想的那么高深。它背后就是一组现实约束的折中生命周期长短、系统版本覆盖、团队技术储备、第三方生态的适配程度。把这些约束一项项摊开来看版本选择其实就是一道排列组合题。我现在做新项目默认不看别的直接落在.NET 8这个长期支持版本上然后按目标平台的具体SDK要求把TargetFramework配齐。只有遇到那种明确要尝鲜新系统能力的特殊需求我才会考虑往.NET 9走而且一定会在项目启动前就把后续升级到.NET 10的路线图和时间成本算进去。还有一个小技巧分享一下你在csproj里写TargetFrameworks的时候最好把SupportedOSPlatformVersion的注释写在旁边写清楚每个最低版本是怎么定出来的。这个习惯帮我避免过好几次自己给自己挖坑几个月后回来看代码忘了当初为什么定那个版本结果改了个版本号把兼容性破坏了。如果你能坚持这个习惯版本管理这事基本就不会再给你添乱了。 
长河君 · 2026/10/10 1:54:36 · 阅读 1.2k .NET MAUI版本详解：从.NET 6到.NET 9的选型与迁移指南
做.NET客户端开发的朋友这两年应该没少听到.NET MAUI这个名字。不管是新项目选型还是老项目从Xamarin.Forms迁移最终都会绕到同一个问题上MAUI各个版本到底都有啥用我见过太多人一上来就选.NET 8结果发现公司内部还有一堆.NET 6的老工程要兼容也有人盯着.NET 9的新特性却忽略了它并不是长期支持版本项目上线到一半就得被迫做版本升级规划。先说结论MAUI的“版本”其实可以从三个维度拆开看。第一个维度是.NET大版本也就是.NET 6、7、8、9它们决定了你的技术栈能用到哪些新特性、修了哪些底层问题、支持周期有多久第二个维度是目标平台版本比如Android、iOS、Windows、macOS各自需要的SDK版本和编译条件第三个维度是开发形态也就是你用原生XAML、Blazor Hybrid还是从旧工程迁移过来——这三种玩法对应的版本要求完全不同。把这三层彻底搞明白你对MAUI的“各版本”才算真正吃透了。这篇文章我不想写官方文档那种干巴巴的版本说明就按我自己做实际项目的经验把这三个维度拆开逐一讲清楚顺带分享一路踩过的坑和最后总结出的选型建议。1. 先把MAUI的“版本”这事理清楚1.1 MAUI到底是什么怎么和Xamarin.Forms扯上的关系.NET MAUI的全称是.NET Multi-platform App UI是微软在.NET 6时代推出的跨平台UI框架用来替代老牌的Xamarin.Forms。它解决的问题一直没变过让开发团队用一套C#代码和一套XAML界面同时构建Android、iOS、Windows、macOS四个平台的客户端应用。打个比方你就明白了。以前用Xamarin.Forms做跨平台一个Android项目、一个iOS项目、一个共享库界面代码虽然大体能共享但项目管理、资源文件、平台通道的配置都是各搞各的就像同一道菜在好几个厨房里分别开火做配方一致但每个厨房的灶台、锅具、上菜流程全都不一样。MAUI的做法是直接改成中央厨房概念一个工程同时包含所有目标平台的编译配置和资源目录打开一个解决方案子目录里就是Platforms/Android、Platforms/iOS、Platforms/Windows这些文件夹界面和业务逻辑共享在一处只有真正涉及平台差异的代码才放到对应平台目录里。所以很多人把MAUI理解成“Xamarin.Forms换了个名字”这话只对了一半。底层的基础架构确实有很多传承比如Page、Layout、控件体系的思路几乎一脉相承但工程结构、渲染机制、依赖注入方式、生命周期处理已经完全翻新。这也就直接导致了后面那个问题旧的Xamarin.Forms项目不能无脑升级版本的鸿沟真实存在。1.2 看版本最容易搞混的地方三个版本号千万别弄错很多新手第一次接触MAUI时打开NuGet包管理器会看到Microsoft.Maui.Controls、Microsoft.Maui.Core这些包版本是7.0.x、8.0.x再看看自己的csproj文件里写的是net8.0-android然后又去微软官网看到.NET 8 LTS的说法三个数字在脑子里完全对不上号。这里给你一个最省心的理解方法.NET大版本号比如.NET 6、.NET 7、.NET 8决定整体基础类库、语言版本、运行时能力。MAUI包版本基本和.NET大版本同步比如.NET 8对应的MAUI包就是8.0.x无需单独记忆。TargetFramework平台版本csproj里的net8.0-android、net8.0-ios这些后半段代表具体目标平台前半段就是对应的.NET大版本。所谓“用哪个MAUI版本”核心就是给csproj里设置哪个TargetFramework。一个典型的多目标工程长这样TargetFrameworksnet8.0-android;net8.0-ios;net8.0-maccatalyst/TargetFrameworks TargetFrameworks Condition$([MSBuild]::IsOSPlatform(windows))$(TargetFrameworks);net8.0-windows10.0.19041.0/TargetFrameworks我在项目评审时见过不少人在这上面栽跟头Windows条件编译那段没看清楚结果团队里用macOS的开发者和用Windows的开发者拿到同一个工程生成的TargetFramework列表都不一样最后为环境不一致排查了好几天。记住MAUI是单工程多目标平台版本差异是通过条件编译和平台文件夹共同管理的这是理解“各版本有啥用”的基础中的基础。2. 按时间线走一遍从.NET 6到.NET 9每个版本到底解决了什么2.1 .NET 6MAUI的出生证能跑但别指望完美.NET 6于2022年5月正式发布MAUI作为Xamarin.Forms的接班人也算正式转正。这个版本的意义在于从无到有把单工程结构、Hot Reload热重载、Shell导航、Handler渲染机制这些核心骨架定了下来。但实际用它做过项目的人都懂.NET 6时代的MAUI粗糙的地方一抓一大把。最典型的是Windows平台那时候Windows App SDK和MAUI的版本对齐还在磨合期动不动就遇到启动白屏、资源加载失败、控件渲染异常。Android平台的性能也谈不上好列表滚动掉帧、启动速度偏慢都是正常操作。我记得当时做个简单的列表页在低端Android机上滑动起来能明显感到卡顿优化半天也只能说是“勉强能看”。.NET 6的定位就是个奠基版本。最适合的场景是两个一是技术团队想提前验证MAUI的可行性用一个小Demo跑通全流程二是有充足时间做二次封装和性能调优的团队。如果你是在2025年的今天才准备启动新项目我不会建议你再选.NET 6因为它的支持周期已经在2024年11月结束了这意味着安全更新和关键修复都已经停止风险完全暴露。2.2 .NET 7从“能用”到“好用”的过渡版本.NET 7在2022年11月发布距今已经过了主流支持期2024年5月就结束了生命周期。但它作为过渡版本贡献其实是实打实的。这个版本的重点是把.NET 6时期遗留的稳定性问题收拾了一遍。Android平台的兼容性大幅提升修复了一大批特定国产ROM上的崩溃问题Windows平台与WinUI 3的配合也顺了很多BlazorWebView正式成为MAUI的常规控件这意味着你可以在原生MAUI壳里运行Blazor组件后来大名鼎鼎的Blazor Hybrid混合开发模式就是从这里起来的。另外.NET 7的MAUI还在性能上做了不少文章布局计算、绑定链路、控件初始化都有优化。我个人的感受是同样一套代码从.NET 6升到.NET 7启动时间和列表流畅度都有可感知的提升。不过.NET 7也有自己的尴尬之处它是个STS短期支持版本生命周期太短加上前面有.NET 6后面有.NET 8它夹在中间就像一个过渡桥梁。除非你的项目因为某种依赖限制只能停在.NET 7否则我不会主动推荐你现在入坑。它的最大价值在于历史参照让你知道MAUI的成熟曲线是怎么走过来的。2.3 .NET 8LTS版本正式“转正”的分水岭如果你问我当前最稳妥的选择是什么我的答案永远是.NET 8。它是MAUI历史上第一个真正意义上的长期支持版本支持周期到2026年11月整整三年比STS版本多出一大截安全窗口。.NET 8的MAUI不像前两个版本那样在架构上大动干戈而是把精力集中在“把细节磨圆”。Android 14的API支持、iOS 17的适配、可访问性的全面增强、MVVM Toolkit的深度集成、控件渲染的一致性修复这些都是实打实的生产级改进。我拿同一套业务代码在.NET 7和.NET 8上分别跑过对照测试最直观的感受是.NET 8在Android上的内存占用明显更稳定长时间运行不崩WebView混用场景下的渲染穿透问题也罕见很多。还有一个容易被低估的点.NET 8统一了对Windows App SDK的版本要求解决了之前头疼的版本冲突问题。Windows平台上MAUI程序跑起来不再像以前那样敏感MSIX打包和旁加载都顺滑得多。对新项目我的意见很简单默认.NET 8起步这是目前权衡稳定性、支持周期、生态兼容性之后的最优解。2.4 .NET 9新特性尝鲜者的选择但不是谁都能上.NET 9于2024年11月发布是STS版本主流支持到2026年5月。这个版本的MAUI在性能上又卯足了劲Android端强化了AOT预编译支持iOS端的启动速度和内存占用也有明显优化Windows App SDK升级到了1.6对最新移动平台特性的跟随也更积极比如Android 15和iOS 18的适配很早就进入了计划。.NET 9比较适合那些对最新平台API有硬需求的团队。比如你的产品必须用到iOS 18的某个新系统能力或者目标是要在Android 15的新特性上做差异化体验那.NET 9能让你更快用上这些能力。但对多数业务型App来说.NET 9带来的增值感受其实有限因为MAUI本身的控件层迭代已经趋缓性能提升是渐进式的不是质变的。这里尤其要提醒STS版本的痛点就在生命周期短。如果你现在拿.NET 9开新项目意味着到2026年中就必须规划升级到.NET 10这个节奏对团队的管理成本是不小的负担。除非你有专门负责升级维护的平台组否则我更建议继续留在.NET 8等.NET 10这个未来LTS版本出来后再做跳跃式升级。.NET版本发布时间支持类型结束支持MAUI总体评价适合场景.NET 62022.05LTS2024.11奠基粗糙历史项目/技术验证.NET 72022.11STS2024.05过渡稳定历史项目/迁移跳板.NET 82023.11LTS2026.11生产成熟新项目首选.NET 92024.11STS2026.05性能增强最新API强依赖场景3. 目标平台版本的差异Android、iOS、Windows各自的门道3.1 AndroidMAUI真正的主战场版本碎片化是最现实的敌人Android在MAUI生态里地位特殊。一方面Android设备的数量基数最大大部分MAUI项目的首要发布目标都是Android另一方面Android的版本碎片化问题又是所有平台里最突出的。MAUI的Android目标框架写法通常是net8.0-android明确了要使用的Android SDK版本。实际操作中csproj里还有两个容易搞混的属性SupportedOSPlatformVersion和TargetPlatformVersion。前者是你声明的最低支持版本比如你的App要兼容Android 7.0API 24就在这里声明24后者是编译目标版本一般需要声明为较新的API级别比如34或35用来获取最新的平台行为和新API支持。合理设置这两个值编译期能自动帮你拦住不少误用新API的隐患。我强烈建议在MAUI项目里养成一种习惯写平台相关代码时优先使用DeviceInfo、Version之类的抽象封装少直接判断Android版本号。因为MAUI的控件在底层是Handler机制很多行为差异已经被框架抹平你要是绕过封装去写平台分支等于自己给自己挖坑。真遇到必须区别对待的场景用OnPlatform或者在Platforms/Android目录下写平台类比任何花哨的判断都干净。发布环节也有版本问题。Android包体积和ABI拆分是要提前规划的事。MAUI默认会打出包含多种CPU架构的包体积直接膨胀到上百MB。建议在产品发布前就把构建配置拆好按arm64、armeabi-v7a、x86_64分别出包或者用App Bundle打包让应用商店按需分发。这一步不做你的包体在中小型公司审核时百分百被质疑。3.2 iOS与Mac Catalyst苹果生态里一套逻辑两副面孔MAUI的iOS目标框架是net8.0-ios对应的是iOS SDK版本比如17.0、18.0。苹果生态的优势在于机型远不如Android杂但代价是真机联调必须依赖Mac环境和签名配置这一道坎就被不少Windows为主的团队卡住了。还有一个经常被忽略的角色叫Mac Catalyst。它允许你把iOS应用编译成一个能在macOS上运行的版本框架写法是net8.0-maccatalyst。这玩意儿适合什么场景比如你已经有一个MAUI的iOS应用想快速出一个macOS桌面版且UI交互不需要做太大调整那么Mac Catalyst是最低成本方案。但如果你的桌面版是重工具类型需要多窗口、复杂菜单栏、丰富的快捷键体系那就别守着Catalyst硬做老老实实单独建一个Windows/macOS原生UI工程还更省事。做iOS版本时最典型的坑在签名和权限描述。MAUI项目中Info.plist里的权限说明字符串如果写得不够清楚真机上会直接拒绝访问相册或定位而开发签名和发布签名不匹配则会在提审时收到一堆莫名其妙的报错。这些属于经验问题碰到一次处理一次第二次基本就能提前规避了。3.3 WindowsWinUI 3是底层宿主版本匹配决定成败MAUI的Windows版本目标框架写法是net8.0-windows10.0.19041.0。后半段那一长串是Windows SDK版本19041对应Windows 10 2004。这不是说你只能在老Windows上运行而是代表编译时使用的最低Windows API协定版本。Windows平台MAUI底层直接构建在WinUI 3之上这意味着Windows App SDK的版本约束会一路传递到你的工程里。我踩过最深的坑是某个第三方库引用了更高版本的Windows App SDK导致MAUI项目启动时直接弹窗报错查了半天才发现是SDK版本冲突。解决方案要么升级MAUI补丁版本要么给特定依赖做版本统一覆盖。这属于典型的本平台版本兼容性问题Windows上尤其常见。发布Windows版本时MSIX打包是推荐方式支持自动更新、权限声明、安装卸载干净彻底。代价是这个格式在分发上比较折腾企业内部用还好对外给用户直接下载安装就得配合代码签名证书。如果没签名的MSIX包用户第一次安装时必须手动绕过SmartScreen这个体验对非技术用户很不友好。如果你要的是直下直用的绿色软件体验那可能还是要走旁加载或者免安装模式但这又会牺牲一部分系统集成能力。3.4 Linux、Tizen与其他平台社区力量能给你意外惊喜官方支持的平台就是前面那几个但MAUI的开源生态额外带来了两个特殊选项。一是Tizen三星主导的智能设备系统在智能电视、家电设备上都有布局。MAUI对Tizen有官方支持渠道虽然受众面窄但在特定行业的IoT场景里一套C#代码能同时覆盖手机、电视、设备屏这种跨端能力非常有吸引力。二是Linux这属于社区驱动既有基于GTK的GirCore实现也有Gallium等实验性项目。稳定性和控件完整度都有限生产环境上真要用得掂量清楚。我的意见是如果项目里Linux只是辅助分发目标可以试如果Linux是重头戏那现阶段还是别指望MAUI了老老实实考虑Electron或者Avalonia更实际。4. 开发形态的“版本”选择原生XAML、Blazor Hybrid还是迁移工程4.1 原生XAML形态MAUI的标准打开方式大多数MAUI项目都是原生XAML形态也就是用XAML描述界面用C#写业务逻辑通过数据绑定和MVVM模式把两层接起来。这种形态的好处是框架的文档、示例、控件生态最齐全遇到问题能找到最多的参考。原生XAML的版本关注点主要在于控制台版本尽量跟随最新稳定版不要长期停留在老补丁上。因为我观察到一个很有意思的规律MAUI的补丁版本常常会夹带对特定平台行为的修正比如Android 15发布后老版本MAUI在Android 15设备上可能出现布局偏移而更新补丁版本后问题自动消失。这算是版本管理里最划算的低成本维护。4.2 Blazor Hybrid形态Web团队跨界移动端的捷径Blazor Hybrid是MAUI提供的另一种开发形态界面用Razor组件编写逻辑用C#UI渲染由WebView承载。它与Blazor WebAssembly的区别在于代码在本地进程跑不依赖浏览器沙箱可以直接调用底层设备能力这让纯前端团队切入MAUI的成本一下子降了很多。选择Blazor Hybrid的关键版本考量是CSProj里对Microsoft.AspNetCore.Components.WebView包的引用这个包必须和MAUI主版本匹配。有次我把.NET 8的MAUI工程加了BlazorWebView包版本却还是7.0的结果运行时报一堆类型转换错误。这种版本错配问题在混合开发里尤其容易发生因为涉及的技术栈更多了。Blazor Hybrid形态特别适合那种团队以C#和Web技术为主、没有专门XAML工程师的场景。愿意牺牲一点控件渲染的原生感换来团队开发效率的大幅提升这笔账对很多中小团队是划算的。4.3 Xamarin.Forms迁移到MAUI版本跳跃里的隐形风险从Xamarin.Forms迁移到MAUI本质上是一次跨大版本的架构升级。官方推荐的路径是先升级到Xamarin.Forms 5.x然后转到.NET 7或.NET 8对应的MAUI版本最后清理兼容代码。这个过程中最容易被低估的是命名空间和API签名变化。Xamarin.Forms里的Xamarin.Forms.命名空间要替换成Microsoft.Maui.不少控件属性的行为细节也有微妙变化。渲染器Renderer被Handler替代是最核心的架构差异如果你在Xamarin.Forms里大量使用了自定义Renderer做控件扩展迁移时几乎都得重写。依赖注入也是重灾区Xamarin.Forms的DependencyService在MAUI里被更完整的DI容器取代用法完全变了。我的建议是迁移前先跑一遍官方的迁移工具把基础命名空间替换和项目结构调整自动处理掉但要预留至少一多半的时间去处理自定义渲染器、第三方控件兼容和平台特化代码。版本跳跃越狠手工作业量越大这是跑不掉的。5. 实操选型与踩坑盘点几个真实有效的经验之谈5.1 新项目选版本我一直在用的判断逻辑每次做MAUI技术选型我都会按一个固定的优先级清单来筛先看目标平台的系统版本要求再看第三方库的兼容性然后是团队技能栈最后才是对最新特性的渴望程度。具体来说如果客户明确要求支持Android 7.0以下的老设备你就不光要选旧一点的SDK声明还得注意.NET版本对新API的裁剪问题这种时候选.NET 8依旧稳妥。如果第三方库只有旧版包你就得顺着它的依赖反推MAUI版本强行用新版本反而会陷入无休止的包冲突。团队里全是XAML熟手那Blazor Hybrid再好也不该是首选因为价值发挥不出来。完整版判断逻辑我整理成了一张表项目特征推荐版本/形态理由企业级新项目无特殊API需求.NET 8 原生XAML稳定、支持周期长项目要求最新iOS/Android系统能力.NET 9 原生XAML新API适配最快团队以Web技术为主.NET 8 Blazor Hybrid降低学习成本老Xamarin.Forms项目迁移.NET 8为主跳板工具链和依赖最成熟需要覆盖智能电视等特殊设备基础.MAUI Tizen扩展官方渠道支持目标包含Linux且占比高暂不建议MAUI社区实现不够可靠这套逻辑我用在好几个项目的选型评审里不能说百分之百正确但至少不会让你在第一步就翻车。5.2 实际生产环境里我踩过的版本相关坑列几个印象最深的每一个都是真金白银换来的教训。第一个是Windows App SDK版本冲突。某个项目里引入了第三方地图控件它内部依赖更高版本的Windows App SDK结果MAUI工程启动时直接抛异常窗口都弹不出来。最后通过查看启动日志里的WinUI版本信息把MAUI补丁升了三级才解决。建议所有Windows目标项目建立初期就锁定Windows App SDK的版本并记录在项目文档里。第二个是Android打包ABI导致包体爆炸。默认配置下MAUI会打出包含arm64和x86_64等所有架构的包一个简单App安装包就要逼近150MB。后来我把每个目标框架单独配置RuntimeIdentifiers按架构拆包分发包体直接降到了50MB左右。这种差异在选型评审阶段根本想不到但真正发布时就是致命问题。第三个是iOS模拟器与真机行为不一致。MAUI的iOS版本在模拟器上表现良好但真机上却可能因为AOT裁剪而出现类型丢失某些反射功能直接不可用。解决方法是使用NativeAOT时仔细配置裁剪白名单或者在csproj里关闭不必要的裁剪选项。这个坑对测试安排的影响很大因为很多团队习惯只在模拟器上测。第四个是.NET 6工程升级到.NET 8时Android的WebView行为发生了变化。旧版缓存策略在新版里导致部分H5页面无法正常加载。这类问题没有明显的报错只能通过联调时逐一排查页面表现才能发现。升级版本时务必把核心业务页面的回归测试用例准备充分尤其是涉及WebView和地图控件的页面。5.3 升级MAUI版本的正确姿势按这个顺序做能少熬夜很多团队升级版本是直接改TargetFramework然后编译报错了再逐个修。这种打地鼠式做法效率极低。我建议按下面这个顺序来第一步先查.NET版本对应MAUI包的最新补丁版本把csproj里的PackageReference升级到目标补丁。第二步用.NET Upgrade Assistant工具做一次整体扫描它能自动识别多数需要替换的API和命名空间。第三步检查所有第三方NuGet包的版本兼容性矩阵重点看依赖Windows App SDK的包优先处理版本强约束的依赖。第四步按Android、iOS、Windows的顺序分平台构建验证每个平台单独处理编译错误和运行时问题不要一次全平台一起编否则错误混在一起很难定位。第五步做一次全功能的回归测试尤其是平台特化代码所在的页面并观察不同系统版本设备上的实际表现。这套流程下来升级MAUI版本虽然不能保证零失眠但至少能让你对照步骤有序排查而不是在编译器的红色波浪线里迷失方向。最后再分享一点个人的实际体会做MAUI项目做了这几年我最大的感受是版本这东西不像很多人想的那么高深。它背后就是一组现实约束的折中生命周期长短、系统版本覆盖、团队技术储备、第三方生态的适配程度。把这些约束一项项摊开来看版本选择其实就是一道排列组合题。我现在做新项目默认不看别的直接落在.NET 8这个长期支持版本上然后按目标平台的具体SDK要求把TargetFramework配齐。只有遇到那种明确要尝鲜新系统能力的特殊需求我才会考虑往.NET 9走而且一定会在项目启动前就把后续升级到.NET 10的路线图和时间成本算进去。还有一个小技巧分享一下你在csproj里写TargetFrameworks的时候最好把SupportedOSPlatformVersion的注释写在旁边写清楚每个最低版本是怎么定出来的。这个习惯帮我避免过好几次自己给自己挖坑几个月后回来看代码忘了当初为什么定那个版本结果改了个版本号把兼容性破坏了。如果你能坚持这个习惯版本管理这事基本就不会再给你添乱了。