博客 (115)

完整操作步骤如下：

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

前言：

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

无法向会话状态服务器发出会话状态请求。请确保 ASP.NET State Service (ASP.NET 状态服务)已启动，并且客户端端口与服务器端口相同。如果服务器位于远程计算机上，请检查 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection 的值，确保服务器接受远程请求。如果服务器位于本地计算机上，并且上面提到的注册表值不存在或者设置为 0，则状态服务器连接字符串必须使用“localhost”或“127.0.0.1”作为服务器名称。

无法连接 StateService 的原因有很多种，我遇到的情况是：

VS 中使用 IISExpress 调试项目，系统没有安装 IIS，

ASP.NET 状态服务是开启状态，

没有对系统作任何修改，无缘无故无法连接。

修改注册表、配置防火墙无效（我没有用到远程连接），

执行 aspnet_regiis -i -enables 无效，

重装 .NET Framework 4.8 Developer Pack 无效，

差点就重装系统了。

最终的解决方法是：

在“启用或关闭 Windows 功能”中勾选安装：Internet Information Services -> 万维网服务 -> 应用程序开发功能 -> ASP.NET 4.8

重启系统。

这是一篇可能解决困扰了 .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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
  

注册苹果开发者账号和发布 App 会填写一些联系邮箱，一旦账号或应用违规，苹果方也只会以解决方案中心或邮件的形式通知开发者，一旦超过时限，可能会采取一些强制措施，影响到我们的 App 正常上架运营，本文罗列了一些相关的电子邮箱，如有不全请指正。

1. 在注册 Apple ID （https://appleid.apple.com/account/manage）时会填写 3 个邮箱，一个用于登录用户名，一个作为常规联系，第 3 个是用于救援（估计是常规联系邮箱失效时才会用到）。

   
   

2. 在 App Store Connect （https://appstoreconnect.apple.com/）中发布新版本 App 时会填写两个邮箱，一个是 App 的联系邮箱，一个是审核联系邮箱。

   
   

3. 当我们在联系审核团队（https://developer.apple.com/contact/app-store/）时，可能会填写一个邮箱，用于针对当前问题进行反馈。

4. 苹果的“联系我们”（https://developer.apple.com/contact/）
   

5. 其它一些主动提交的信息，用于反馈，如：投诉侵犯知识产权（https://www.apple.com/legal/internet-services/itunes/appstorenotices/#?lang=zh）
   

这是一个数据可视化项目，基于D3.js。能够将历史数据排名转化为动态柱状图图表。

先来看看效果：

https://xoyozo.net/Demo/BarGraph

作者 Jannchie 见齐还提供了官方视频教程：

https://www.bilibili.com/video/av28087807

不过由于开源项目的不断更新，该教程的部分内容已失效，本文针对 2018-12-25 版本总结了一些常用的配置说明，仅供参考。

从 GitHub 下载源代码，在 src 目录中可以看到 4 个文件：

bargraph.html --> 运行示例页面

config.js --> 配置文件

stylesheet.css --> 样式表

visual.js --> 核心文件

作者并没有将代码封装为插件的方式，所以我们是通过修改 config.js 配置文件的方式应用到自己的项目中的。

visual.js 虽然是核心文件，但作者将部分示例中的代码也包含其中，但并不影响我们直接在自己的项目中引用。

以下是 config.js 中的主要属性：

在学习和使用 ASP.NET Web API 之前，最好先对 RESTful 有所了解。它是一种软件架构风格、设计风格，而不是标准。

推荐视频教程：https://www.imooc.com/learn/811

讲师：会飞的鱼Xia

需时：2小时25分

REST API 测试工具：

在 Chrome 网上应用店中搜索：Restlet Client

或网站 https://client.restlet.com

>>> 资源路径

SCHEME :// HOST [ ":" PORT ] [ PATH [ "?" QUERY ]]

其中 PATH 中的资源名称应该使用复数名词，举例：

GET https://xoyozo.net/api/Articles/{id}

POST https://xoyozo.net/api/Articles

>>> HTTP verb（对应 CURD 操作）：

>>> 过滤信息：

如分页、搜索等

>>> 常用状态码：

>> 错误处理：

C# 例：throw new HttpResponseException(HttpStatusCode.NotFound);

PHP 例：throw new Exception('文章不存在', 404);

>>> 返回结果：

JSON/XML

不要返回密码等机密字段

>>> 其它：

身份验证窗口（浏览器弹窗，类似 alert，非页面表单），明文传输，安全性不高，不建议使用。实现：

在 Headers 中添加 Authorization:Basic “用户名:密码”的 Base64 编码

1. 首先，手机打开【设置】-【更多设置】-【关于手机】-【版本信息】，触摸“软件版本号”7次。

2. 返回【更多设置】底部出现【开发者选项】，打开后开启【USB 调试】。

3. 使用数据线连接手机和电脑（注意必须使用数据线，而非一般充电宝附带的充电线，虽然插头类型是一样的），弹出“允许 USB 调试吗？”对话框，选择“确定”。

4. 电脑上安装 vivo 手机助手，就可以管理手机了。手机端可以安装手机助手。

5. 如果需要连接 HBuilderX 进行安卓应用调试，需要从手机顶部下划，将“USB已连接”中的“管理文件”更改为“传输照片”。并使用 vivo 手机助手手动安装调试基座（控制台中会提示）。