定位：不是框架，是胶水
微软 .NET 生态里不缺 Web 框架。ASP.NET Core、NancyFx、EmbedIO、最小 API 等等——它们每个都是为了解决某类业务需求和问题。而 PicoServer 从另一个视角看待问题：程序之间的交互。框架给你一套规则让你遵守，PicoServer 只是给你一个 Web 出入口，提供 Web 能力。不属于任何一类 Web 框架，也不和任何框架竞争。
PicoServer 借助开源 .NET 平台来做这件事——为你的 .NET 程序添加 Web 能力，让设备能对话，让系统能互通，让旧程序能被调用、被管理、被赋予新的能力。融合了轻量、跨平台、零依赖、高性能、胶水特性、AOT、极简开发等特性。
为什么要这样做？
很多时候只是想给程序开一个 Web 出入口，但现有框架往往要求你调整项目结构、跟进版本升级、处理环境配置。有时候升级一个框架版本，意味着整个项目的目标框架和第三方依赖都得跟着动。资源受限的环境里，大框架根本跑不动；跑了好几年的老项目，没人敢动、也没人愿意动、依赖太多，处理兼容性头大。
这些不仅是技术问题，更是成本和风险。
PicoServer 给的解决方案？
单 DLL，几十 KB，零依赖。NuGet 包下载，几行代码，完事。
不需要新建项目，不需要改目标框架，不需要配宿主，不需要学新套路。.NET Framework 4.6.1 到 .NET 10，乃至未来版本，直接用。
你原来怎么组织代码，现在还怎么组织。架构设计上，MVC、DDD、整洁架构、Repository、Service——随你。想用 DI 容器？直接集成。想配合任意第三方库？随便搭。PicoServer 不挑——你习惯用什么，它就配合什么。
// 快速验证，函数式挂路由
MyAPI.AddRoute("/add", Add, "GET");// 企业级规范，特性路由自动扫描
[ApiController]
public class UserController
{[ApiRoute("/api/user", "GET")]public async Task GetUser(HttpListenerRequest req, HttpListenerResponse res){await res.WriteAsync("{\"id\":1,\"name\":\"张三\"}", WebAPIServer.ContentType.ApplicationJson);}
}
MyAPI.AutoRegisterRoutes();
PicoServer 不定义你，你定义 PicoServer。
PicoServer 的胶水特性决定了：你要它是什么样子，它就是什么样子。
- 在工控上位机里，它可以是远程监控和参数配置的 Web 管理端；
- 在桌面应用里，它可以是不依赖额外服务器的本地 API 服务；
- 在跨平台项目里，它可以是一套代码跨端运行的服务出口；
- 在控制台程序里，它可以是单文件部署、零依赖的后台服务；
- 在边缘设备上，它可以是资源受限环境下毫秒级启动的轻量 Web 服务；
- 在轻量 Web 应用里，它可以是无需 ASP.NET Core、不依赖 IIS 的服务入口；
- 在 AI Agent 或 MCP 服务里，它可以是工具服务的底座。
不只是代码层面的适配，更是场景层面的融入。你把它放在哪里，它就变成哪里需要的形状。
如果需要的不仅是 HTTP 接口——大文件上传下载（流式异步、断点续传）、视频流推送（无缓存、分块传输）、SSE 或长连接推送（低内存持续推送）、WebSocket 双向通信（与 WebAPI 共用端口）、静态文件托管、CORS、Cookie 管理、Token/JWT 鉴权、特性路由、API文档自动生成——全都有。
这些不是为了搭复杂系统，而是让你在需要的时候，一个方法调用就能解决。从开发到运维再到迭代，PicoServer 从设计之初的胶水定位就规避了一些潜在的问题。
运维也简单。 几十 KB 的 DLL，覆盖即升级；没有复杂的配置文件，没有版本地狱；回滚就是换旧版本；新人上手没有框架要学，代码就是普通 .NET 方法。
PicoServer 只做一件事：为 .NET 程序提供 Web 能力。
上善若水，水善利万物而不争。它像水一样，放在哪里就变成什么形状。PicoServer 只提供 Web 能力，至于你想用它构建什么——框架、工具、服务，都由你决定。有趣的是 ASP.NET Core 可以和 PicoServer 共存，可以互相调用。
PicoServer 官网：https://picoserver.cn
ASP.NET Core 官网：https://dotnet.microsoft.com/zh-cn/apps/aspnet