DotNetCore.SKIT.FlurlHttpClient.Wechat/docs/WechatApi/Sample.md

## 示例项目

---

示例项目位于 _samples/SKIT.FlurlHttpClient.Wechat.Api.Sample_Net6_。

示例项目基于 .NET 6.0 实现，依赖以下第三方库：

-   [`DistributedLock`](https://github.com/madelson/DistributedLock)：分布式锁。

-   [`NMemory`](https://github.com/zzzprojects/nmemory)：内存数据库。

示例项目实现了以下功能：

-   多租户微信账号;

-   AccessToken 中控；

-   验证并接收微信服务器推送数据；

-   一个根据 OpenId 获取用户信息的 API。

---

### 关于 AccessToken 的刷新机制：

示例项目遵循微信官方建议的“使用中控服务器统一获取和刷新”原则，实现了 AccessToken 的主动刷新机制，开发者不需要、也不应该在业务代码中手动执行刷新操作。

所谓“主动刷新机制”，即由系统在后台周期性地执行刷新操作，在需要使用 AccessToken 时直接读取已有的记录即可，无需关心 AccessToken 是否过期。

与之相对应的是“被动刷新机制”，即在每次读取时先判断已有的记录是否过期，如果未过期则直接返回，如果过期则执行一次刷新操作后再返回。

开发者可根据业务需要自行实现被动刷新机制，也可以二者相结合。

---

### 【重要】使用须知：

示例项目仅作为业务上的参考，不代表可直接用于生产。

开发者应提前知晓：

#### 1. 分布式锁：

示例项目使用分布式锁来确保多节点并发情况下不会产生 AccessToken 刷新冲突问题。

示例中的分布式锁是基于文件系统实现的，仅为展示工作原理，只可用于单机环境下；如在生产项目中，请自行替换成基于数据库或 Redis 等实现的锁。

更多的分布式锁实现方案可直接参考 [`DistributedLock`](https://github.com/madelson/DistributedLock) 的开发文档。

#### 2. 数据持久化：

示例项目仅为展示工作流程，未集成数据库来实现数据持久化。

程序中的全部数据都只在运行时内存可访问，一旦进程终止，数据将会丢失；如在生产项目中，请自行集成 MySql / SQL Server / Oracle 等数据库，或其他数据持久化方案。

#### 3. 容错性：

示例项目中未特殊处理可能产生的异常（如：空指针等），也没有考虑 AccessToken 中控刷新失败等业务逻辑问题，开发者可根据业务需要自行实现。

#### 4. 安全性：

示例项目中不包含授权认证等相关的业务逻辑，开发者可根据业务需要自行实现。