UEditor 的 ASP 版本在虚拟空间上传文件失败，提示“上传错误”或“上传失败，请重试”等，是因为其文件上传组件在创建目录时，没有网站目录外的访问权限。
例如上传文件的磁盘保存路径为：
D:\web\sitename\wwwroot\upload\20180523\123.jpg
百度编辑器的上传组件会依次判断以下目录是否存在，不存在则创建：
D:\
D:\web\
D:\web\sitename\
D:\web\sitename\wwwroot\
D:\web\sitename\wwwroot\upload\
D:\web\sitename\wwwroot\upload\20180523\
虚拟空间自动配置的网站根目录可能是：
D:\web\sitename\wwwroot\
所以，判断存在或创建以下目录没有问题：
D:\web\sitename\wwwroot\upload\
D:\web\sitename\wwwroot\upload\20180523\
但判断存在以下目录时会因为权限不足而失败：
D:\
D:\web\
D:\web\sitename\
解决方法是找到文件 asp/Uploader.Class.asp
找到 CheckOrCreatePath 这个 Function，替换为：
Private Function CheckOrCreatePath( ByVal path )
Set fs = Server.CreateObject("Scripting.FileSystemObject")
Dim parts
Dim root : root = Server.mappath("/") & "\"
parts = Split( Replace(path, root, ""), "\" )
path = root
For Each part in parts
path = path + part + "\"
If fs.FolderExists( path ) = False Then
fs.CreateFolder( path )
End If
Next
End Function另外，如果服务端无法通过 Request.Form 来接收该值，把 <form /> 放到 <table /> 外面试试。
或者绑定 contentChange 事件来赋值（不推荐）：
ue.addListener("contentChange", function() {
document.getElementsByName('xxxxxx')[0].value = ue.getContent();
});此方法的缺点是，不是所有操作都能触发 contentChange 事件，比如剪切、上传图片等。
改进方法（推荐）：在 form 提交之前赋值。
WGS-84（地球坐标）
用于 GPS 模块 及 Google Earth
CGCS 2000（国家大地坐标系）
用于天地图，与 WGS-84 最大差异 0.11mm
GCJ-02（火星坐标、国测局坐标系）
用于 Google Map、必应-中国地图、高德、腾讯、图灵、阿里地图，是对地理位置的一次加密
BD-09（百度坐标）
仅用于百度地图，是对火星坐标的再次加密
在线转换工具：https://xoyozo.net/Tools/GeoConverter
坐标转换：https://github.com/wandergis/coordtransform
微信网页开发的获取地理位置接口（wx.getLocation）默认使用 wgs84，可选 gcj02。
微信网页开发的使用微信内置地图查看位置接口（wx.openLocation）支持 gcj02。
一: 执行sql语句,返回受影响的行数
在mysql里面,如果没有影响,那么返回行数为 -1 ,sqlserver 里面 还没有测试过
(var ctx = MyDbContext())
{
ctx.Database.ExecuteSqlCommand("");
}二 : Database.SqlQuery<T> EF5执行sql查询语句 Database.SqlQuery 带返回值
这个准确的说是 IEnumerable<T> SqlQuery<T>(string sql, params object[] parameters) ,注意返回值是 IEnumerable
这个是执行sql语句,返回你想要的类型的列表
dbMain.Database.SqlQuery<int>("select max(UserId) from tb_user_account").First();
或者假如你自己有个类别
PersonView
{ PersonID { ; ; } Name { ; ; }
}
那么就可以直接返回这个 PersonView类
(var ctx = MyDbContext())
{
var peopleViews = ctx.SqlQuery<PersonView>("").ToList();
}直接返回你想要的数据. 例如这里是 List<PersonView> 列表
“/”应用程序中的服务器错误。
无法为具有固定名称“MySql.Data.MySqlClient”的 ADO.NET 提供程序加载在应用程序配置文件中注册的实体框架提供程序类型“MySql.Data.MySqlClient.MySqlProviderServices, MySql.Data.Entity.EF6, Version=6.10.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d”。请确保使用限定程序集的名称且该程序集对运行的应用程序可用。有关详细信息，请参阅 http://go.microsoft.com/fwlink/?LinkId=260882。
打开 nuget，卸载并重新安装 MySql.Data 和 MySql.Data.Entity
如果没有效果，打开 web.config，检查是否多次定义了 MySql.Data.MySqlClient
“/”应用程序中的服务器错误。
未能加载文件或程序集“MySql.Data.Entity.EF6, Version=6.10.7.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d”或它的某一个依赖项。找到的程序集清单定义与程序集引用不匹配。 (异常来自 HRESULT:0x80131040)
6.10.7 版本的 MySql.Data.Entity.EF6.dll 文件发布后会自动变成 6.10.6，文件大小一样，只要用 FTP 上传覆盖一下即可。
“/”应用程序中的服务器错误。
The host xxx does not support SSL connections.
说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。
异常详细信息: MySql.Data.MySqlClient.MySqlException: The host xxx does not support SSL connections.
在 Web.config 的 connectionStrings 节点找到相关数据库连接，在 connectionString 中增加属性值：SslMode=none
如果 .NET Core 项目发布到服务器上报以下错误：
HTTP Error 502.5 - Process Failure
Common causes of this issue:
The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port
Troubleshooting steps:
Check the system event log for error messages
Enable logging the application process' stdout messages
Attach a debugger to the application process and inspect
For more information visit: https://go.microsoft.com/fwlink/?LinkID=808681
在服务器上安装最新的 .NET Core Runtime 即可（Windows Server 选择 Hosting Bundle Installer）。
本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)
本文基于 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）。
索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。
本文系个人实践总结，欢迎批评指正！
删除主题时，会变更主题表 pre_forum_thread：
displayorder = -1
moderated = 1
帖子表（或分表） pre_forum_post* 该主题的所有帖子的
invisible = -1
同时 pre_forum_threadmod 会新增一条 DEL 记录，用于显示到 Discuz! 控制面板 - 内容 - 主题回收站。
删除回帖时，会变更回帖表 pre_forum_post（或分表）：
invisible = -5
屏蔽回复时，会变更回复表 pre_forum_post（或分表）：
status = 1
短信通判断了 30 天内提交错误验证码超过 5 次会有该提示，代码：