* 以上规则仅针对虚拟商品

“✘”是指：不能展现任何有购买、支付的功能、页面、按钮，即使实际上它们都不可使用；也不得引导至外部网站或 APP 来实现支付功能。

“虚拟商品”包括但不限于购买：会员、月卡、代金券、置顶服务。

“引导行为”包括但不限于引导至：App、公众号、H5、个人号、网站、安卓手机。

参：微信小程序 - 运营规范 - 虚拟支付行为

微信内规则大部分基于 iOS 规则。

任何不被允许的虚拟支付只要能够通过内购实现，那么都变得允许，只不过到手只剩 70%。

本文介绍 ASP.NET 的 Swagger 部署，若您使用 ASP.NET Core 应用程序，请移步 ASP.NET Core Web API Swagger 官方文档：

https://docs.microsoft.com/zh-cn/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio

https://github.com/domaindrivendev/Swashbuckle.AspNetCore

安装

NuGet 中搜索安装 Swashbuckle，作者 Richard Morris

访问

http://您的域名/swagger

配置

显示描述

以将描述文件（xml）存放到项目的 bin 目录为例：

1. 打开项目属性，切换到“生成”选项卡

2. 在“配置”下拉框选择“所有配置”

3. 更改“输出路径”为：bin\

4. 勾选“XML 文档文件”：bin\******.xml，（默认以程序集名称命名）

5. 打开文件：App_Start/SwaggerConfig.cs

6. 取消注释：c.IncludeXmlComments(GetXmlCommentsPath());

7. 添加方法：

   public static string GetXmlCommentsPath()
   {
       return System.IO.Path.Combine(
           System.AppDomain.CurrentDomain.BaseDirectory,
           "bin",
           string.Format("{0}.xml", typeof(SwaggerConfig).Assembly.GetName().Name));
   }

   其中 Combine 方法的第 2 个参数是项目中存放 xml 描述文件的位置，第 3 个参数即以程序集名称作为文件名，与项目属性中配置一致。

如遇到以下错误，请检查第 2、3、4 步骤中的配置（Debug / Release）

500 : {"Message":"An error has occurred."} /swagger/docs/v1

使枚举类型按实际文本作为参数值（而非转成索引数字）

1. 打开文件：App_Start/SwaggerConfig.cs

2. 取消注释：c.DescribeAllEnumsAsStrings();

完整操作步骤如下：

1. 安装 NuGet 包：Microsoft.AspNet.Web.Optimization

2. 打开 Views 目录（如果是应用于区域，则为区域的 Views 目录）中的 web.config，在 <namespaces /> 节点中添加

   <add namespace="System.Web.Optimization" />

3. 在 App_Start 目录中创建类文件 BundleConfig.cs，更改其命名空间为应用程序的默认命名空间（即移除 .App_Start），创建方法：

   public static void RegisterBundles(BundleCollection bundles)
   {
       bundles.Add(new StyleBundle("~/虚拟路径（不能有点）").Include("~/CSS文件路径"));
       bundles.Add(new ScriptBundle("~/虚拟路径（不能有点）").Include("~/JS文件路径"));
   }

   虚拟路径应避免与页面访问路径相同。Include 可包含多个文件，效果是合并输出，注意引用的顺序。

4. 打开 Global.asax，在 Application_Start() 事件中添加代码

   BundleTable.EnableOptimizations = true; // 该设置使在开发模式中实现压缩代码，不设置则仅在发布后压缩代码
   BundleConfig.RegisterBundles(BundleTable.Bundles);

5. 视图页面中引用样式表或脚本

   @Styles.Render("~/CSS虚拟路径")
   @Scripts.Render("~/JS虚拟路径")

   使用 Render 的好处是，ASP.NET 会自动给引用地址加上参数，可在更改脚本或样式表内容后更改这些参数使浏览器缓存立即失效。

如果你的项目中已经安装并使用 Bundle，那么只需要参考第 4 步，将 BundleTable 的 EnableOptimixations 设为 true。

以下是一些常见异常的解决方法：

The name 'Styles' does not exist in the current context

The name 'Scripts' does not exist in the current context

解决：参步骤 2。

引用的样式表或脚本不存在（报 404 错误）

解决：步骤 3 中的虚拟路径不规范。

微信支付商户平台注册时填写的企业法人为超级管理员，此处对比的是在“员工账号管理”中添加的“管理员”身份的账号，并且“配置权限”中勾选了所有权限。

微信支付商户可以直接注册，也可以由公众号、小程序、开放平台等开通。

直接注册时可勾选使用的公众号、小程序、APP、PC 网站等，并填写相应的 APPID。

填写资料提交审核，等待 1~2 工作日。

审核通过后签约，选择“手动提现”或“自动提现”，建议“手动提现”，原因如下：

