博客 (113)

完整操作步骤如下：

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 中的虚拟路径不规范。

Response.StatusCode = 403;
Response.End();

原标题：关于 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 为了符合有些用户会用代理，所以才首先使用了两个容易伪造的方法，如果有需要可以自行修改。

总的来说，

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

场景：每天带笔记本电脑上班，公司使用固定 IP 上网，家里网络的网段又跟公司不一样。

方法 1：两个网络环境分别使用有线连接和无线连接（鉴于笔记本无线网卡不支持 5G（802.11ac），或者有其它需求必须都使用有线连接的不适用此方法）。

方法 2：修改家里路由器的局域网 IP 地址，使其网段与公司相同（虽然仅需要一次修改，但部分路由器不允许修改局域网 IP 地址）；

方法 3：使用第三方软件一键切换（有安全隐患，且可能导致电脑网络设置出现错误）；

方法 4（推荐）：设置电脑网络连接同时使用两个 IP，具体方法如下：

打开“以太网 属性”，双击“Internet 协议版本 4 (TCP/IPv4)”，配置其中一个网络环境的 IP 地址和网关（例如我在公司上网的 IP 是 192.168.1.5，网关是 192.168.1.1）

点击“高级”，在 IP 地址栏添加另一个网络的 IP（如 192.168.31.5），在“默认网关”处添加这个网络的网关（如 192.168.31.1）

这样设置后，不管到公司还是回到家，只要网线一插就能上网，不需要每天更换 IP 地址设置了。

（图中显示了两个网络名称）

Visual Studio 2019 已于本月早些时候正式发布，但 MySQL for Visual Studio 却迟迟未更新，目前的 1.2.8 版本只支持到 VS2017。表现在 VS2019 上会发生：

• 在“服务器资源管理器”中添加连接时，或在新建“ADO.NET 实体数据模型”时，无法看到数据源“MySQL Database (MySQL Data Provider)”

• 在实体数据模型设计器（Entity Data Model Designer）中执行“从数据库更新数据模型”时出现错误：尝试从数据库进行更新时，遇到类型为“System.ArgumentException”的异常。异常消息为:“无法将运行时连接字符串转换为设计时等效项。没有为提供程序“MySql.Data.MySqlClient”安装为设计目的(DDEX 提供程序)启用 Visual Studio 以便与数据库进行通信所需的库。 

幸运的是 VS2019 可以与低版本 VS 共存，使用 ASP.NET 连接 MySQL 的开发者们要再等一等才能用上 VS2019 了。

这几天 MySQL 不断有产品更新，相信 MySQL for Visual Studio 2019 也会在不久的将来面世，本站将第一时间更新下载地址。

2019.8.30 Jose Ramirez（来自 MySQL 的 Windows 团队）：MySQL for Visual Studio 的当前版本不支持 Visual Studio 2019。正在努力提供支持，但根据公司政策，我无法披露日期或对何时可用提供任何承诺。查看

2019.9.26 MySQL for Visual Studio 迟迟未更新，但是 VS2019 更新到最新版本（v16.3）已经一切正常了。

MySQL for Visual Studio 的 Repair 功能是鸡肋，有问题的话，Remove 后重新安装才能解决。

如何查看 ASP 详细错误信息

解决办法：

1. 打开 IIS，在相应网站的功能视图中双击“错误页”，在右侧“操作”栏中点击“编辑功能设置…”，将“错误响应”更改为“详细错误”。

2. 在功能视图中双击“ASP”，展开“调试属性”，“将错误发送到浏览器”设为 True。记得在网站调试完成后还原此项设置。

3. 若仍不显示，本地浏览器去掉了“显示 http 友好错误提示”选项。

这是一篇可能解决困扰了 .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 方式发布。

如果你是刚入手的小米 WiFi 电力猫，那么按说明书一步一步配置即可。这里记录一下移机的重置方法。

本次移机的场景是电力猫从一台小米路由器更换到另一台小米路由器的配置，两台小米路由器 WIFI 的 SSD 不同（假设为 WIFI-A 和 WIFI-B）。

错误做法：打开米家，切换到 WIFI-B 所在的房间，点击右上角的添加新设备，根据介绍插上子猫，并按子猫的配置键 5 秒以上。连上“xiaomi-plc-xxx”，米家显示正在连接，但到达 100% 后显示连接超时。

可能的错误原因：

1. 没有插上主猫

2. 该电子猫已经在米家上添加过了（在 WIFI-A 所在的房间），就无法添加到其它房间了（仅猜测，未实测）

于是，同时插上主猫和子猫，并且路由器和主猫使用网线连接，什么都不设置，过一两分钟，两猫自动会变成蓝灯（表示连接成功）。这时，如果刚才那步没有重置成功的话，打开米家主界面上的“小米电力线wifi扩展器”（如果没有删除过，还在 A 房间），里面会显示网络名称为 WIFI-A，还可能没有开“WIFI漫游”。这样虽然能连接上网，但有两个 SSD，不能实现漫游。

这时，按子猫配置键 5 秒以上，并静等一分钟以上，变回蓝灯后，再打开米家，就会看到网络名称可能是 WIFI-B-Plus，这时"WIFI漫游”也能打开了，完美扩展了 WIFI。

综上实践得出：

WIFI 是由子猫负责的，所以跟 SSD 有关的配置由子猫负责；

一台设备（这里指电子猫套餐）只能添加到米家一次，但可以更改设备所在的房间。

正确的重置电力猫步骤是：

1. 同时插上主猫和子猫

2. 主猫连上路由器

3. 子猫按配置键 5 秒以上，等待一分钟以上

4. 打开米家，进入“小米电力线wifi扩展器”，打开 WIFI 漫游

以上仅在使用小米路由器情况下实测，非小米路由器未尝试。