简介：这是一套面向C#/.NET开发者的微信小程序优惠券领取完整项目源码，前端采用微信小程序原生框架，后台基于ASP.NET MVC开发，并已封装淘宝客API的授权与调用。资源适合有一定C#基础、希望学习微信小程序与.NET后端联调，或正在构建领券返利类应用的开发者参考。压缩包共76个文件，包括22个js脚本、17个json配置、17个wxss样式、16个wxml页面模板等，分别承担页面布局、交互逻辑、数据配置与接口对接；前端页面与逻辑模块完整，后台代码单独打包于TBKAdmin.zip中，整个资源包约22.8MB。后台已实现内容管理、会员、订单、微信系统、WAP等模块，便于二次拓展成完整网站；数据库脚本位于DataBase文件夹，连接字符串可在webconfig中修改。目前已有1784人学习下载，适合在Visual Studio 2010、SQL Server 2008环境中部署演练，通过实际项目快速理解小程序电商、API授权调用及.NET MVC分层开发思路。
1. 这套源码到底解决什么问题：ASP.NET MVC + C# 后端 + 微信小程序的优惠券闭环
先说结论：标题里这套 2019 完整版的 ASP.NET MVC C# 优惠券领取微信小程序源码，本质是一个「微信小程序做前端展示与交互、ASP.NET MVC 做后端接口与数据存储」的完整业务闭环。优惠券不是在小程序里本地生成，而是由 C# 后端维护券模板、库存、领取记录，小程序端只是通过微信登录拿到用户身份，再调用后端接口完成领取动作。适合的场景很典型：某个线下商家或电商平台要做「关注公众号后领券」「分享给好友得券」「新人专享券」这类拉新促活活动，又不想从零开始写整套用户体系和发券逻辑。适合的人群有三类：接二手项目的外包开发者、拿这套代码做课程设计或毕设的学生、以及手里有 .NET 技术栈但没写过微信小程序的团队。我拿到手的这类源码，一般包含两个工程：小程序前端目录和后端 MVC 解决方案，中间靠 HTTP + JSON 通信。能不能用、怎么跑通，接下来按我的实际经验一点一点拆。
2. 微信小程序端怎么接：登录换取 openid、领券与消息订阅
2.1 小程序的整体代码骨架：拿到源码先改这三个文件
我接手这类源码的第一步，不是急着编译，而是先把小程序端的目录结构摸清楚。一个典型的微信小程序项目，无论源码怎么组织，核心就三个文件：app.js（全局逻辑与登录态初始化）、app.json（页面路由与窗口配置）、以及utils/request.js（封装 wx.request 的公共请求层）。如果这套源码还包含了「领取成功提醒」之类的功能，那大概率在app.json里能看到"permission"字段或者"requiredPrivateInfos"配置，这是当年申请订阅消息权限用的。
// app.js 中典型的全局登录态初始化 App({ onLaunch: function () { // 小程序启动时先静默登录，拿 code 换 openid wx.login({ success: (res) => { if (res.code) { // 将 res.code 发给后端，后端用 code 换 openid wx.request({ url: 'https://api.yourdomain.com/api/auth/login', method: 'POST', data: { code: res.code }, success: (loginRes) => { // 把后端返回的 token 或 sessionId 存到全局 this.globalData.token = loginRes.data.token } }) } } }) }, globalData: { token: '', userInfo: null } })这套登录逻辑在 2019 年的源码里几乎是标配：小程序端wx.login拿临时 code，后端拿 code 去微信接口换 openid 和 session_key。要注意的是，2019 年之后微信官方把wx.getUserInfo接口收紧了，但wx.login一直是稳定的，所以登录链路基本不用改。真正要改的是请求地址：源码里写死的https://api.yourdomain.com全部要换成你自己的线上域名。另外，如果源码里用了wx.getUserInfo获取头像昵称，在今天的开发者工具里会提示「该接口已废弃」，建议直接改用wx.getUserProfile或者用头像昵称填写能力替代。
2.2 登录流程：wx.login 换 code，后端换 openid，后端返回会话态
登录是整个券系统的地基，因为优惠券必须绑定到具体用户头上，否则一个人反复注册小号把券薅光，活动预算就废了。微信小程序的登录流程遵循「code 换 openid」的标准协议：前端调用wx.login拿到一个五分钟有效的临时 code，这个 code 只能使用一次，后端拿着 code 请求微信的jscode2session接口，换取该用户在当前小程序下的唯一标识 openid，以及用于解密用户信息的 session_key。
// utils/request.js 中封装公共请求，自动携带 token const request = (url, method, data) => { return new Promise((resolve, reject) => { wx.request({ url: getApp().globalData.baseUrl + url, method: method || 'GET', data: data || {}, header: { 'Content-Type': 'application/json', 'Authorization': 'Bearer ' + getApp().globalData.token }, success: (res) => { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data) } else if (res.statusCode === 401) { // token 过期，重新登录 wx.reLaunch({ url: '/pages/login/login' }) } else { reject(res) } }, fail: (err) => reject(err) }) }) }这段封装里有两个参数值得盯住：timeout和header。很多 2019 年的源码里没有设置timeout，默认 60 秒，如果后端接口在领券高峰时响应慢，小程序这边会一直转圈，用户体验很差。我一般在wx.request里显式加上timeout: 10000，超过 10 秒直接提示「网络繁忙」。还有header里的Authorization，不同源码写法不一样，有的是Cookie、有的是自定义X-Token，这个要和后端约定的中间件完全匹配，否则后端拿不到用户身份。
2.3 领券请求的请求体与响应体：字段、状态码、超时时间
领券接口是这套源码里最核心的调用点。在 2019 年的写法里，前端一般是先进入「领券中心」页面，页面onLoad时请求券模板列表，用户点击某张券时再触发单张领取。请求体和响应体一般长这样：
// pages/center/center.js 中的领券核心方法 receiveCoupon: function (e) { const couponId = e.currentTarget.dataset.id if (this.data.receiving) return // 防重复点击 this.setData({ receiving: true }) request('/api/coupon/receive', 'POST', { couponId: couponId, scene: 'center' // 来源场景：center-领券中心 / share-分享领券 }).then(res => { if (res.code === 0) { wx.showToast({ title: '领取成功', icon: 'success' }) // 刷新剩余库存和已领取状态 this.loadCouponList() } else if (res.code === 1001) { wx.showToast({ title: '已经领过了', icon: 'none' }) } else if (res.code === 1002) { wx.showToast({ title: '券已抢光', icon: 'none' }) } }).catch(() => { wx.showToast({ title: '网络异常', icon: 'none' }) }).finally(() => { this.setData({ receiving: false }) }) }这里的前端防重复靠一个receiving布尔量，原理是拦截用户连点：第一次点击后置为 true，接口返回前再点击直接 return。但需要注意，这只是体验层的防护，真正防止用户用脚本刷接口，必须靠后端的幂等校验。响应体的code字段是业务状态码，和 HTTP 状态码区分开——HTTP 200 只代表请求到达了后端，code: 0才代表业务成功。很多新手在这里被坑：后端返回了 500，前端还去读res.data.code，结果拿到的是 undefined。我一般会在request.js的success回调里先判断res.statusCode，不是 200 就直接 reject，不往业务逻辑走。
3. ASP.NET MVC 后端：领券接口、数据库与配置
3.1 后端项目的目录结构与启动入口，MVC 路由如何映射到小程序请求
拿到后端源码后，第一步是分清「网站项目」和「接口项目」。2019 年左右的 ASP.NET MVC 源码，通常是同一个解决方案里既有给运营管理员用的后台页面（Controller 返回 View），也有给小程序调用的纯接口（Controller 返回 Json）。如果这套源码同时包含后台管理页面，那你会看到典型的 MVC 目录：Controllers、Views、Models、Content、Scripts。小程序请求只会打到返回 Json 的那些 Action 上。
// Controllers/CouponController.cs 中的典型接口写法 [RoutePrefix("api/coupon")] public class CouponController : Controller { // POST /api/coupon/receive [HttpPost] [Route("receive")] public ActionResult Receive(string couponId, string scene) { var token = Request.Headers["Authorization"]; if (string.IsNullOrEmpty(token)) { return Json(new { code = 401, msg = "未登录" }); } // 通过 token 解析用户（实际项目中通常用 JWT 或 Session） var userId = GetUserIdByToken(token); // 调用业务层领取 var result = _couponService.Receive(userId, couponId, scene); return Json(new { code = result.Code, msg = result.Message, data = result.Data }); } }这里有两个 2019 源码常见的问题。一是路由前缀：如果项目用了RoutePrefix，但RouteConfig.cs里又开启了默认路由，可能会出现接口地址和前端请求对不上的情况，原因是两个路由规则叠加之后，实际生效的地址变成了/api/coupon/receive而不是前端写的/coupon/receive。二是返回值类型：Controller的Json()方法默认序列化时会带Content-Type: application/json，但属性名可能是PascalCase（比如CouponId），而小程序端拿到的字段名是couponId，JSON 大小写对不上，前端就取不到值。我一般会让后端在Json()之前配置好JsonSerializerSettings，或者直接规定前端统一用小写开头取字段。
3.2 数据库表设计：优惠券模板表、领取记录表、用户表
券系统能不能扛住活动，数据库表设计起了决定性作用。我看过的这类源码，表设计一般分三类：用户表（存 openid、UnionID、昵称等）、优惠券模板表（存券的名称、面额、库存、生效时间）、领取记录表（存哪个用户领了哪张券、领取时间、核销时间、核销状态）。核心在领取记录表上：它必须有一个「唯一约束」来保证一个用户不能重复领同一张券。
-- 优惠券模板表 CREATE TABLE CouponTemplate ( Id INT IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(50) NOT NULL, -- 券名称，例如 "新人立减5元" Amount DECIMAL(10,2) NOT NULL, -- 优惠金额 TotalCount INT NOT NULL, -- 总库存 RemainingCount INT NOT NULL, -- 剩余库存 StartTime DATETIME NOT NULL, -- 领取开始时间 EndTime DATETIME NOT NULL, -- 领取结束时间 Status TINYINT NOT NULL DEFAULT 1 -- 1-上架 0-下架 ); -- 领取记录表 CREATE TABLE CouponRecord ( Id INT IDENTITY(1,1) PRIMARY KEY, UserId INT NOT NULL, CouponTemplateId INT NOT NULL, ReceivedTime DATETIME NOT NULL DEFAULT GETDATE(), ExpireTime DATETIME NOT NULL, -- 过期时间 UseTime DATETIME NULL, -- 核销时间 Status TINYINT NOT NULL DEFAULT 0, -- 0-未使用 1-已使用 2-已过期 -- 唯一约束：一个用户对一张券只能有一条领取记录 CONSTRAINT UQ_User_Coupon UNIQUE (UserId, CouponTemplateId) );这张表设计里有三个细节值得注意。第一，TotalCount和RemainingCount分开存，是为了运营后台能看到初始预算和实时剩余；但剩余库存的扣减必须走 SQL 原子操作，不能先查再减，否则并发场景下会超发。第二，ExpireTime的计算逻辑一般在后端代码里完成，比如「领取后 7 天内有效」，不要在数据库里写死常量。第三，Status字段用 TINYINT 而不是 BIT，因为券的状态将来可能增加（比如「已锁定」「已退款」），BIT 就只有 0 和 1，扩展性太差。2019 年的源码里还有一个通病：没有建立UsageLog表，导致核销记录无从追溯，我在后期项目里都会建议补一张日志表。
3.3 领券核心接口的实现：校验、扣减、幂等
领券接口是整个系统的命门。我在帮客户排查线上问题时，发现大部分「券被超发」「一人领多张」的问题都出在同一个地方：没有把「查剩余库存」和「扣减库存」放在同一个数据库事务里。正确的做法是用一条带条件的 UPDATE 语句，让数据库自己保证原子性。
public ActionResult Receive(int userId, int couponTemplateId) { using (var db = new AppDbContext()) { // 步骤一：校验用户是否已领过（幂等检查） var exists = db.CouponRecords.Any(r => r.UserId == userId && r.CouponTemplateId == couponTemplateId); if (exists) { return Json(new { code = 1001, msg = "已经领过了，不能重复领取" }); } // 步骤二：原子扣减库存，这里必须使用 UPDATE 语句配合库存条件 var now = DateTime.Now; var affected = db.Database.ExecuteSqlCommand( @"UPDATE CouponTemplate SET RemainingCount = RemainingCount - 1 WHERE Id = @p0 AND RemainingCount > 0 AND StartTime <= @p1 AND EndTime >= @p1", couponTemplateId, now); if (affected == 0) { // 影响行数为 0：要么没库存了，要么不在领取时间范围内 return Json(new { code = 1002, msg = "券已抢光或不在领取时间内" }); } // 步骤三：插入领取记录 db.CouponRecords.Add(new CouponRecord { UserId = userId, CouponTemplateId = couponTemplateId, ReceivedTime = now, ExpireTime = now.AddDays(7), Status = 0 }); db.SaveChanges(); return Json(new { code = 0, msg = "领取成功" }); } }这段代码把最关键的并发防线放在了步骤二：RemainingCount > 0这个条件写在 UPDATE 的 WHERE 子句里，数据库行锁会保证多个请求同时过来时只有一个能更新成功。如果当初写的是「先 SELECT 剩余库存，大于 0 再 UPDATE」，在高并发下一定翻车——两个请求同时读到剩余 1 张，各自执行 UPDATE 后库存变成 -1。另外一个容易被忽略的点是：步骤一和步骤三之间并没有显式的事务包裹，如果插入记录失败而库存已经扣了，用户会发现「没领到但库存少了」。所以我一般会把步骤一也放到显式事务里，或者在后端先插入记录再扣库存，这样即使失败也更方便补偿。
4. 小程序与后端联调：从本地到 HTTPS 的完整链路
4.1 本地联调：IIS Express + 内网穿透，解决「不在合法域名列表」
我见过太多人卡在这一步：后端在本地跑起来了，小程序一请求就报「不在合法域名列表」。微信小程序的网络请求有个硬性规定：wx.request的 URL 必须是在小程序后台「服务器域名」里配置了的 HTTPS 域名。本地开发时我们手里的地址一般是http://localhost:8080，这既不是 HTTPS，也不在域名白名单里，直接请求必然失败。常见的做法是走「不校验合法域名」的开发模式。
在微信开发者工具里，点击右上角的「详情」→「本地设置」，勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。这是最快速的本地联调方式，但注意它只对当前项目生效，而且真机预览时必须关闭这个选项，否则就是给自己埋雷。如果需要在真机上调试，2019 年的主流方案是用内网穿透工具把本地后端暴露成一个临时的 HTTPS 域名，然后在开发者工具后台把这个临时域名加到 request 合法域名里。这个方案的问题是工具提供的域名往往不稳定，第二天可能就换了，每次换域名都要同步改后端Web.config里的 CORS 白名单。
<!-- Web.config 中允许跨域的配置，2019 年源码常见写法 --> <system.webServer> <httpProtocol> <customHeaders> <add name="Access-Control-Allow-Origin" value="https://servicewechat.com" /> <add name="Access-Control-Allow-Headers" value="Content-Type, Authorization" /> <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" /> </customHeaders> </httpProtocol> </system.webServer>这里有个细节：微信小程序的请求来源是https://servicewechat.com，不是你的业务域名。如果你的后端配置了严格的跨域白名单，必须把servicewechat.com和你的小程序线上域名都加进去，否则后端虽然收到了请求，但响应被浏览器拦截，小程序端依然报错。还有一个 2019 年源码常漏的点：OPTIONS预检请求。前端如果带了Authorization这个自定义 header，后端必须响应OPTIONS请求并返回 200，否则后续 POST 请求根本发不出去。
4.2 接口联调中的会话校验：session_key、Token 与请求头
登录链路走通之后，接下来就是每次领券请求时后端的身份校验。2019 年的源码里，身份校验方式粗略分两派：一派是 Session/Cookie，一派是自定义 Token。小程序端没有 Cookie 概念，但wx.request会自动把 Set-Cookie 存起来并在后续请求带上，所以 Session 方案也能跑。但有个致命问题：Session 依赖服务器内存，IIS 应用池一回收，所有用户的登录态全部失效，用户会发现「早上好好的，下午点领券就提示未登录」。我强烈建议把这套源码里的 Session 校验改成 Token 校验，至少在领券接口上，前端传 Token，后端查缓存或数据库校验。
// 简单的 Token 校验中间件写法（示例项目 X 中常用） public class TokenAuthAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { var token = filterContext.HttpContext.Request.Headers["Authorization"]; if (string.IsNullOrEmpty(token) || !token.StartsWith("Bearer ")) { filterContext.Result = new JsonResult { Data = new { code = 401, msg = "未登录或登录已过期" }, JsonRequestBehavior = JsonRequestBehavior.AllowGet }; return; } var userId = TokenStore.GetUserId(token); if (userId <= 0) { filterContext.Result = new JsonResult { Data = new { code = 401, msg = "登录态无效" }, JsonRequestBehavior = JsonRequestBehavior.AllowGet }; return; } filterContext.HttpContext.Items["UserId"] = userId; base.OnActionExecuting(filterContext); } }这段写法里有几个逻辑值得说明。Authorization请求头的格式是Bearer <token>，中间有个空格，判断时不能只判断非空，还要判断前缀。Token 的存储常见做法是放 Redis，Key 为token:{token}，Value 为 UserId，过期时间 7 天。如果源码里没有 Redis，用数据库表存也能跑，但每次请求都查一次数据库，性能堪忧。我在联调时一般会先打开后端的日志输出，确认每个请求的Authorization头是否正常传递，因为小程序端如果header里的键名写错了（比如写成Authorization少了个字母），后端拿不到 Token 直接返回 401，而前端看到的只是「请求失败」，排查起来很费劲。
4.3 联调自测清单：能领、不能重复领、库存耗尽
联调不是「点一下通了就完事」，而是要把边界条件全部验证一遍。我自己踩过最深的坑是只测了「正常领取」这一个happy path，上线后用户反馈「领券按钮点了没反应」，一查是库存为 0 时的分支里前端弹了 toast 但后端返回了 HTTP 500，前端 catch 后又走了网络异常提示，用户根本没看懂。所以联调阶段我手里会有一张检查清单，每个场景都单独验证。
| 测试场景 | 操作方式 | 预期后端 code | 预期前端表现 |
|---|---|---|---|
| 正常领取 | 未登录用户登录后点击领取 | 0 | 提示「领取成功」，列表刷新 |
| 重复领取 | 用同一账号再次领取同一张券 | 1001 | 提示「已经领过了」，按钮置灰 |
| 库存耗尽 | 后台把剩余库存改为 0 后点击领取 | 1002 | 提示「券已抢光」，按钮不可点 |
| 未登录调用 | 清空 token 后直接点领取 | 401 | 跳转登录页 |
| 不在领取时间 | 后台把结束时间改成过去 | 1003 | 提示「不在领取时间内」 |
| 网络超时 | 后端接口人为 sleep 15 秒 | 无响应 | 前端 10 秒后提示「网络繁忙」 |
这张表看起来简单，但真跑起来会发现很多问题。比如「重复领取」这个场景，如果你后端的幂等校验是先查记录再 INSERT，并发下会出现两个请求都没查到记录，然后都插入成功。这时候你在测试里用「串行点击」是测不出问题的，必须用并发工具压测。我在本地联调时会打开后端的Debug日志，每个接口输入输出都打出来，前端报什么错，直接对时间戳看后端日志，联调效率能提升一倍。
5. 部署与运行避坑：2019 版源码在今天的 5 个典型坑
5.1 小程序基础库版本与 wx.getUserProfile 的变化
2019 年的源码拿到今天，第一道坎就是小程序基础库的版本兼容。那时候源码里普遍用wx.getUserInfo来拿用户头像昵称，而微信官方从 2021 年 4 月起已经回收了这个接口的「弹窗授权」能力，现在调用它不再弹出授权框，而是直接进失败回调。现象是：用户点击授权按钮后，头像昵称永远拿不到，登录流程卡在「获取用户信息」这一步，领券自然进行不下去。原因不是你的代码写错了，而是微信在服务端把老接口的授权入口关了。解决方法是把wx.getUserInfo替换为wx.getUserProfile，后者是官方推荐的新接口，但注意它必须由用户主动点击触发，不能像老的wx.getUserInfo那样在onLoad里直接调。
5.2 .NET Framework 版本与 NuGet 包还原失败
这类源码的后端一般跑在 .NET Framework 4.6 或 4.7 上，拿到今天，在 Visual Studio 里第一件头疼的事就是 NuGet 包还原失败。现象是打开解决方案后，References里一堆黄色感叹号，编译直接报一堆命名空间不存在。原因有三个：一是本机没装对应版本的 .NET Framework 开发包，二是 NuGet 源被改成了国内镜像导致某些旧版包找不到，三是源码里的packages.config写的是需要手动还原的旧格式。我的处理步骤是：先确认本机装了 .NET Framework 4.7.2 Developer Pack，然后在 Visual Studio 的 [工具]→[NuGet 包管理器]→[程序包源] 里加上官方源https://api.nuget.org/v3/index.json，最后右键解决方案选「还原 NuGet 程序包」。如果还提示某些包版本不存在，去packages.config里手动调整版本号到相近的稳定版，比如Microsoft.AspNet.Mvc从 5.2.7 升到 5.2.9。
5.3 微信支付/消息订阅的模板 ID 过期的处理
很多 2019 版的券系统不止发券，还配套了「领取成功发订阅消息」的功能，这就要用到微信的订阅消息模板 ID。今天的坑是：当年申请的模板 ID 可能已经被你删除，或者微信改了模板库的分类，老模板 ID 在后台已经搜不到。现象是：后端调subscribeMessage.send接口报 43101 或 47003 错误码，前端收不到任何提醒。原因不是代码逻辑问题，而是模板 ID 失效了。解决方法是登录微信公众平台，在「订阅消息」里重新选模板，拿到新的模板 ID，然后同步修改后端代码里写死的templateId字段。这里有一个血泪经验：模板 ID 不要直接硬编码在多个文件里，放到Web.config或数据库配置表里，以后换模板只用改一处。
5.4 数据库连接字符串与发布时 Web.config 的玄学
本地跑得好好的，一发布到服务器就报「无法连接到已配置的数据库服务器」，这可能是 ASP.NET 项目里最经典的玄学问题。现象有两种：一是服务器上根本没有装 SQL Server，或者装的版本和你本地不一致（本地是 LocalDB，服务器上是 Express，连接字符串完全对不上）；二是Web.config里的连接字符串写的是Server=localhost，发布到服务器后localhost指向的是服务器自己，但 SQL Server 实例名和端口没配好。我一般的做法是：发布前把Web.config里的connectionStrings改成用 SQL Server 身份验证的模式，明确写Server=<服务器IP>,1433;Database=coupon;User Id=sa;Password=<强密码>;这样服务器上只要开了 1433 端口和 SQL Server 的 TCP/IP 协议就能连上。还有每次都踩的坑：发布工具有时会保留旧的Web.config，你改了连接字符串但没生效，需要手动到服务器上检查发布目录里的Web.config到底是不是最新版本。
5.5 证书与 HTTPS：小程序强制要求，非 HTTPS 一律请求失败
小程序上线后，所有请求域名必须是 HTTPS，而且证书链必须是完整的。2019 年买证书的人少，很多源码的部署文档里直接让你用 HTTP 跑，这在开发者工具勾选「不校验域名」时能跑通，但真机预览和线上一定是全军覆没。现象：点任何按钮都报request:fail，而且错误信息里会带着TLS version之类的提示。原因有二：要么域名还是 HTTP，要么证书用的 TLS 版本过低（比如 TLS 1.0），微信要求至少 TLS 1.2。解决办法是在服务器上配好 HTTPS 证书后，用在线检测工具检查证书链是否完整，确保没有中间证书缺失。部署完 HTTPS 之后，记得在小程序后台的「服务器域名」里把request合法域名改成https://开头的地址，而且域名不能带端口号、不能带路径，只能是二级或三级域名。这点很多人忽略：你填了https://api.yourdomain.com/coupon是无效的，只能填https://api.yourdomain.com。
6. 把「领券」做成能扛活动的状态机：幂等、库存与对账
6.1 并发场景下的库存扣减：UPDATE 条件判断与事务隔离级别
如果你的券活动上了某个大流量入口，比如整点秒杀、公众号推送后的一波洪峰，领券接口会被瞬间打到上千 QPS。我见过某公司的运营活动把优惠券后台直接打崩，原因就是当初的代码是「先查库存再 UPDATE」。正确的做法我在第 3 章已经写了，用UPDATE ... WHERE RemainingCount > 0的原子操作。但这里还有个参数值得调：SQL Server 默认的隔离级别是READ COMMITTED，在扣减库存时建议用UPDLOCK行锁提示，确保并发下同一张券的扣减是串行的。
6.2 对账与补偿：领券记录、核销记录、每日对账脚本
做券系统和做交易系统一样，不能只看「发出去多少」，还要看「实际核销多少」。我习惯在整套源码之外补一个每日对账脚本：统计每条券模板的领取总数、核销总数、过期总数，和数据库里的剩余库存做减法验证。如果发现「领取总数 + 剩余库存 ≠ 模板总数」，说明中间有异常数据，要立刻排查。
-- 每日对账统计脚本：核对库存与领取记录是否一致 SELECT t.Id AS TemplateId, t.Name, t.TotalCount, t.RemainingCount, (SELECT COUNT(*) FROM CouponRecord r WHERE r.CouponTemplateId = t.Id) AS ReceivedCount, (SELECT COUNT(*) FROM CouponRecord r WHERE r.CouponTemplateId = t.Id AND r.Status = 1) AS UsedCount, t.TotalCount - t.RemainingCount - (SELECT COUNT(*) FROM CouponRecord r WHERE r.CouponTemplateId = t.Id) AS DiffCount FROM CouponTemplate t HAVING DiffCount <> 0;这句 SQL 的DiffCount字段是核心：如果它不是 0，说明库存记录和领取记录对不上。最常见的原因是历史代码里存在「扣了库存但插入领取记录失败」的异常操作，或者有人手动改了数据库的库存字段。我一般在活动结束后用这个脚本跑一遍全量对账，发现问题后人工核对操作日志，确认是补偿发放还是修正库存。
6.3 进阶：把领取入口从「用户手动领」升级为「系统自动发券」
当这套系统稳定跑通后，我建议的进阶方向是引入「触发式发券」：不依赖用户手动进领券中心，而是当用户完成某个动作（比如首次下单、晒单评价、邀请好友注册）时，后端自动调领取接口。这需要你在原有领取接口上再加一个source参数，区分是「手动领取」还是「系统发放」。系统发放的逻辑里，幂等校验更加重要，因为同一个用户可能多次触发同一个动作，不能重复发券。另一个进阶是把领取成功的通知从「前端 toast」升级为「微信订阅消息」，让用户领完券之后收到一条带券码的消息。这一步的技术难点不在后端，而在小程序端需要在用户点击领券时就发起wx.requestSubscribeMessage请求，用户同意后后端才能调用订阅消息接口下发通知。否则你会遇到「后端发了消息但用户收不到」的情况，原因就是前端根本没拿到订阅授权。
我做这套东西走过最弯的一段路，是把并发扣减想成了「先 SELECT 后 UPDATE」，导致一次活动中超发了 30 多张券，最后只能人工发补偿券收场。从那以后，凡是涉及库存扣减的代码，我第一条原则永远是「让数据库做判断，而不是让应用层做判断」。这套 2019 年的源码虽然技术栈偏老，但核心思路——登录换身份、模板管库存、记录做幂等——到今天依然是券系统的标准骨架，值得花时间吃透。希望帮到你。
本文还有配套的精品资源，点击获取
