1. 事件背景与核心争议
1.1 白皮书发布与认定内容
2024年6月,上海市卫生健康委员会通过其官方微信公众号"上海卫生观察"发布了《上海市卫生健康"信息技术应用创新"白皮书》。这份文件作为上海市医疗卫生领域信创工作的指导性文件,对各级公立医疗机构的IT系统建设具有直接的政策导向作用。
在技术组件分类体系中,白皮书将C#/.NET在"ARM架构信创技术全景图"中明确认定为"A组件"。这一认定采用颜色编码系统呈现,A组件通常以红色标识,代表最高风险等级。这意味着上海市卫生健康系统在信创改造中被建议或要求逐步淘汰该技术栈。
1.1.1 A组件的定义与影响
在信创技术组件分类体系中,A组件一般指代非开源、非自主可控、存在供应链安全风险的技术组件,原则上需要被替换。具体评估维度包括:
- 源代码可获取性(是否开源及开源协议类型)
- 知识产权归属(是否由境内实体控制核心技术)
- 供应链安全性(是否存在断供或技术封锁风险)
- 生态自主性(国内产业支撑能力与可持续发展性)
将C#/.NET认定为A组件,意味着官方认为其不符合上述标准,需要纳入替代规划。这一认定对大量基于.NET构建的医院信息系统(HIS)、实验室信息系统(LIS)、医学影像系统(PACS)、电子病历系统(EMR)等核心业务应用构成直接冲击。
1.2 技术社区的质疑点
技术社区对白皮书的认定提出了强烈质疑,主要集中在以下几个方面:
- 技术事实错误:C#/.NET平台自2014年起已完成全面开源转型
- 发展阶段误判:混淆了.NET Framework与.NET Core/.NET 5+两个截然不同的技术发展阶段
- 标准化程度忽视:C#语言已通过ECMA-334/ISO/IEC 23270国际标准认证
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. C#/.NET的技术演进与开源属性
2.1 技术发展历程
2.1.1 .NET Framework时代(2002-2016)
这是微软Windows专有技术阶段,确实属于闭源技术。主要特征:
- 源代码封闭
- Windows平台绑定
- 微软完全控制技术演进
- 版本迭代至.NET Framework 4.8(2019年4月,最终版本)
2.1.2 .NET Core转型期(2016-2020)
这是开源跨平台重构阶段,关键技术节点:
- 2014年11月.NET基金会成立
- 2016年6月.NET Core 1.0发布
- 采用MIT协议,GitHub协作开发
- 多厂商参与(Red Hat、Samsung、Google等)
2.1.3 .NET 5+统一时代(2020至今)
这是完全开源的单一平台阶段:
- 2020年11月.NET 5发布,完成平台统一
- 后续年度版本持续演进(.NET 6/7/8/9)
- 完全开源,基金会治理
- 支持全平台+国产CPU架构
2.2 开源治理结构
2.2.1 .NET基金会独立运营
.NET基金会成立于2014年9月,为501(c)(6)美国非营利组织,具有以下特征:
- 独立于微软的法律地位
- 多元化董事会构成(微软不占多数)
- 托管开源项目知识产权
- 采用标准开源贡献流程
2.2.2 多厂商支持体系
包括Red Hat、Samsung、Google等国际厂商,以及龙芯、华为等国内厂商的深度参与。特别是龙芯团队直接参与dotnet/runtime核心开发,其LoongArch架构支持已合并至官方主线。
2.3 标准化与合规性
2.3.1 国际标准认证
- ECMA-334 C#语言规范
- ISO/IEC 23270国际标准认证
- 微软2022年声明:.NET不受EAR出口管制约束
2.3.2 国产适配现状
| 国产处理器 | 架构 | .NET支持情况 |
|---|---|---|
| 龙芯3A5000/3C5000 | LoongArch64 | .NET 6+,代码合并官方主线 |
| 华为鲲鹏920 | ARM64 | .NET 5+,生产可用 |
| 天津飞腾FT-2000+ | ARM64 | .NET 5+,服务器优化 |
3. 技术社区的回应与行动
3.1 核心反对意见
技术社区通过系统性的技术论证,指出白皮书认定存在以下问题:
- 基础性技术事实错误:忽视.NET已全面开源的事实
- 时态错配:以2020年前的技术状态评估2024年的技术
- 标准不一致:相比Java等技术的认定标准存在矛盾
3.2 社区代表人物与行动
3.2.1 张善友的技术论证
国内知名.NET技术专家张善友于2024年6月24日发表系统性质疑文章,提供完整证据链:
- GitHub开源仓库与统计
- 开源许可全文(MIT/Apache 2.0)
- 基金会治理文件
- 微软出口管制声明
- 国产平台适配声明
3.2.2 社区集体行动
- 开发者论坛广泛讨论(博客园、CSDN、知乎等)
- 行业媒体跟踪报道
- 开源社区联合发声
3.3 抗争策略与诉求
社区采取"以技术事实说话"的策略,主要诉求包括:
- 纠正技术事实错误
- 重新评估C#/.NET的技术属性
- 调整技术组件分类
4. 事件结果与现状评估
4.1 官方回应情况
截至2026年3月3日,经过全面检索确认:
- 上海市卫健委未通过任何公开渠道回应
- 白皮书修订版本未发布
- 原始版本继续有效
4.2 实际影响评估
| 影响层面 | 具体表现 |
|---|---|
| 新建系统技术选型 | .NET采用受限,倾向Java、Python等选项 |
| 现有系统升级改造 | 面临"维持现状"与"彻底替换"两难 |
| 人才储备 | .NET开发者岗位吸引力下降 |
| 供应商生态 | 本地.NET服务商业务受限 |
4.3 社区抗争的成效与局限
4.3.1 成效
- 提升技术认知
- 形成行业共识
- 记录历史案例
4.3.2 局限
- 未促成官方政策调整
- 缺乏制度化反馈机制
5. 延伸讨论与行业启示
5.1 信创政策制定的改进建议
-
建立动态技术评估机制
- 年度复审制度
- 技术预警机制
- 第三方专业评估
-
统一开源技术认定标准
- 明确开源协议类型要求
- 规范治理结构要求
- 建立国产化适配验证标准
-
完善社区参与机制
- 政策制定过程设置公开征求意见环节
- 建立技术专家咨询机制
- 委托中立专业机构进行持续技术跟踪
5.2 技术社区的未来策略
- 前置性参与:建立常态化政策跟踪机制
- 组织化发声:形成跨技术栈联合倡导网络
- 证据链建设:量化政策影响的经济成本
- 国际对标:引入第三方评估机构
- 长期耐心:将单次事件经验转化为可持续组织能力
这一事件反映了技术快速演进与政策评估滞后之间的张力,也为完善我国信创政策制定机制提供了宝贵的案例参考。技术社区需要继续以专业、理性的方式参与公共政策讨论,推动建立更加科学、动态的技术评估体系。
