Discuz! 数据库加索引
待优化的 SQL：（pre_forum_thread 表有 150 万条数据）
SELECT * FROM pre_forum_thread WHERE `fid`='62' AND `displayorder` IN('0','1','2','3','4') ORDER BY displayorder DESC, dateline DESC LIMIT 20, 20加索引前，
EXPLAIN 结果 Extra 为：Using index condition; Using where; Using filesort
> 时间: 0.915s
加索引后：`fid`, `displayorder`, `dateline`
EXPLAIN 结果 Extra 为：Using where 或 Using index condition
> 时间: 0.001s
magapp 数据库加索引
待优化的 SQL：（mag_score_action_log 表有 200 万条数据）
SELECT COUNT(*) AS tp_count
FROM `mag_score_action_log`
WHERE action_id = 20
AND user_id = 650070
AND create_time >= 1534953600
AND create_time < 1535040000
LIMIT 1加索引前，
EXPLAIN 结果 Extra 为：?????
> 时间: 70s
加索引后：`action_id`, `user_id`, `create_time`
EXPLAIN 结果 Extra 为：Using where; Using index
> 时间: 0.073s
待优化的 SQL：（mag_score_mission_log 表有约 55 万条数据）
SELECT COUNT(*) AS tp_count
FROM `mag_score_mission_log`
WHERE mission_id = 7
AND user_id = 650070
AND create_time >= 1534953600
AND create_time < 1535040000
LIMIT 1加索引前，
EXPLAIN 结果 rows 为：549178
> 时间: 17.719s
加索引后：`mission_id`, `user_id`, `create_time`
EXPLAIN 结果 rows 为：1
> 时间: 0.025s
待优化的 SQL：（mag_score_mission_user 表有约 28 万条数据）
SELECT *
FROM `mag_score_mission_user`
WHERE `user_id` = 431779
AND `mission_id` = 5
AND `create_time` >= 1534953600
ORDER BY complete_count DESC
LIMIT 1不加索引
1SIMPLEmag_score_mission_userALL282436Using where; Using filesort
> 时间: 7.325s
`user_id`, `mission_id`
1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where; Using filesort
时间: 0.014s
`user_id`, `mission_id`, `create_time`
1SIMPLEmag_score_mission_userrangeix_us_miix_us_mi151Using index condition; Using filesort
时间: 0.023s
`user_id`, `mission_id`, `complete_count`
1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where
> 时间: 0.014s
`user_id`, `mission_id`, `complete_count`, `create_time`
1SIMPLEmag_score_mission_userrefix_us_miix_us_mi10const,const7Using where
> 时间: 0.028s
`user_id`, `mission_id`, `create_time`, `complete_count`
1SIMPLEmag_score_mission_userrangeix_us_miix_us_mi151Using index condition; Using filesort
> 时间: 0.025s
其它就不一一举例了，根据 SHOW FULL PROCESSLIST 的慢查询自行加索引就行了。
工作这几年碰到的版本检测升级的接口也算是五花八门，啥样的都有，但肯定有的功能是有个 apk 的下载链接，能间接或直接提示你是强制还是非强制更新：
间接是指提供你后台最新版本号，让你自己与本地版本号通过比较得出是否升级；
直接就是后台接口直接返回个 Boolean 类型告诉你是强制或者非强制更新。
个人认为一个好的版本检测接口需要设计的更灵活更清晰用起来更方便，下面就我理解的接口设计如下（如思路有误，欢迎指正）：
总字段如下(并不是所有字段都要返回给客户端)：
1.最新版本号 ：newVersion
2.最小支持版本号 : minVersion
3.apk 下载 url : apkUrl
4.更新文案 : updateDescription
5.是否有更新 : isUpdate
6.是否强制更新 : forceUpdate 可选字段：
7.apk 文件大小：apkSize
8.apk 的文件 MD5 值：md5方案一(后端处理逻辑)：
在客户端请求参数中添加当前版本号 currentVersion 传输给后台，由后台根据客户端传过来的当前版本号 currentVersion 做相应的判断后给出是否强制更新。
后端逻辑如下：
如果 currentVersion < newVersion, 则 isUpdate = true；
如果 currentVersion < minVersion, 则 forceUpdate = true；
如果 currentVersion >= minVersion, 则 forceUpdate = false;
如果有特殊需求可指定某个版本必须强制更新，如 currentVersion == XXX, 则 forceUpdate = true;
如果 currentVersion == newVersion，则 isUpdate = false.
结论：
返回客户端的字段仅需要 apk 下载 url : apkUrl、更新文案 : updateDescription、是否有更新 : isUpdate 、 是否强制更新 : forceUpdate 这四个字段即可。
方案二（前端处理逻辑）：
逻辑和后端处理逻辑大体上一致，只是把逻辑判断移到前台，故需要后端提供最新版本号 ：newVersion 、 最小支持版本号 : minVersion 、apk下载url : apkUrl 、更新文案 : updateDescription 这四个字段。
客户端逻辑如下：
如果 currentVersion < newVersion, 则有更新信息；
如果 currentVersion < minVersion, 则需要强制更新；
如果 currentVersion >= minVersion, 则不需要强制更新;
如果 currentVersion == newVersion，则没有更新信息。
总结：
细心的你可能会发现上面的可选字段 apkSize 和 md5 并没有用到，既然是可选字段也就是可用可不用，根据需要决定是否采用，这里来讲下他们的用处。
apk 文件大小 apkSize
这个用处可以说出于考虑用户体验，需要在升级弹框出来展示给用户将要更新的内容多大，让用户决定在非 WIFI 状态是否要更新，不能为了拉用户下载量或所谓的 UV 数直接让用户在不知道大小的情况下去直接下载（土豪用户绕路）。apk 的文件 MD5 值
这个主要是出于安全考虑吧，因为文件内容固定的话对应的 md5 是一样的，我们可以通过这个 md5 值来和下载的 apk 的 md5 值进行比较去保证我们从服务器更新下载的 apk 是一个完整的未被篡改的安装包，也就是说如果我们下载的 apk 的 md5 值和服务器返回的 md5 值相等，则说明我们下载的 apk 是完整的，且没有被相关有心人处理过的 apk。
综上所述，这个版本更新的处理逻辑客户端和后端谁来做都可以，无关乎懒不懒的问题，个人感觉灵活性后端比客户端方便多了，毕竟后端可以指定 minVersion 与 newVersion 中间的任意一个版本强制更新，而客户端做起来就没有那么灵活了，个人见解，如有更好的方案，欢迎指教。
本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)
本文基于 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）。
索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。
本文系个人实践总结，欢迎批评指正！
RHSA-2017:1842: kernel security, bug fix, and enhancement update (Important)
RHSA-2017:1615: kernel security and bug fix update (Important)
RHSA-2017:1372: kernel security and bug fix update (Moderate)
RHSA-2017:1308: kernel security, bug fix, and enhancement update (Important)
RHSA-2017:0933: kernel security, bug fix, and enhancement update (Important)
RHSA-2017:0892: kernel security and bug fix update (Important)
RHSA-2017:0817: kernel security, bug fix, and enhancement update (Moderate)
RHSA-2017:0307: kernel security and bug fix update (Moderate)
RHSA-2017:0036: kernel security and bug fix update (Important)
RHSA-2016:2766: kernel security and bug fix update (Important)
RHSA-2016:2105: kernel security update (Important)
RHSA-2016:2006: kernel security and bug fix update (Important)
RHSA-2016:1406: kernel security and bug fix update (Important)
RHSA-2016:0855: kernel security, bug fix, and enhancement update (Moderate)
RHSA-2016:0715: kernel security, bug fix, and enhancement update (Moderate)
修复命令：yum update kernel
修复后需要重新启动系统（阿里云技术回复：-devel 的组件涉及系统核心，必须重启才能生效），否则安骑士依然会提示漏洞待处理，漏洞依然存在。
扩展阅读：修改内核引导顺序（阿里云教程）
本文记录 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);
在 Windows 上安装 MySQL Server，提示需要安装 Microsoft Visual C++ 2013 Redistributable，但 MySQL Installer 安装向导中提供的 C++ 是 12.0.30501 版本：
导致无法正常安装 MySQL Server，仍然提示：
This application requires Visual Studio 2013 Redistributable. Please install the Redistributable then run this installer again.
解决办法是下载安装 Update for Visual C++ 2013 and Visual C++ Redistributable Package，即 12.0.40649.5 版本
安装成功
HTML5 Sortable 是一款使用原生 HTML5 drag 和 drop API 来对列表或网格进行排序的 jQuery 插件。
下载和使用：官网
步骤：
1、给 <ul /> 添加 sortable 样式类
2、引入 jquery.sortable.js
3、$('.sortable').sortable();
通过绑定 sortupdate 事件来获取排序后的 DOM 位置，示例：
$('.sortable').sortable().bind('sortupdate', function (event, ui) {
var item = $(ui.item[0]);
var prev = item.prev();
$.post(window.location.pathname, {
xdo: 'fn_sort',
cid: item.data('cid'),
prev: prev.data('cid') // 可能为 undefined
}, function (json) {
if (json.result.success) {
} else {
toastr['error'](json.result.info);
}
}, 'json');
});经测试，.NET Framework 4.8 的 Cache.Insert() 已恢复正常。
安装 .NET Framework 4.7 后，不管项目有没有升级到 .NET Framework 4.7，使用 Cache.Insert() 添加的自动过期的缓存都不会过期了，可以使用 Cache.Add() 来解决！
使用 Cache.Insert() 例：
HttpRuntime.Cache.Insert(key, value, null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration);改为使用 Cache.Add()：
HttpRuntime.Cache.Add(key, value, null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration, CacheItemPriority.Default, null);如果 Cache 中已保存了具有相同 key 的项，则调用 Add 方法将不作任何更改。（Insert 方法则会覆盖该值）
完整测试代码：
public static DateTime DateTimeNow
{
get
{
if (HttpRuntime.Cache["DateTimeNow"] == null)
{
HttpRuntime.Cache.Add("DateTimeNow", DateTime.Now,
null, DateTime.Now.AddSeconds(5), Cache.NoSlidingExpiration,
CacheItemPriority.Default, null);
}
return Convert.ToDateTime(HttpRuntime.Cache["DateTimeNow"]);
}
}在部分项目中（如 .NET Framework 4 项目中）发现上述改动仍不起作用，不会自动过期，那么可以采用以下方法：
方法一、可以记录将数据添加到 Cache 的时间，获取数据时判断该时间，超时则清除该 Cache 并重新赋值；
方法二、放弃缓存依赖，用定时器清除 Cache 数据。
新建项目
使用 VS2017 / VS2015 新建项目 - ASP.NET Web 应用程序 - MVC - 个人身份验证
添加模型
右击 Models 文件夹，添加类 Movie
using System;
using System.Data.Entity;
namespace MvcMovie.Models
{
public class Movie
{
public int ID { get; set; }
public string Title { get; set; }
public DateTime ReleaseDate { get; set; }
public string Genre { get; set; }
public decimal Price { get; set; }
}
public class MovieDBContext : DbContext
{
public DbSet<Movie> Movies { get; set; }
}
}Movie 类表示一部电影，一个对象实例对应数据库中一行，每个属性对应表中一列。
MovieDBContext 代表 EF 数据库上下文，处理抓取、存储、更新。
创建连接字符串和使用 SQL Server
打开 Web.config
在 <configuration /> 中的 <connectionStrings /> 中添加
<add name="MovieDBContext" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\Movies.mdf;Initial Catalog=Movies;Integrated Security=True" providerName="System.Data.SqlClient" />
name 必须与 DbContext 类的名称匹配（MovieDBContext）
这步将会把数据库文件 Movies.mdf 创建到 App_Data 文件夹中，你也可以使用其它 SQL Server 数据库的连接字符串，简单的方法是：
在“服务器资源管理器”中添加连接
从右击属性中获取连接字符串
从控制器访问模型的数据
右击 Controllers 文件夹添加控制器，选择 包含视图的 MVC 5 控制器(使用 Entity Framework)
模型类：Movie (MvcMovie.Models)
数据上下文类：MovieDBContext (MvcMovie.Models)
F5 运行，访问 /Movies 可添加、查看、编辑、删除影片
添加新字段
设置模型更改的 Code First 迁移
在程序包管理器控制台窗口中，在 PM> 提示符下输入
Enable-Migrations -ContextTypeName MvcMovie.Models.MovieDBContext
在 Migrations 文件夹中新建了 Configurations.cs，打开并在 Seed 方法中加入
context.Movies.AddOrUpdate(i => i.Title,
new Movie
{
Title = "When Harry Met Sally",
ReleaseDate = DateTime.Parse("1989-1-11"),
Genre = "Romantic Comedy",
Price = 7.99M
},
new Movie
{
Title = "Ghostbusters ",
ReleaseDate = DateTime.Parse("1984-3-13"),
Genre = "Comedy",
Price = 8.99M
}
);Seed() 将在每次迁移（PM>update-database）后被调用执行，AddOrUpdate 将执行 upsert 操作（有则 update，无则 insert）
AddOrUpdate 的第一个参数指定用于检查行是否已存在的属性
如果该属性值不唯，则出现异常
序列包含多个元素
创建迁移命令：
PM>add-migration Initial
名称“Initial”是任意的
执行迁移：
PM>update-database
F5 运行将显示种子数据
向 Movie 模型添加 Rating 属性
向 Movie 类添加属性，生成
public string Rating { get; set; }向 Create 和 Edit Action 方法的 Bind 属性添加 Rating
更改各视图支持新的 Rating 属性
此时 F5 运行将提示
System.InvalidOperationException:“支持“MovieDBContext”上下文的模型已在数据库创建后发生更改。请考虑使用 Code First 迁移更新数据库(http://go.microsoft.com/fwlink/?LinkId=238269)。”
要解决错误除了手动往数据库中添加 Rating 字段外可以利用 Code First 迁移：
更新 Migrations\Configuration.cs 给每个 Movie 对象添加一个 Rating 字段
PM>add-migration Rating
名称 Rating 是任意的
创建了 DbMigration 的派生类 Rating，可以看到添加新列的代码
PM>update-database
数据库自动完成了对新字段的添加，当然 update-database 也会把种子数据还原。
参考
Getting Started with ASP.NET MVC 5
UTC（世界协调时间）和 GMT（格林尼治标准时间）都与英国伦敦的本地时间相同。北京是东八区，即 UTC+8 或 GMT+0800
时间戳是指格林威治时间1970年01月01日00时00分00秒（北京时间1970年01月01日08时00分00秒）起至现在的总秒数。
翻译成程序员语言就是指当前的本地时间与 1970-1-1 0:00:00 UTC 时间换算的本地时间相差的秒数
或者当前的 UTC 时间与 1970-1-1 0:00:00 UTC 时间相差的秒数
以我在北京时间 2000/1/1 8:00:00 站在东八区为例：
在 JS 中：
// 获取当前本地时间： new Date() // 返回：Jan 1 2000 8:00:00 GMT+0800（中国标准时间） // 获取当前 UTC 时间字符串： (Local Time).toUTCString() // 返回：Jan 1 2000 0:00:00 GMT // 初始化一个 UTC 时间 2000-1-1 0:00:00 new Date(Date.UTC(2000, 1 - 1, 1, 0, 0, 0)) // 获取 UTC 时间的本地时间字符串： (UTC Time).toLocaleString() // 本地时间 1970/1/1 8:00:00 的时间戳 new Date(1970, 1 - 1, 1, 8, 0, 0).getTime() / 1000 // 返回：0 // 本地时间 2000/1/1 8:00:00 的时间戳 new Date(2000, 1 - 1, 1, 8, 0, 0).getTime() / 1000 // 返回：946684800 // 本地时间 当前 的时间戳 new Date().getTime() / 1000 // UTC 时间 2000/1/1 0:00:00 的时间戳 new Date(Date.UTC(2000, 1 - 1, 1, 0, 0, 0)).getTime() / 1000 // 或 Date.UTC(2000, 1 - 1, 1, 0, 0, 0) / 1000 // 返回：946684800
在 C# 中：
DateTime 默认的 Kind 是 Local，使用 DateTime.SpecifyKind() 方法可以定义一个 UTC 时间
DateTime.Now 返回当前本地时间
DateTime.UtcNow 返回当前 UTC 时间
// 定义一个本地时间 2000/1/1 8:00:00 new DateTime(2000, 1, 1, 8, 0, 0) // 定义一个 UTC 时间 2000/1/1 0:00:00 DateTime.SpecifyKind(new DateTime(2000, 1, 1), DateTimeKind.Utc) // 将 UTC 时间转化为本地时间 (UTC Time).ToLocalTime() // 将本地时间转化为 UTC 时间 (Local Time).ToUniversalTime()
再次说明，本地时间和 UTC 时间都是 DateTime 对象，关键看定义的时候是 Local 还是 Utc
// 本地时间 1970/1/1 8:00:00 的时间戳 (new DateTime(1970, 1, 1, 8, 0, 0) - DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime()).TotalSeconds // 返回：0 // 本地时间 2000/1/1 8:00:00 的时间戳 (new DateTime(2000, 1, 1, 8, 0, 0) - DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime()).TotalSeconds // 返回：946684800 // 本地时间 当前 的时间戳 (DateTime.Now - DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime()).TotalSeconds // 将时间戳 946684800 转换为本地时间 DateTime.SpecifyKind(new DateTime(1970, 1, 1), DateTimeKind.Utc).ToLocalTime().AddSeconds(946684800)
实战：
如果我们要将时间戳精确到毫秒，那么 JS 直接 .getTime() 即可，不需要 / 1000，C# 将它转换为本地时间时用 AddMilliseconds 代替 AddSeconds。
中国跨越了多个时区却统一使用北京时间，所以国内网站只要记录本地时间即可；如果做国际站或者有不同国家的访客，除非全部由服务器端获取时间，否则客户端 JS 的本地时间（非时间戳）都需要转换成 UTC 时间来跟服务端的时间进行运算和保存，推荐使用时间戳在客户端和服务端之间传递，因为时间戳与时区无关，它是两个相同性质的时间（同为本地时间或同为 UTC 时间）的差值。