用户付款、退款、企业付款等流程

以乐趣到家为例，

用户 A 提交搬家需要，并支付 100 元搬家费（其中的 10 元是平台抽成，90 元是服务者 B 的收入）。

那么 A 付款成功后，100 元打入商户的“未结算”中，在结算周期后扣除手续费变成“已结算”（若手续费 0.6% 则变成 99.4 元），如果商户开通了自动提现，则直接打入对公账户。

当 A 申请退款时，如果“未结算”资金充足，那么从“未结算”资金中退款给 A，如果不足，则从“可用余额”中退款（从商户角度来说应该是“企业付款”）。

若服务正常完成，则从可用余额中付款 90 元给 B。

可用余额（简称余额）是专用于支付的资金，其资金来源可以是充值或从“已结算”资金转入（前提是未开通自动提现）。

如果开通了“企业付款”，那么相关资金也是从余额中扣除的。

所以，退款（用户角度的“退款”）直接从“未结算”中扣是最划算的，只当“未结算”中资金不足时采用余额退款（用户角度的“退款”，商户角度的“企业付款”）。

由于退款（商户角度的“退款”）的前提是有相应的订单，所以上例中的 90 元支付给 B 时不能使用商户的退款功能，只能从余额支付（企业付款），而从“已结算”转到“余额”是最划算的，如从“已结算”到“对公账户”再充值到“余额”就会涉及开票缴税。

下面是如何关闭和再次开通“自动提现”。（注意：并非所有的商户都有此功能！据我所知，结算周期为 T+1 的有关闭功能，T+7 的不能关闭）

以上系本人经验总结，仅供交流，不承担任何责任，如有错误敬请指正。QQ 940534113

这是一篇可能解决困扰了 .NET 程序猿多年的文章！

首先，使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序，直接选用了 MVC 模板。

直接发布项目，默认的设置如下图：

对于小型项目，按默认设置发布基本可满足正常运行，首次运行打开第一个页面基本在 5~6 秒（视服务器配置），其它页面的首次打开也基本在 1~2 秒完成，非首次瞬间打开。

一旦项目功能变得复杂，文件增多，会导致发布后首次运行打开第一个页面 30 秒以上，其它页面的首次打开 10 秒左右，非首次瞬间打开。

这是因为项目在发布时没有进行预编译，而是在用户访问网页时动态编译，一旦应用程序池回收，或项目文件改动，都会重新编译，再次经历缓慢的“第一次”，这是不能忍的。

于是咱们来研究一下“预编译”。

在发布页面勾选“在发布期间预编译”，这时发布会在“输出”窗口显示正在执行编译命令（编译时间会比较长）：

该选项对发布后的文件结构和内容影响不大，因此对首次执行效率的提升也不大，重要的在后面。

在“高级预编译设置”窗口中：

我们针对预编译选项和合并选项分别做测试。

不勾选“允许更新预编译站点”，会致 bin 目录中生成许多 .compiled 文件，而所有 .cshtml 文件的内容都是：

这是预编译工具生成的标记文件，不应删除!

如果是 Web From 网站，.aspx/.ashx 等文件内容同上。

尝试打开网站页面，你会发现，除了项目启动后的第一个页面仍然需要 1~2 秒（无 EF），其余每个页面的首次都是瞬间打开的（EF 的首次慢不在本文讨论范围）。这让我对预编译有一种相见恨晚的感觉！

这里偷偷地告诉你，把 Views 目录删掉也不影响网页正常打开哦~为什么不让删，咱也不敢问，咱也不敢删。

目的达到了，有一些后遗症需要解决，比如 bin 目录内杂乱无章。

选“不合并。为每个页面和控件创建单独的程序集”，结果是 bin 多出许多 App_Web_*.dll 文件。

选“将所有输出合并到单个程序集”，填写程序集名称。这时会发现“输出”窗口执行了命令：

如果程序集名称跟已有名称冲突，会发生错误：

合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.

查看 bin 目录，.compiled 文件还在，但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍，所以不存在相对于“合并”的增量发布优势。

是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见？意外之外，情理之中，bin 没有什么变化。

继续选择“将各个文件夹输出合并到其自己的程序集”，呃，bin 中文件数不降反增。

最后选择“将所有页和控件输出合并到单个程序集”，同样程序集名称不能冲突。结局令人失望，bin 中仍然一大堆 .compiled 和 App_Web_*.dll。

整理成表格：

bin 目录下，页面的程序集文件（App_Web_*.dll）增多的原因是编译后的文件名不固定，发布到会导致残留许多无用的程序集文件。

