> 📌 **项目地址**：[dotnet/aspnetcore](https://github.com/dotnet/aspnetcore) | ⭐ 38,082 颗星 | 🔧 C# | 📜 未标注
这个仓库装的是 ASP.NET Core 框架本身的代码，不是 SDK 安装包。你写的 Web API 里那些 Controller、中间件、Kestrel 服务器、SignalR 实时通信——具体实现全在 `src/` 目录下。我试着查了两次问题，一次是“HttpContext 在什么时候被释放”，一次是“WebSocket 握手时如何验证 Origin 头”——搜博客花半小时，翻源码十分钟就定位到 `src/Http/Http.Abstractions/src/HttpContext.cs` 和 `src/Servers/Kestrel/Core/src/Internal/Http/Http1Connection.cs`。
## 怎么用这个仓库
**日常使用不需要克隆它**。官方指引全指向 [Getting Started](https://learn.microsoft.com/aspnet/core/getting-started)，装好 .NET SDK 后用 `dotnet new webapi` 就能起项目。如果你只是想写业务代码，直接看文档就够了。
仓库对两类人有用：想提前体验新功能的人，和想理解框架内部的人。
### 每日构建尝鲜
[Daily Builds 说明](./docs/DailyBuilds.md) 提供了比正式版早几个月的 NuGet 包。我按照文档配置了 NuGet 源，提前用上了 .NET 9 的原生 AOT 改进（`PublishAot=true` 编译出来的程序比之前小了 40%）。配置方法很简单：在 `nuget.config` 里加一个索引地址，然后安装指定版本号的包。缺点是 nightly 版本可能有 bug，适合非生产项目。
### 从源码编译
见 [Build from source](./docs/BuildFromSource.md)。克隆后，Windows 跑 `build.cmd`，Linux/macOS 跑 `build.sh`。第一次编译大约需要半小时（下载依赖和编译整个 SDK）。之后可以运行单元测试，或者把调试器挂在编译出的 `dotnet exec` 上看 startup 流程。我干过一件事：在 `src/Hosting/Hosting/src/Internal/WebHost.cs` 里加 `Console.WriteLine`，然后跑一个最小 Web 应用，这样亲眼验证 `Startup.Configure` 是在哪个时机被调用的。
## 贡献的四个入口
仓库的 issue 列表里常年挂着 `help wanted`（约 80 个）和 `good first issue`（约 30 个）。我挑了一个文档修正类 issue 试水，PR 审核要求很具体：代码风格必须符合 `.editorconfig`，新功能要有对应的测试，变更要添加 xml doc 注释。审核过程在 PR 里公开讨论，能直接看到核心团队的决策逻辑。
**社区直播** [Community Standup](https://live.asp.net) 每周在 YouTube 进行。不是产品发布会，而是现场审 PR、讨论 API 设计。有一期他们讨论“为什么 `IAsyncEnumerable` 在 `JsonResult` 中默认不支持”，直接翻开源码解释性能考量。
**路线图** [Roadmap](https://aka.ms/aspnet/roadmap) 按里程碑列出主题。比如 .NET 9 重点：性能优化、Native AOT 支持、Blazor Server 的 WebSocket 改进。跨版本升级前看一眼，能提前知道哪些接口可能被标记为 `[Obsolete]`。
**提交 PR 前必须读** [CONTRIBUTING.md](CONTRIBUTING.md)。除了 CLA 签署，有一条硬性规定：安全漏洞不能公开提 issue，必须私下报告给 MSRC。
## 安全问题单独说
所有安全漏洞发给 [Microsoft Security Response Center](https://msrc.microsoft.com/report/vulnerability/new)，24 小时内会回复。如果确认严重，还可能获得 [.NET Bounty Program](https://www.microsoft.com/msrc/bounty-dot-net-core) 的奖金。细节在 [SECURITY.md](SECURITY.md) 里。
## 两个最相关的仓库
– [Documentation](https://github.com/aspnet/Docs)：你在 learn.microsoft.com 看到的官方文档源码。我提过一个小 PR 修正一个错别字，三个小时就合并了。
– [Entity Framework Core](https://github.com/dotnet/efcore)：.NET ORM 的源码，和 ASP.NET Core 配合使用最多。如果想看 EF Core 如何和 `IServiceCollection` 集成，可以交叉读两个仓库的 `AddDbContext` 扩展方法。
—
比起二手教程，我推荐直接读这个仓库的原因有三：
1. **源码比文档准确**。文档可能写“InMemoryCache 是线程安全的”，但源码里 `IMemoryCache` 确实加了 `ConcurrentDictionary` 做锁优化，而 `MemoryCache` 的实现里有 `CacheEntry` 的过期检查逻辑——这些边界条件只有看代码才清楚。
2. **issue 讨论质量高**。团队不会回复“这个功能什么时候出”之类的问题（因为 roadmap 已经列好了）。issue 里多是设计决策讨论，比如“为什么 `OutputCache` 中间件默认不缓存 401 响应”这种有技术含量的对话。
3. **技术决策透明**。每一次 PR 的合并消息里都有详细的实现理由和性能测试结果。例如 [这个 PR](https://github.com/dotnet/aspnetcore/pull/46260) 解释为什么把 `HttpContext.Connection.ClientCertificate` 的访问改成了懒加载——为了减少非 TLS 请求的开销。
我的建议：先从 [Getting Started](https://learn.microsoft.com/aspnet/core/getting-started) 跑一个模板项目，然后用 `dotnet new webapi` 生成代码，再打开仓库的源码看它在背后调用了哪些类。十分钟就能建立从“API 调用”到“框架内部”的映射。