.NET开发微信小程序，从入门到上线的完整指南

我写.NET多年，一直觉得它和微信小程序是两条平行线。直到去年接了个活，客户要求必须用.NET做后端，前端上微信小程序，我才发现这两者其实能配合得相当默契。今天就把这套从开发工具配置到真机上线验证过的流程，原原本本分享出来。

先解决最让人头疼的环境问题。小程序前端用的是微信官方的开发者工具，这个没啥好说的，下载安装就行。关键是后端，很多人以为.NET只能跑在Windows上，其实从.NET Core 3.1开始，跨平台早就不是新鲜事了。我推荐直接用.NET 6或.NET 8，配合Visual Studio 2022，或者直接用VS Code加命令行工具。别忘了装微信开发者工具的“云开发”插件，虽然不是必须，但调试起来方便很多。有一点要强调：小程序的request域名必须是HTTPS且备案过的，本地开发时可以在开发者工具里勾选“不校验合法域名”，但上线前一定要配好正式域名。

接下来是架构设计。我见过太多人一上来就写Controller，结果业务逻辑和数据处理全揉在一起，后期改需求时想哭都来不及。我的做法是分三层：最外层是Web API项目，专门处理HTTP请求和参数绑定；中间是业务逻辑层，负责校验、流程控制和异常处理；最底层是数据访问层，用EF Core或者Dapper操作数据库。小程序端只跟API层打交道，这样前后端分离得很干净。数据库方面，如果你用腾讯云，直接用云数据库MySQL就行；如果是自建服务器，SQL Server或者PostgreSQL都行，EF Core都支持得很好。记住一个原则：小程序端永远不要直接操作数据库，所有数据操作必须走后端API。

说到API设计，这里有个坑必须提醒你。微信小程序的request方法有超时限制，默认60秒，但实际体验中超过10秒用户就开始烦躁了。所以你的API响应时间必须控制在200毫秒到1秒之间。实现这个目标有几个技巧：第一，数据库查询加上索引，别偷懒；第二，用Redis做缓存，特别是用户信息、商品列表这种高频读取的数据；第三，API返回的数据格式要精简，别把数据库字段原封不动全丢给前端。我一般会定义一个统一的返回格式，比如code、message、data三个字段，前端用起来也方便。另外，小程序端的wx.request封装也很重要，统一处理token、错误提示和loading状态，省得每个页面重复写。

登录认证这块是重头戏，也是很多新手最容易翻车的地方。微信小程序的登录流程是这样的：前端调用wx.login拿到临时code，然后传给后端；后端拿这个code加上小程序的AppID和AppSecret，去微信的接口换取openid和session_key；拿到openid后，你在自己数据库里找对应的用户，找不到就新建一个；然后签发一个自定义的token返回给前端，前端后续请求都带着这个token。这里要注意，session_key是敏感信息，绝对不能返回给前端，也不能存在前端存储里。我习惯用JWT做token，设置合理的过期时间，比如7天。还要处理token刷新机制，不然用户用着用着突然要重新登录，体验很糟糕。

文件上传功能，比如用户头像、图片评论，这个话题值得单独说说。小程序的wx.uploadFile方法会把文件以multipart/form-data格式POST到你的后端。在.NET里接收这个文件很简单，用IFormFile类型就行。但要注意几点：第一，文件大小限制，我一般设置5MB，超过就拒绝；第二，文件类型白名单，图片只允许jpg、png、gif，防止有人上传恶意文件；第三，存储位置，开发环境可以存本地磁盘，生产环境建议存腾讯云COS或者阿里云OSS，别把文件堆在应用服务器上。上传成功后，返回一个URL给前端存储。另外记得做防盗链，不然别人可以直接引用你的图片地址，白白消耗你的流量。

然后说说小程序端怎么调用.NET的API。前端用wx.request发起请求，method选POST或GET，header里带上Content-Type和Authorization。有个细节：小程序要求request的url必须是HTTPS，而且域名要在小程序后台配置到request合法域名列表里。开发阶段可以用http://localhost，但真机调试时不行，因为手机访问不到你电脑的localhost。我一般是用内网穿透工具，比如ngrok或者cpolar，把本地API暴露到公网临时调试。还有个容易忽略的问题：小程序发请求时，如果后端返回的Content-Type不是application/json，前端可能解析不了，所以后端要统一设置响应头。

聊上线流程和常见坑。代码写完后，前端在小程序开发者工具里点“上传”，填版本号，然后到微信公众平台提交审核。审核一般1-3天，期间你可以准备后端服务器。后端发布前要检查几件事：appsettings.json里的连接字符串别写死，用环境变量或者密钥管理服务；开启HTTPS，用免费证书就行；配置好CORS，允许小程序的请求来源；日志系统要接好，我用Serilog，出了问题能快速定位。上线后第一周密切监控API的响应时间和错误率，微信小程序对接口的稳定性要求很高，经常有用户抱怨“页面打不开”，大概率就是后端撑不住了。我遇到过最坑的一次是Redis连接没设超时，高峰期连接池耗尽，整个服务假死，排查了两个小时才找到原因。

走完这一整套流程，你会发现.NET做小程序后端其实很顺手。类型安全、工具链成熟、性能也够用。最关键的是，.NET的异步编程模型处理高并发比Node.js那种回调式写法清晰得多。如果你正在犹豫要不要用.NET做小程序后端，我的建议是：先把登录认证跑通，然后做一个简单的增删改查功能，感受一下前后端配合的节奏。等你熟练了，什么微信支付、模板消息、订阅消息，都是水到渠成的事。开发这件事，动手比什么都强，现在就打开Visual Studio，建一个Web API项目试试吧。