相比较，如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的（还有一个缺点是：如果页面有删除，目标 bin 内对应该页面的 .compiled 和 .dll 不会删除，这跟“允许更新预编译站点”是一个情况），那么第 4 种 或第 5 种也是不错的选择（同样有缺点：执行合并比较慢）。

测试一个有 300 个页面的项目，compiler 用时约 2 分钟，merge 用时约 5 分钟，发布用时约 4 分钟。

这里有个槽点，执行预编译和合并是佛系的，CPU 和磁盘使用率永远保持在最低水平。

所以如果是要经常修改的项目，那么建议选择“不合并”的第 3 种发布方式：

“视为库组件（删除 AppCode.compiled 文件）”：移除主代码程序集（App_Code 文件夹中的代码）的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用，则不要使用此选项。

补充：

• 不允许更新预编译站点发布后，因为前端页面没有内容，因此无法单独修改发布（单独发布一个页面后，在访问时不会生效！），只能全站发布，耗时较长；bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。

• 预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误（特别是命名空间和路径引用）。

• 改为预编译发布后，可以将服务器上残留的 .master / .ascx / .asax 删除，但不能删除 .aspx / .ashx /.config 等。
  

• VS 发布到 FTP 经常会遗漏一些页面文件，不合并时会遗漏独立文件，合并后也会遗漏合并后的 .dll 的文件，合并的好处就是方便检查是否完全上传发布。

• 慎选“在发布前删除所有现有文件”！一旦勾选发布，世界就清静了，所有网友上传的图片附件以及网站运行产生的其它文件，消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然，如果是先发布到文件系统，再通过 FileZilla 等 FTP 软件上传到服务器的，建议勾选此项。

• .NET Core 应用程序部署：https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index

• 由于上传文件时 bin 目录文件较多，理论上 bin 目录内的文件有任何改动都会重启应用池，而且 VS 是单线程上传的，导致期间网站访问缓慢，服务器 CPU 升高，我的做法是：发布到文件系统，再使用专用 FTP 工具上传，上传用时约半分钟（如果大小不同或源文件较新则覆盖文件）。还嫌慢？那就打包上传，解压覆盖。

• 关于本文研究对象的官方解释：高级预编译设置对话框

• 出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时，先用改用 Debug 方式发布会报详细错误，一般是 .aspx 等客户端页面有 C# 语法问题，注意提示报错的是 /obj/ 目录下的克隆文件，应更改原文件。排除错误后关闭所有页面，再使用 Release 方式发布。

• 2025年9月补充：因预编译发布后生成的文件时间都是系统最新时间，通过 FTP 上传到服务器时都会覆盖文件，可能导致杀毒软件进程 MsMpEng.exe 占用 CPU 过高。尝试选择不进行预编译，即取消“发布期间预编译”前的勾，这样发布的的文件时间都是文件本身的最后修改时间，重复发布不会更新这个时间，而且 bin 目录中也不会出现大量编译后的文件。这样通过 FTP 上传时只要设置“大小不同且文件较新则覆盖”就不会重复上传文件了，杀毒软件的工作量就能大大减少。缺点就是本文开头说的，每个页面的第一次打开会比较慢，而是非常慢。所以仍然需要勾选“发布期间预编译”，同时勾上“允许更新预编译站点”，这样 bin 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
  

前提：

若需获取用户 unionid，则小程序必须已绑定到微信开放平台。

1. 小程序调用 wx.login()，将 code 发送到开发者服务器

2. 开发者服务器请求微信接口 code2Session，获得 session_key、openid，有机会获得 unionid（参 UnionID 机制说明）。因此无需任何用户授权即可获取 openid

3. 访问须要已获取用户信息的页面时，可通过小程序端使用 button + getUserInfo 的方式请求用户授权

4. 访问须要已获取手机号码的页面时，可通过小程序端使用 button + getPhoneNumber 的方式请求用户授权
   

5. code2session、getUserInfo、getPhoneNumber 等接口返回数据存入数据库 dt_weapp_user

6. 服务端的任何接口均返回口令状态包（含自定义会话口令等信息），小程序端应保存于 storage
   

7. 请求 getUserInfo 后应判断 detail.errMsg 是否为 getUserInfo:ok，请求 getPhoneNumber 后应判断 detail.errMsg 是否为 getPhoneNumber:ok

8. 授权窗口的弹出情况参此文

9. 口令状态包是用来传递到客户端用来标识用户唯一凭证的，包含字段：会话口令（自定义用户凭证）、会话口令有效时间（秒）、是否已获取 unionid 或昵称（视业务需求）、是否已获取手机号码、uid（可选），以及其他用来标识业务身份字段。服务端可根据会话口令从数据库中获取该用户的所有已知信息。

   一般情况下，当已获取手机号码时，uid 必有值，否则，uid 必为空。因此 uid 不是必须传递到客户端的。

   通过 code2Session 获得的 session_key、以及 openid、unionid、手机号码等机密信息不允许包含在口令状态包中并缓存在客户端，客户端需要用到手机号码时单独调用接口获取。

