这个现象在国产浏览器上使用极速内核时出现，原因是百度编辑器上传图片功能通过 <form /> 提交到 <iframe /> 时，因跨域导致 cookie 丢失。
ASP.NET 的 ASP.NET_SessionId 默认的 SameSite 属性值为 Lax，将其设置为 None 即可：
protected void Session_Start(object sender, EventArgs e)
{
// 解决在部分国产浏览器上使用百度编辑器上传图片时（iframe），未通过 cookie 传递 ASP.NET_SessionId 的问题
string ua = Request.UserAgent ?? "";
var browsers = new string[] { "QQBrowser/" /*, "Chrome/" 不要直接设置 Chrome，真正的 Chrome 会出现正常页面不传递 Cookie 的情况 */ };
bool inWeixin = ua.Contains("MicroMessenger/"); // 是否在微信中打开（因微信PC端使用QQ浏览器内核，下面的设置会导致其网页授权失败）
if (browsers.Any(c => ua.Contains(c)) && !inWeixin)
{
Response.Cookies["ASP.NET_SessionId"].SameSite = SameSiteMode.None;
}
}以上代码加入到 Global.asax 的 Session_Start 方法中，或百度编辑器所在页面。
注意一：SameSite=None 时会将父页面的 cookie 带入到 iframe 子页的请求中，从而导致 cookie 泄露，请确保项目中无任何站外引用，如网站浏量统计器、JS组件远程CDN等！
注意二：微信PC版的内嵌浏览器使用QQ浏览器内核，以上代码会导致其微信网页授权不能正常执行。
2020年5月30日，AddTrust External CA Root 过期，虽然不影响客户端浏览器访问网站，但服务器端调用接口（file_get_contents）会出现问题，原因是证书链中根证书过期（必须使用检测工具检查服务端的证书链，而不是查看客户端浏览器上的证书信息，因为客户端浏览器上看到的的根证书是客户端系统上的根证书，是随着系统自动更新的）。
这里，Windows Server 的 IIS 与 CentOS 中的 nginx 又有所区别，咱们分开来讲：
如何更新 Windows Server 的 IIS 中的网站的根证书？
Windows Server 本身相当于一个客户端，会自动更新根证书，只不过 IIS 中的网站证书未同步更新。
打开 IIS，进入对应网站的“绑定”界面，重新绑定即可生效。简单的方法是简单修改主机名，确定，再改回原主机名，确定。
如何更新 CentOS 的 nginx 中的网站的根证书？
nginx 中使用的域名证书（pem 文件），即 conf 文件中设置的 ssl_certificate 路径对应的证书文件，是包含根证书信息的：
因此保留第一段域名证书信息，用新的根证书信息替换掉除第一段的其它内容即可。
项目 "***" 指向“netstandard2.1”。它不能被指向“.NETFramework,Version=v4.8”的项目引用。
可能的原因是：Standard 库项目中存在一些警告，譬如 NuGet 包中的 Newtonsoft.Json 12.0.3 可能不兼容 Standard 2.1
解决这些警告，Web 项目再重新引用库项目即可正常发布。
情况：
马甲 App 添加链接 a（域名 A），该页面跳转至页面 b（域名 B），信任域名添加 B。
现象：
无法获取 token，即授权不成功。
原因：
马甲 App 是判断首次打开的域名（即本例中的域名 A）是否在信任域名中。
解决：
将上述两个域名都填到信任域名中，或直接添加链接 b，不使用链接 a 作跳转。
另外提醒：
信任域名是真实的 token，合作域名是临时的 token，区别是权限高低；
配置完域名白名单后，应该重启 App 再测试，因为客户端有缓存。
使用 myssl.com 检测证书状态，显示握手失败（No FS No SNI）：
发现 XP 上的 IE6 和 IE8 均无法访问该站点，原因是 XP 不支持 FS，不支持 SNI。
可以尝试在 IIS 的站点的“绑定”中更改“需要服务器名称指示”来实现正常访问。
步骤参阅：https://xoyozo.net/Blog/Details/wxpay-notify-url-https
当然，前提是服务器上必须已启用相关的协议版本和加密方式（按需启用），建议使用 IISCrypto。
当 MySQL 中使用 tinyint(1) 作为布尔值类型时，ASP.NET Core DBFirst 创建模型时会将其定义为 sbyte，运行时会抛出异常：
InvalidCastException: Unable to cast object of type 'System.Boolean' to type 'System.SByte'.
我们可以在数据库连接字符串中加入 TreatTinyAsBoolean=false 来实现不抛出异常，但程序中赋值和判断该字段时还是会比较麻烦。
因此我更倾向于将数据库中该字段类型改为 bit(1)。
2019.11.28 注：这回遇到 tinyint(1) 映射到了 C# 的 bool，而 bit(1) 却映射到了 ulong。具体什么原因未作排查，反正哪个最终为 bool 就选哪个吧。
前言：
ChatGPT 给了 3 条建议：
在应用程序中正确释放数据库连接。确保在使用完数据库连接后，将其关闭并将其返回到连接池中。您可以使用 using 语句来确保连接在使用完毕后被正确释放。
调整连接池的大小。默认情况下，连接池的最大大小为 100。如果您的应用程序需要更多的连接，则可以增加连接池的大小。您可以在连接字符串中设置 Max Pool Size 属性来调整连接池的大小。
调整连接池的超时时间。默认情况下，连接池中的连接在 30 秒钟内未使用时将被关闭。如果您的应用程序需要更长的连接时间，则可以增加连接池的超时时间。您可以在连接字符串中设置 Connection Lifetime 属性来调整连接池的超时时间。
亲测有效，尤其是第 3 条，原因是 Connection Lifetime 的默认值是 0，即没有超时限制。
—— 2023.5
一般地，我们使用 EF 连接数据库前会先初始化一个数据库上下文：
dbEntities db = new dbEntities();虽然 ASP.NET 会在查询完毕后自动关闭该连接，但是在什么情况下回收等都是不确定的，所以会导致 MySQL 中出现很多 Sleep 的连接（执行命令 SHOW FULL PROCESSLIST 可见），占用数据库的连接数，除非主动调用 Dispose()：
db.Dispose();官方建议的写法是使用 using 语法：
using (dbEntities db = new dbEntities())
{
}using 会自动调用 Dispose()。这样对减少连接数是很有效的，但官方提示为了提高下一次连接的速度，并不会完全关闭所有连接。
C# 8 建议写法：
using dbEntities db = new dbEntities();在实际项目中（该项目有 500+处数据库连接）测试结果，在不执行 Dispose() 时稳定为 140 个左右连接数，使用 using 或 Dispose() 后稳定变为 40 个左右。
如果不小心在 using 外部或 Dispose() 后再次对该上下文执行查询操作会出现异常：
无法完成该操作，因为 DbContext 已释放。
或
此 ObjectContext 实例已释放，不可再用于需要连接的操作。
所以要避免出现这种情况。这里还有一种另类的解决方法（不建议），根据上下文的特性，只要在 using 内查询一次（譬如视图中需要用到的导航属性，即外键关联的表），就可以在外部使用这个属性。
（建议）在 ASP.NET MVC 或 Web API 项目中，如果一个控制器中仅在 Action 外部定义一个 DbContext，那么，只要重写该控制器的 Dispose() 方法即可：
private dbEntities db = new dbEntities();
protected override void Dispose(bool disposing)
{
if (disposing)
{
db.Dispose();
}
base.Dispose(disposing);
}上下文使用 private 修饰即可。
| 变量名 | 字段名 | 官方描述 |
| return_code | 返回状态码 | SUCCESS/FAIL 此字段是通信标识，非交易标识，交易是否成功需要查看 trade_state 来判断 在“统一下单”和“支付结果通知”中，该描述变成了：交易是否成功需要查看 result_code 来判断 |
| result_code | 业务结果 | SUCCESS/FAIL |
| trade_state | 交易状态 | SUCCESS — 支付成功 REFUND — 转入退款 NOTPAY — 未支付 CLOSED — 已关闭 REVOKED — 已撤销（付款码支付） USERPAYING — 用户支付中（付款码支付） PAYERROR — 支付失败（其他原因，如银行返回失败） |
总的来说，
return_code 是用来判断通信状态的，个人理解在“结果通知”时必为 SUCCESS；
result_code 是用来判断业务结果的，指一次调用接口或回调的动作是否如愿执行成功。如“关闭订单”时关闭成功为 SUCCESS，因参数配置错误、找不到订单号、订单状态不允许关闭等其它关闭失败的情况为 FAIL；
trade_state 是用来判断交易状态的，“交易”是指微信支付订单。
另，在“统一下单”和“支付结果通知”中，return_code 的描述变成了：交易是否成功需要查看 result_code 来判断。不知道是官方笔误，还是真的可以用来判断交易是否成功，因为在调用“统一下单”时是未支付状态，根本没有支付成功的可能。
保险起见，我们在异步收到“结果通知”时，不要相信文档去判断 result_code，应调用“查询订单”，并判断 trade_state。
微信支付商户可以直接注册，也可以由公众号、小程序、开放平台等开通。
直接注册时可勾选使用的公众号、小程序、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
本文讲述使用网页开发适用于宴会、活动、年会现场 LED 大屏幕显示抽奖、抢楼、游戏、视频等互动界面，通过在浏览器中打开后 F11 全屏投影到大银幕上。
设计思路：
为了保证最佳的显示效果，设计稿的尺寸按大屏幕的“宽高比”来做（本文以4米*3米的大银幕为例，设计稿以800*600像素为例）。
由于电脑的视频输出分辨率很有可能与大银幕的宽高比不同，那么我们全屏投影后会界面会有变形，但是投影设备接收到电脑视频信号后再全屏显示到大银幕时，界面又会变回正常。
按设计稿的尺寸开发网页，并使用 CSS3 的 scale 实现整体伸缩，目的是自适应窗口尺寸来全屏显示内容，无留白、无裁切。整体拉伸的要求是文字、图片、背景、间距、iframe 等所有元素以统一的比例拉伸，无错位。
网页上通过 JS 设置一些快捷键来实现页面展示内容的切换。
若投影设备功能有限或操作员水平有限等原因导致无法顺利设置输入输出分辨率时，网页可设置 x 轴和 y 轴两个方向的伸缩系数、定位偏移量等，更灵活地实现完美投影需求。
开发要点：
网页尺寸按设计稿来定（以 800x600 为例）。
使用 CSS3 的 transform 的 scale 来实现缩放，以电脑显示器分辨率 1920x1080，宽放大 1920/800 倍，高放大 1080/600 倍，即可将设计稿全屏展示到电脑显示器上。为了更灵活，我们使用窗口大小来代替显示器分辨率，这样不管怎么改变窗口大小或者全屏，设计稿都能完整地显示在窗口上。
在页面初始化和窗口尺寸变化时重新调整设置上述比例。
代码参考：