今天我就掏心窝子分享一套我自己攒了3年的”实战秘籍”——精选的ASP.NET Core和Blazor项目案例，全是企业级项目里真刀真枪用过的。不用你懂高深理论，跟着案例敲一遍，保准你从”会写代码”到”能做项目”，再到”能设计架构”，亲测带过3个实习生，按这套方法走，最快6个月就能独立负责中小型项目。
ASP.NET Core实战：从”能跑起来”到”跑得稳”
很多人学ASP.NET Core都是从”Hello World”开始的，但真正做项目时，你会发现要考虑的远比输出一句话复杂。我把这几年做过的10多个项目里，最有代表性的3个基础场景拆出来，每个都带”踩坑指南”，你跟着做一遍，基本就能应对80%的常规业务开发。
从0到1搭建企业级Web API
上个月帮一个创业公司搭后台API，他们技术负责人之前用Java，转.NET后总觉得”不对劲”。我去看了看他的代码：Program.cs里堆了200多行配置，控制器里又调数据库又处理业务逻辑，才上线3天就因为并发查询崩了两次。后来我带着他重构，从项目结构开始改，两周后接口响应速度快了4倍，服务器CPU占用从80%降到20%。
其实搭框架就像盖房子，地基打不好，后面怎么修都别扭。你可以试试我这套”三层结构+依赖注入”的标准模板：
ServiceExtensions类，写AddApplicationServices方法注册所有服务，再在Program.cs里调用builder.Services.AddApplicationServices()。这样一看就清爽，新人接手也能快速定位问题。 你可以先克隆这个微软官方示例项目（记得加nofollow），对比着改，把它拆成我上面说的分层结构，改完后你会发现代码可读性至少提升60%。
用户认证：别让安全漏洞拖垮项目
“用户登录”看着简单，里面门道可不少。我见过最离谱的案例：一个外包项目把用户密码明文存在数据库，被黑客拖库后，客户损失了几十万。所以认证这块一定要重视，我 了3种常用方案，你可以根据项目选：
| 认证方式 | 适用场景 | 优点 | 缺点 | 安全等级 |
|---|---|---|---|---|
| Cookie认证 | 传统MVC应用、同域网站 | 浏览器自动处理，开发简单 | 跨域麻烦，易受CSRF攻击 | ★★★☆☆ |
| JWT认证 | 前后端分离、跨域API | 无状态，支持跨域 | Token过期处理复杂 | ★★★★☆ |
| OAuth2.0+OpenID | 第三方登录（微信/QQ等） | 无需存储用户密码 | 配置复杂，依赖第三方服务 | ★★★★★ |
我个人最常用的是JWT+刷新令牌方案，既安全又灵活。教你个小技巧：生成JWT时，别把用户角色、权限这些敏感信息放Payload里，去年我做项目时图方便放了进去，后来需要改权限，只能等Token过期，用户怨声载道。正确做法是只存用户ID，需要权限时再查数据库，虽然多一次查询，但灵活性高多了。
数据处理：别让”N+1查询”拖慢系统
数据库查询优化是提升性能的关键。之前帮一个电商平台做优化，他们商品列表接口要2秒才能返回，我用EF Core Profiler一看，好家伙，一个列表查询触发了200多次数据库请求（N+1问题）。后来改成Include预加载关联数据，响应时间直接降到200毫秒。
你写查询时，记住这3个原则：
Include就别懒加载：EF Core默认懒加载，但会导致N+1问题。比如查订单列表时，dbContext.Orders.ToList()然后遍历order.User，每遍历一个订单就查一次用户表。改成dbContext.Orders.Include(o => o.User).ToList()，一次查询搞定。 dbContext.SaveChanges()，这会生成1000个事务。用AddRange一次性添加，最后调一次SaveChanges()，效率能提升10倍以上。 Blazor项目进阶：从”能用”到”好用”
Blazor这几年越来越火，尤其适合想做全栈开发的.NET程序员。但很多人学了Blazor基础知识，一到复杂项目就卡壳——组件复用难、状态管理乱、页面加载慢。我把自己做Blazor项目时 的”避坑手册”分享给你，都是实打实踩过的坑。
组件开发：别让”重复代码”拖垮效率
Blazor的核心是组件，但新手很容易写出一堆重复代码。去年我做一个后台管理系统，10个页面都有表格，每个表格都写了分页、排序逻辑，后来改样式时改了10遍，差点没疯。后来重构时抽了个通用DataTable组件，把分页、排序、筛选逻辑全封装进去，新页面直接引用，代码量少了60%。
教你3个组件设计技巧，亲测能大幅提升复用率：
[Parameter]传参，EventCallback回传事件：比如分页组件，定义[Parameter] public int PageSize { get; set; }接收每页条数，[Parameter] public EventCallback OnPageChanged { get; set; }回传页码变化事件。这样父组件传值，子组件回调，耦合度低。 DataService服务，组件里只负责调用服务和渲染UI。上个月我接手一个项目，组件里写了200多行数据处理代码，改个排序规则都要找半天，后来拆成服务，清爽多了。 RenderFragment实现”插槽”功能：这招能解决90%的组件定制化需求。比如通用卡片组件，你可能需要头部、内容、底部显示不同内容，定义[Parameter] public RenderFragment Header { get; set; }，使用时在组件标签里写
自定义头部
你可以先试试这个Blazor组件库示例（nofollow），把里面的Counter组件改造成带增减按钮、输入框的通用计数器组件，练手效果特别好。
状态管理：别让”数据混乱”毁掉用户体验
Blazor项目一复杂，状态管理就容易变成”一锅粥”。去年我做的Blazor Server项目，用户反馈”点了A按钮，B组件数据没更新”，排查发现是组件间用参数传值，数据变了没通知到。后来改用StateContainer服务+事件订阅，问题解决。
不同项目规模适合不同的状态管理方案，我整理了一张对比表，你可以参考：
| 方案 | 适用规模 | 实现难度 | 性能影响 | 推荐工具 |
|---|---|---|---|---|
| 组件参数 | 小型项目（<5页） | ★☆☆☆☆ | 低 | 原生Blazor参数 |
| StateContainer服务 | 中型项目（5-20页） | ★★☆☆☆ | 中 | 自定义服务+EventCallback |
| Fluxor | 大型项目（>20页） | ★★★★☆ | 低 | Fluxor（Redux模式） |
| Blazored.SessionStorage | 跨页面持久化 | ★★☆☆☆ | 中 | Blazored.SessionStorage库 |
如果你是新手， 从StateContainer开始，实现很简单：创建一个服务类，定义要共享的状态属性和属性变化事件，组件注入服务后订阅事件，状态变了就触发刷新。比如：
public class UserState
{
private string _username;
public string Username
{
get => _username;
set { _username = value; OnUsernameChanged?.Invoke(value); }
}
public event Action OnUsernameChanged;
}
然后在组件里注入UserState，调用userState.OnUsernameChanged += (name) => StateHasChanged();，这样用户名变了，所有订阅的组件都会刷新。
性能优化：别让”加载慢”赶走用户
Blazor WebAssembly项目最容易被吐槽”首屏加载慢”，去年我给一个客户做的官网，首次加载要8秒，客户差点要换技术栈。后来用了3个优化技巧，降到2.5秒，客户满意了。
这几招你一定要试试：
true开启Gzip压缩，发布时用dotnet publish -c Release -p:BlazorEnableCompression=true。AOT编译虽然会增加构建时间，但运行时性能提升30%以上，复杂计算场景特别有用。 LazyAssemblyLoader加载，比如帮助中心页面，用户可能90%的时间不会点，没必要一开始就加载。微软文档里有详细示例（nofollow），照着做就行。 WebP格式图片，比JPG小40%；静态资源放CDN，去年我把图片从服务器移到阿里云CDN，加载速度快了一倍。 对了，你可以用浏览器的”性能”面板测加载时间，按F12打开开发者工具，选”性能”标签，点录制按钮然后刷新页面，结束后看”加载”阶段耗时，重点优化超过500ms的资源。
如果你按这些案例一步步做，遇到问题别慌，大部分坑我都踩过了——比如ASP.NET Core的CORS配置要注意允许的源和方法，Blazor Server的连接断开要处理重连逻辑。你可以在评论区告诉我你做到哪一步了，或者卡在哪了，我看到会回复你。记住，后端开发没有捷径，但有好的实战案例带路，能少走至少一半弯路。
你有没有过这种感觉？跟着教程敲代码，明明每一步都照做，运行起来也没问题，可第二天让你自己写个类似功能，脑子就一片空白？我前两年带过一个实习生，他把Blazor教程里的计数器组件敲得滚瓜烂熟，可让他加个”重置”按钮，他盯着屏幕愣了十分钟，问我”老师，教程里没写这个啊”——这就是典型的”照着敲但没理解”。后来我逼他改了个习惯，现在他已经能独立负责模块开发了，今天就把这个方法掏给你。
我的笨办法其实特简单：每敲完30行代码，就立刻把教程窗口最小化，假装自己是第一次见这个项目。然后盯着屏幕问自己三个问题，每个问题都要能用大白话说明白才算过关。第一个问题是”这段代码到底在解决什么问题？”比如写ASP.NET Core的控制器时，别光知道”[HttpGet]”是GET请求，要想清楚”为什么这个接口用GET而不是POST？”——去年我做用户列表接口，一开始用POST传分页参数，后来才反应过来”查询数据不修改资源，按REST规范就该用GET”，改完后前端调用方便多了。第二个问题是”如果需求变了，我要动哪几行？”比如写完分页功能，就假设”产品经理说要加个按名称筛选”，你试着在不看教程的情况下改代码，改的时候就会发现”哦，原来筛选条件要加在Repository层的查询里”。第三个问题最关键：”有没有更笨的办法实现？”我以前写数据访问层，总跟着教程用EF Core的LINQ查询，有次故意试试用原生SQL写同样的功能，写完一对比，才发现LINQ的延迟加载原来帮我省了这么多事——这种”反向操作”比单纯看文档记得牢十倍。
光问问题还不够，你得动手”搞破坏”。就拿依赖注入来说，教程里都说”要注入IService而不是直接new Service”，可你知道为啥吗？我去年故意在项目里试了把注入改成new对象，结果单元测试根本跑不起来——因为直接new的对象没法模拟依赖，想测某个方法就得连数据库一起跑，效率低得要命。后来改回依赖注入，写测试时用Moq模拟一个假的Service，几秒钟就跑完测试，这时候你才真正明白”解耦”不是句空话。还有Blazor的组件传参，教程说用[Parameter]，你偏试试直接在子组件里定义public字段让父组件赋值，运行时虽然能行，但控制台会报错”组件参数应该用[Parameter]标记”，这种”踩过坑”的经验，比看十遍文档都管用。
最后再教你个土办法：准备个活页笔记本，专门记”踩坑指南”。别抄教程里的正确代码，就记你自己掉进去的坑——比如”Program.cs里中间件顺序错了会导致404″，旁边画个箭头标上”认证中间件要放路由前面！”；或者”Blazor组件里直接修改Parameter参数不会触发UI刷新”，后面补一句”要改用私有变量+StateHasChanged()”。我现在翻这个本子，还能想起去年写文件上传功能时，因为没加[FromForm]特性，调试了两小时才发现参数一直是null的窘迫。上个月带新人时，我把本子借他看，他说”原来老师也犯过这种错啊”——你看，记录错误不仅能帮自己复盘，还能让后来者少走弯路，多划算。
零基础学习ASP.NET Core和Blazor应该从哪里开始？
你先花1-2周熟悉C#基础语法（尤其是面向对象和LINQ），然后直接从官方文档的“入门教程”入手（比如ASP.NET Core的Web API教程和Blazor的计数器示例）。不用急着学高深概念，先跟着敲一遍文章里提到的“三层结构+依赖注入”项目模板，把框架跑起来再说。我带的实习生里，最快上手的那个就是每天花2小时敲案例，3周后就能自己改代码实现简单功能了。
ASP.NET Core和Blazor适合开发哪些类型的项目？
根据我做过的项目经验，ASP.NET Core最适合开发后台API（比如电商后台、管理系统接口）、中小型Web应用；Blazor适合做前后端都用C#的全栈项目，尤其是企业内部管理系统、数据可视化平台这类交互复杂但用户量不大的场景。如果是高并发的大型网站（比如百万级用户电商）， 用ASP.NET Core做API，前端搭配Vue/React；如果是快速开发的小项目，Blazor WebAssembly能省不少事，一套代码前后端通吃。
跟着实战案例学习时，如何避免“照着敲代码但不理解”的情况？
我之前也踩过这个坑——照着教程敲完能跑，但换个需求就懵。后来 了个笨办法：每敲完一个功能，立刻停下来问自己三个问题：“这段代码是做什么的？”“如果要加个XX功能，我要改哪里？”“有没有更简单的实现方式？”比如搭API时，写完控制器后，试试删掉依赖注入改成直接new对象，对比两种方式的区别，你会发现依赖注入的好处一下就懂了。 把案例里的“踩坑指南”抄在笔记本上，遇到类似问题时翻出来对照，印象会特别深。
实战案例中的项目结构是否适用于所有规模的项目？
文章里的“三层结构+依赖注入”是基础模板，小项目（比如个人博客后台）完全够用；中型项目（5-20人开发）可以在此基础上增加“领域层”处理复杂业务逻辑；大型项目（百人以上团队） 引入DDD（领域驱动设计），把Service层拆成“应用服务”和“领域服务”。我去年参与的一个政府项目，初期用基础模板，后来用户量涨到50万，就加了领域层和事件总线，系统依然很稳定。记住，项目结构不是一成不变的，要根据团队规模和业务复杂度灵活调整。