10. 若业务不要求以手机号码作为用户唯一标识，那么口令状态包中不需要包含是否已获取手机号码，仅 uid 即可。在客户端访问须要业务用户登录的页面时，也仅判断 uid 有值即可。
    

流程图：

为更好地适应 2017.7.19 发布的《小程序内用户帐号登录规范调整和优化建议》，开发者服务器提供的所有业务逻辑接口的返回值中都应包含口令状态包，约定有以下相关的返回值和处理动作（返回值按个人喜好来定）：

• WWW-Authenticate 有大小写的问题，千万别入坑，参：https://xoyozo.net/Blog/Details/header-www-authenticate
  

• 返回内容是根据业务逻辑在服务端决定的，客户端在处理每个接口返回值时对返回内容作相应的处理即可。

【推荐】临时口令和会话口令合二为一的流程（适合随时授权）

前提：

小程序已绑定到微信开放平台。

分两种场景：

场景一：仅需要获取 unionid，且不需要获取头像昵称等用户信息，且已经有很大部分用户仅通过 code2Session 就能获取到 unionid（如：已关注了绑定同一微信开放平台的其它公众号，参 UnionID 机制说明）；

场景二：仅需要获取 unionid，或需要获取 unionid 及头像昵称等用户信息，或很大部分用户不能通过 code2Session 获取到 unionid。

场景一步骤：

1. 小程序调用 wx.login()，将 code 发送到开发者服务器

2. 开发者服务器请求微信接口 code2Session，获得 session_key、openid，有机会获得 unionid

3. 若没有返回 unionid，尝试用 openid 从数据库中获取 unionid

4. 如果数据库中没有找到对应的 unionid，告知小程序端使用 button + getUserInfo 的方式请求用户授权

5. 授权允许（判断 detail.errMsg 是否为 getUserInfo:ok）则将加密数据传回开发者服务器进行解密，得到 unionid、头像、昵称等信息，保存到数据库

6. 若授权拒绝，则无动作，用户再次点击 button 会重新弹起授权框

* 该流程仅部分用户的首次使用才要求授权。其它注意事项和流程细节见下方流程图。

场景二步骤：

1. 小程序调用 wx.login()，将 code 发送到开发者服务器

2. 开发者服务器请求微信接口 code2Session，获得 session_key、openid

3. 尝试用 openid 从数据库中获取 unionid 和/或 用户信息

4. 如果数据库中没有找到对应的 unionid 和/或 用户信息，告知小程序端使用 button + getUserInfo 的方式请求用户授权

5. 授权允许（判断 detail.errMsg 是否为 getUserInfo:ok）则将加密数据传回开发者服务器进行解密，得到 unionid、头像、昵称等信息，保存到数据库

6. 若授权拒绝，则无动作，用户再次点击 button 会重新弹起授权框

* 该流程仅每个用户的首次使用才要求授权。其它注意事项和流程细节见下方流程图。

上述两种场景的设计流程，只要数据库中已保存用户的 unionid（和/或 用户信息），都不再需要用户再次授权（即使在“设置”中关闭了“用户信息”授权，点击小程序右上角三点按钮，选择关于小程序，点击右上角的三点，选择设置）。

场景一流程图：

场景二流程图：

流程图中的“临时口令”仅用于关联“通过 code2Session 获得的 session_key”，并在用户授权后带回换取 session_key。原因是 session_key 是机密数据，不允许被传到小程序端。临时口令用完即删（设置表 dt__weapp_code2session 中相应记录的该字段为空）。

【推荐】临时口令和会话口令合二为一的流程（适合随时授权）

Input string is not a valid interger. Path 'batteryLevel', line 1, position 447.

使用 uni-app 开发小程序的时候，获取系统信息（getSystemInfoSync()）在 iPhone X 上报错，原因是电池电量值无法转换为 int 型。出现的情况是偶发性的，但一旦出现，一段时间内会一直出现（可能等电量值更新了才会正常吧）。不知道是 uni-app 的 bug 还是微信小程序的 bug。问了度娘和必应国际，暂时没有找到答案。

HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure

Common causes of this issue:

• The application process failed to start

• The application process started but then stopped

• The application process started but failed to listen on the configured port

Troubleshooting steps:

• Check the system event log for error messages

• Enable logging the application process' stdout messages

• Attach a debugger to the application process and inspect

For more information visit: https://go.microsoft.com/fwlink/?LinkID=808681

发现装错了东西，服务器上应该安装 dotnet-hosting-*.*.*-win.exe，而非 dotnet-runtime-*.*.*-win-x64.exe