博客 (208)

前言：

ChatGPT 给了 3 条建议：

1. 在应用程序中正确释放数据库连接。确保在使用完数据库连接后，将其关闭并将其返回到连接池中。您可以使用 using 语句来确保连接在使用完毕后被正确释放。

2. 调整连接池的大小。默认情况下，连接池的最大大小为 100。如果您的应用程序需要更多的连接，则可以增加连接池的大小。您可以在连接字符串中设置 Max Pool Size 属性来调整连接池的大小。
   

3. 调整连接池的超时时间。默认情况下，连接池中的连接在 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 修饰即可。

参考：SQL Server 连接池 (ADO.NET)

原标题：关于 PHP 获取 IP 地址的几种方法

PHP 获取客户端的 IP 地址有 4 种方式：

1. REMOTE_ADDR：浏览当前页面的用户计算机的 IP 地址

2. HTTP_X_FORWARDED_FOR：记录代理信息，会把每一层代理都记录

3. HTTP_CLIENT_IP：客户端的 IP
   

4. X-Real-IP：没有标准，由上一跳决定

REMOTE_ADDR 一般是不能伪造的，因为是通过服务器与客户端握手协议来获取的。而 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP 是在 header 信息里面，所以客户端是可以进行很轻松的伪造。下面是对这三种方式详解：

https://www.v2ex.com/t/230367

https://www.test404.com/post-1448.html

https://www.cnblogs.com/mypath/articles/5239687.html

一、关于 REMOTE_ADDR
这个变量获取到的是“直接来源”的 IP 地址，所谓“直接来源”指的是直接请求该地址的客户端 IP 。这个 IP 在单服务器的情况下，很准确的是客户端 IP ，无法伪造。当然并不是所有的程序都一定是单服务器，比如在采用负载均衡的情况（比如采用 haproxy 或者 nginx 进行负载均衡），这个 IP 就是转发机器的 IP ，因为过程是客户端 -> 负载均衡 -> 服务端。是由负载均衡直接访问的服务端而不是客户端。

二、关于 HTTP_X_FORWARDED_FOR 和 HTTP_CLIENT_IP
基于“一”，在负载均衡的情况下直接使用 REMOTE_ADDR 是无法获取客户端 IP 的，这就是一个问题，必须解决。于是就衍生出了负载均衡端将客户端 IP 加入到 HEAD 中发送给服务端，让服务端可以获取到客户端的真实 IP 。当然也就产生了各位所说的伪造，毕竟 HEAD 除了协议里固定的那几个数据，其他数据都是可自定义的。

三、为何网上找到获取客户端 IP 的代码都要依次获取 HTTP_CLIENT_IP 、 HTTP_X_FORWARDED_FOR 和 REMOTE_ADDR
基于“一”和“二”以及对程序通用性的考虑，所以才这样做。 假设你在程序里直接写死了 REMOTE_ADDR ，有一天你们的程序需要做负载均衡了，那么你有得改了。当然如果你想这么做也行，看个人爱好和应用场景。也可以封装一个只有 REMOTE_ADDR 的方法，等到需要的时候改这一个方法就行了。

X_FORWARDED_FOR 与 X-Real-IP 的区别：

X_FORWARDED_FOR：记录了所有链路里的代理 IP 值，比如下面所说的，经过了 3 次代理，分别是 1.1.1.1, 2.2.2.2, 3.3.3.3，其中 1.1.1.1 是客户端 IP，2.2.2.2 是代理服务器，接下来同理。

X-Real-IP：是只会记录前一次代理的 IP 地址。

一般来说，X-Forwarded-For是用于记录代理信息的，每经过一级代理(匿名代理除外)，代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中

来自4.4.4.4的一个请求，header 包含这样一行

X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3

代表请求由1.1.1.1发出，经过三层代理，第一层是2.2.2.2，第二层是3.3.3.3，而本次请求的来源IP4.4.4.4是第三层代理

而X-Real-IP，没有相关标准，上面的例子，如果配置了X-Read-IP，可能会有两种情况

// 最后一跳是正向代理，可能会保留真实客户端IP
X-Real-IP: 1.1.1.1
// 最后一跳是反向代理，比如Nginx，一般会是与之直接连接的客户端IP
X-Real-IP: 3.3.3.3

所以 ，如果只有一层代理，这两个头的值就是一样的。

