一、引言

2025年以来，“.NET 能否在鸿蒙上运行”成为开发者社区的热议话题。跳出情绪化争论，从整体来看，这实质上是微软和华为两大科技巨头在生态建设路径上的战略汇合——在 linux-musl 这个技术交点上不期而遇。

二、微软 .NET 为什么选择 musl？

微软在设计现代 .NET 架构时，已将轻量化 Linux 纳入官方一级支持。.NET 的运行时标识符（RID）明确包含 linux-musl-x64 和 linux-musl-arm64，旨在适配 Alpine Linux 等高效率容器环境。支撑这一能力的是 NativeAOT 技术：通过预先编译，.NET 能够脱离运行时，直接生成符合 C ABI（应用二进制接口）标准的动态库（.so）文件。

这一能力的实现，离不开微软 .NET 团队工程师们的长期迭代与持续投入。

可验证来源：.NET RID Catalog

三、鸿蒙为什么选择了 musl？

华为官方文档记载：“HarmonyOS 采用 musl 作为 C 标准库”。musl 以简洁、轻量和高安全性著称，完美契合鸿蒙“全场景、多形态设备”的定位。华为还在 musl 基础上进行了深度定制，包括动态库延迟加载、命名空间隔离等，使其成为鸿蒙原生开发的核心支撑。

这些定制与系统级集成，由华为底层操作系统工程师们共同完成。

可验证来源：HarmonyOS 官方文档 - libc 标准库

四、共同的基石：Linux 与 musl 社区

这一“巧遇”建立在开源世界的公共基础设施之上：Linux 内核作为共同的底层依赖，由全球数千名工程师、贡献者共同维护；musl 社区 标准化的代码实现，为微软和华为提供了“共同语言”。musl 的 COPYRIGHT 文件中列有上百名贡献者，他们超过 15 年的持续工作同样值得被记住。

这种技术选型证明了：即便商业路径不同，主流技术栈正持续向高效、标准的工业规范收敛，而这一收敛过程离不开开源社区长期、沉默、持续的贡献。

五、本质：基于 ABI 标准的“无缝对接”

由于鸿蒙兼容 musl 格式的 Linux 动态库，而 .NET NativeAOT 恰好能产出该格式，开发者可利用 .NET 编译出符合 musl 标准的 .so 文件，在鸿蒙应用中通过标准的 dlopen 即可调用。

.NET x 鸿蒙 技术链路参考

https://github.com/OpenHarmony-NET/PublishAotCross
https://github.com/OpenHarmony-NET/OpenHarmony.Avalonia
https://github.com/OpenHarmony-NET/OpenHarmony.Blazor.Hybrid
https://blog.csdn.net/svsdhssd/article/details/154304602
https://cloud.tencent.com/developer/article/2528899
https://cloud.tencent.com/developer/article/2498103

六、延申：当前技术选型现状

在国产化演进的背景下，不同技术栈的适配进度存在客观差异。以下成果同样依赖于各框架团队、开源社区与广大开发者的共同推动：

七、结语

以上基于搜集到的资料整理而成，如有错漏欢迎补充。.NET 与鸿蒙的战略交点确实存在，是无数工程师、开发者与开源社区贡献者们共同努力的结果，作为中国 .NET 开发者，大家应该都很乐见其成。

致敬所有在技术一线付出的人——无论他们是商业公司的工程师，还是开源社区的贡献者们。