1. .NET开发选型全景指南
作为深耕.NET技术栈十余年的老鸟，我完整经历了从.NET Framework到跨平台.NET Core的转型期。这个系列将系统梳理.NET生态中的技术选型要点，涵盖框架版本、运行时环境、UI方案、ORM工具等核心组件。不同于官方文档的平铺直叙，我会结合真实项目中的技术决策案例，分享那些只有踩过坑才知道的选型经验。
2. 基础框架选型策略
2.1 .NET Framework与.NET Core的抉择
直到今天，我仍会遇到客户询问："该用Framework还是Core？"这个决策需要考虑三个硬指标：
- Windows服务依赖：如果项目必须使用Windows特有的功能（如WPF、Windows服务），Framework仍是唯一选择。我曾有个工业控制项目，因需要调用OPC DA组件而不得不停留在Framework 4.8
- 部署环境限制：政府机构常见的老旧Windows Server 2008 R2环境，最高只能运行Framework 4.6.2
- 第三方库兼容性：某些商业库（如某报表工具）至今未提供Core版本
经验法则：新项目首选.NET 6+，除非遇到上述三种情况。最近帮某金融客户迁移时，我们用IConfiguration重构了原Web.config的加密配置，成功将ASP.NET MVC5项目升级为ASP.NET Core 6
2.2 运行时环境的隐性成本
不同运行时对性能的影响常被低估：
-
自包含部署：单个exe方便但体积庞大。实测一个Hello World程序：
发布模式 大小 启动时间 Framework 4MB 120ms Core依赖共享 10MB 80ms Core自包含 150MB 200ms -
AOT编译：.NET 8的Native AOT能提升冷启动速度，但会：
- 增加30%构建时间
- 失去动态加载能力
- 调试符号不完整
3. 用户界面技术栈对比
3.1 桌面开发路线图
WinForms的"老当益壮"常让人惊讶。去年我们维护了一个2005年的WinForms项目，通过NuGet更新到最新4.8版本后，依然能流畅运行在高分屏上。但新项目建议考虑：
- WPF：适合复杂业务系统，但学习曲线陡峭。最近用ModernWPF库+Material Design图标，三天就做出了媲美Electron的界面
- MAUI：跨平台愿景美好，但Android支持仍不完善。上周测试发现ListView在小米手机上滚动时会偶发卡顿
3.2 浏览器端方案选型
Blazor的全栈能力令人惊艳，但需要警惕：
- WASM模式：首次加载2MB起，我用Brotli压缩+CDN缓存优化后，首屏时间从8s降到1.5s
- Server模式：每个操作都会产生WebSocket通信，不适合高并发场景。曾有个电商项目在秒杀时出现SignalR连接风暴
4. 数据访问层技术决策
4.1 ORM性能实测
Dapper、EF Core、SqlSugar的对比测试结果（查询10000条记录）：
| ORM | 耗时 | 内存占用 | 易用性 |
|---|---|---|---|
| Dapper | 12ms | 45MB | ★★★☆☆ |
| EF Core | 35ms | 120MB | ★★★★★ |
| SqlSugar | 18ms | 60MB | ★★★★☆ |
关键发现：EF Core的AsNoTracking()能使性能提升3倍，这在处理大数据量报表时特别有用
4.2 多数据库支持策略
为应对客户可能变更数据库的需求，我总结出三层抽象方案：
- 用IRepository封装基础CRUD
- 针对不同数据库实现Provider
csharp复制// SQL Server特定优化 public class SqlServerUserRepository : IUserRepository { public Task<List<User>> BulkInsertAsync(List<User> users) { // 使用SqlBulkCopy实现 } } - 在DI容器中动态注册实现类
5. 实战中的架构设计模式
5.1 模块化开发方案
通过研究Prism和MEF的源码，我提炼出适合中型项目的轻量级模块化方案：
- 按功能划分模块项目
- 用Assembly.LoadFrom动态加载
- 基于特性的自动注册：
csharp复制[AttributeUsage(AttributeTargets.Class)] public class AutoRegisterAttribute : Attribute { public ServiceLifetime Lifetime { get; set; } }
5.2 配置管理的演进
从app.config到IConfiguration的迁移过程中，这些经验值得分享：
- 将连接字符串等敏感信息移到环境变量
- 用IOptionsSnapshot实现热重载
- 自定义配置提供程序支持数据库存储
6. 部署与运维的黑暗森林
6.1 容器化实践要点
在Docker中运行.NET应用时，这些陷阱我全都踩过：
- 基础镜像选择：mcr.microsoft.com/dotnet/aspnet比runtime镜像大，但包含更多诊断工具
- 时区问题：必须显式设置：
dockerfile复制ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime - 内存限制：K8s环境需显式配置GC参数：
bash复制dotnet your.dll --gc-params="ServerGC=true;GCHardLimit=80"
6.2 监控方案选型
经过对比测试，推荐这样的监控组合：
- 应用指标：OpenTelemetry + Prometheus
- 日志收集：Serilog + Elasticsearch
- 链路追踪：Jaeger
7. 性能优化实战记录
7.1 高频问题解决方案
整理近三年性能调优案例，出现频率最高的是：
- EF Core的N+1查询：通过Include+AsSplitQuery解决
- 同步调用异步方法：导致线程池饥饿的GetResult()调用
- 大对象分配：特别是XML序列化产生的byte[]
7.2 内存泄漏排查流程
基于WinDbg的经典分析步骤：
- 抓取dump文件
bash复制
dotnet-dump collect -p <pid> - 分析对象根引用链
- 重点关注实现了IDisposable的类型
- 检查事件订阅未取消的情况
8. 团队协作规范建议
8.1 代码风格强制方案
通过.editorconfig统一团队编码风格：
ini复制[*.cs]
dotnet_sort_system_directives_first = true
csharp_new_line_before_open_brace = all
8.2 CI/CD流水线设计
经过20+项目验证的经典流程：
- 提交时运行单元测试
- PR合并触发SonarQube扫描
- 打Tag时自动生成NuGet包
- 推送到release分支触发K8s滚动更新
9. 未来技术演进预测
根据.NET团队路线图，这些技术值得提前储备：
- AOT编译：将彻底改变部署方式
- WASI支持：可能带来新的边缘计算场景
- ML.NET 2.0：内置更多预训练模型
在最近的一个物联网项目中，我们提前采用.NET 8的AOT特性，使边缘设备的启动时间从3秒缩短到300毫秒。这种技术前瞻性往往能在关键时刻带来竞争优势