那一般在后端取值（比如 node.js 通过 nginx 代理）是用哪个值呢？我看 sf 上看一般推荐是用 X-Forwarded-For，直接用 X-Real-IP 岂不是更方便点？

X-Forwarded-For 确实是一般的做法

1. 他在正向（如 squid）反向（如 nginx）代理中都是标准用法，而正向代理中是没有 x-real-ip 相关的标准的，也就是说，如果用户访问你的 nginx 反向代理之前，还经过了一层正向代理，你即使在 nginx 中配置了 x-real-ip，取到的也只是正向代理的 IP 而不是客户端真实 IP

2. 大部分 nginx 反向代理配置文章中都没有推荐加上 x-real-ip ，而只有 x-forwarded-for，因此更通用的做法自然是取 x-forwarded-for

3. 多级代理很少见，只有一级代理的情况下二者是等效的

4. 如果有多级代理，x-forwarded-for 效果是大于 x-real-ip 的，可以记录完整的代理链路

1、将以下代码保存为 Client.php

// php 脚本开始
$ch = curl_init();
$url = "http://localhost/ser.php";
$header = array('CLIENT-IP:208.165.188.175', 'X-FORWARDED-FOR:208.165.188.175');
// 声明伪造 head 请求头
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
$page_content = curl_exec($ch); curl_close($ch);
echo $page_content;

2、将以下代码保存为 ser.php

// php 脚本开始
echo getenv('HTTP_CLIENT_IP');
echo getenv('HTTP_X_FORWARDED_FOR');
echo getenv('REMOTE_ADDR');

测试结果为

208.165.188.175
208.165.188.175
127.0.0.1

上面结果可看出，http_client_ip、http_x_forwarded_for 都被伪造了，而 remote_addr 还是127.0.0.1 就是客户端 IP

总结：

如果我们没用到负载均衡（CDN）的话直接用 REMOTE_ADDR 获取 IP。

如果使用了一级 CDN 的话，CDN 会把 REMOTE_ADDR 转发成 X-Real-IP，我们服务器可以获取 X-Real-IP 来获取 IP 值。如果是多级 CDN 的话需要我们来做 nginx 代理，详细：https://www.cnblogs.com/princessd8251/articles/6268943.html

就是第一台负载服务器获取 REMOTE_ADDR 转发成 X-Real-IP，之后的去继承前一台的 X-Real-IP 就可以了，这里记住必须是去继承，不然第二台会把第一台的 REMOTE_ADDR 转发成 X-Real-IP 导致错误。

在 discuz! 中的获取 IP 的方法：

private function _get_client_ip() {
    $ip = $_SERVER['REMOTE_ADDR'];
    if (isset($_SERVER['HTTP_CLIENT_IP']) && preg_match('/^([0-9]{1,3}\.){3}[0-9]{1,3}$/', $_SERVER['HTTP_CLIENT_IP'])) {
        $ip = $_SERVER['HTTP_CLIENT_IP'];
    } elseif(isset($_SERVER['HTTP_X_FORWARDED_FOR']) AND preg_match_all('#\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}#s', $_SERVER['HTTP_X_FORWARDED_FOR'], $matches)) {
        foreach ($matches[0] AS $xip) {
            if (!preg_match('#^(10|172\.16|192\.168)\.#', $xip)) {
                $ip = $xip;
                break;
            }
        }
    }
    return $ip;
}

这里 DZ 为了符合有些用户会用代理，所以才首先使用了两个容易伪造的方法，如果有需要可以自行修改。

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

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

直接注册时可勾选使用的公众号、小程序、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 方式发布。

前提：

若需获取用户 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
  

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

其它 scope 会在用到时补充……

“允许后再发起，不弹”的 scope 可在“关于XXX小程序”右上角三点按钮中的“设置”来设置是否允许。

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

前提：

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

分两种场景：

场景一：仅需要获取 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 中相应记录的该字段为空）。

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

微信小程序 login 后，在用 code 换 session 时，如果小程序绑定了微信开放平台，应该会返回 unionid。

文档：https://developers.weixin.qq.com/miniprogram/dev/api-backend/code2Session.html。

但实际上部分用户仍然是没有 unionid 的，把上述接口返回的数据记录下来如：

仔细阅读官方 UnionID 机制说明，通过用户授权 wx.getUserInfo 才会保证有 unionid 返回，否则只会在“用户关注了绑定同一微信开放平台的同主体的公众号”等情况下才会返回 unionid。

确保获取 unionid 流程参此文。