附加消息：暂无该开发者或未上传过应用
原因： 没有上架应用（隐藏的不算上架），应用设置显示后记得在版本管理中将版本也设为显示。
附加消息：抱歉，开发者验证无效
原因：可能是没有达到认证要求，不允许加群（譬如：需应用最低总安装量 1000 次）
DZ 水很深，慎入：http://open.discuz.net/?ac=document&page=xootan
2018.8.14 踩坑：
还有，加群要开发者中填写的 QQ 才能加，因为验证是全自动程序判断的。
如果要跳过安装量 1000 次的要求，就直接花钱购买会员，不过购买会员也是一件非常艰难的事情，在与“Q群管家”这个机器人 QQ 的对话中发送“@购买vip”，绝对能让你体验到一种有钱也花不出去的感受。
做这么多花哨的东西，不如踏踏实实把产品做好。
2018.8.15 踩坑：
跟Q群管家对话，@login 时，由于密码过于复杂，消息没反应，特殊符号别提了，连纯大小写字母数字也不行，后改成纯数字密码登录成功。
加群完全看基本信息中填写的 QQ 客服 号，群主是机器人，只要应用是上架显示的，版本是显示的，就可以用这个QQ客服申请入群，（可以改）。
最近，空心图标和实心图标的讨论变得激烈起来，有言论指出空心图标在视觉上比实心图标看起来更复杂，更容易让用户差生疲劳感和倦怠感。对此，设计师们都各抒己见，一部分人表示赞同这种说法，而另一部分人则表示这样的言论将问题过分了放大化了，并且在证据方面有所欠缺。
图标也可以理解为是网站中的一种指引，是每个新用户都会涉及到的元素，所以无论空心或实心，一个能够令人一目了然，并且记忆深刻的图标才是用户真正喜欢的图标。
以下是小编搜寻的一些空心或实心的图标案例，看看你更倾心于哪一款呢？
1.模糊背景上覆盖着由简单线条、字体和单一的颜色组成的空心图标，这会让整个界面看起来很优雅。不仅如此，这种简易的设计手法也让设计师轻松不少，在效果和操作上都令大家很满意。
2.纯色的背景似乎搭配任何元素都能达到令人意想不到的效果，下面这个案例也不例外。正红色与白色之间的经典配搭，加以可爱的造型，成就了一个俏皮的实心图标设计。界面底部的实心按钮与幽灵按钮也与图标区域前后呼应。
3.APP底部的图标随着用户的任意切换，在空心和实心之间自由转变。实心的图标相比较空心的而言，给人一种更突出和明显的视觉效果，让用户更容易的抓到重点。而主内容左边的卡通小图案同时采用了空心的设置，尽显极简主义。
4.Line的界面似乎代表了大多数APP的图标设计方式。头部和底部的图标选用两种颜色的实心设计，下拉菜单部分使用空心图标。这样的设计虽然比较大众化，但不可否认的是，这样的做法的确让整个界面看起来格外整洁。
5.幽灵按钮虽然简洁大方，但是过多的使用会另界面很单调无味，但如果使用全部实心的图标设计又会觉得很突兀。下面这个案例就想出了一个好方法。既然空心实心都不合适，那不如尝试一下让两者结合在一起吧。
6.两种色差明显的颜色搭配在一起会体现出一种自然而然的时尚感，黑色背景和亮黄色的图标元素就是很典型的例子。强烈的对比色会让空心图标看起来也像实心图标一样，具有突出重点的效果。
7.Metro风格的界面设计也能运用在APP的图标模块中，案例中将各种第三方分享平台的实心图标都用方块元素连接在一起，让原本单调的图标瞬间活跃了起来，给用户一种焕然一新的感觉。
8.传统的导航图标大多会集中在一个区域内，而SevenEleven的APP在此做了很大的突破，将4个部分分别分布在界面的上下左右，简单的界面突然有了运动场的氛围，让APP充满了生命力。
9.天气类应用的看点中总会有气候图标的一席之地，正如这个案例中所表现的，这又是一个空心与实心相结合的图标设计。
10.这也是一个纯色块与实心图标搭配的案例，这个APP的界面设计其实很普通，但正因为图标的设计让网站变得可爱起来。
图标在网页设计中算是一个小单元，但它的重要性大家都有目共睹。空心图标和实心图标在不同的环境中发挥着不同的作用，美化着网页中的小细节。
“/”应用程序中的服务器错误。
无法为具有固定名称“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
本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)
本文基于 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）。
索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。
本文系个人实践总结，欢迎批评指正！
ASP.NET MVC 项目发布到 IIS 上，出现服务器错误“403 - 禁止访问：访问被拒绝”，排除权限设置问题后，原因在于 MVC 的 URL 通常没有扩展名，IIS 并未将其交由 ASP.NET 托管处理。
经过各种找资料，各种尝试后，最终确定：项目本身没有问题，本地运行正常，发布到另一台服务器上正常。
删除服务器 IIS 上的该网站和应用程序池，重新创建网站，恢复正常。原因未知。
在 Global.asax 的 Application_Start() 方法中添加以下代码，作用是在应用程序启动时预先访问一遍所有动态页面，办法虽土，但很有效。
本代码适合 Web Forms 项目，不适合 MVC 项目；修改代码中的 domain 值为真实的网站域名
代码整理中……
在 IIS 中设置应用程序池最长时效或永不过期，则效果更佳。
在应用程序池中选中网站对应的应用程序池，在右侧“操作”窗口中选择“正在回收...”
取消“固定间隔”框中的所有选项，确定。
实践证明，近 200 个动态页面一次性访问需要耗时近 10 分钟，发布后 10 分钟内无法正常浏览网站是同样是无法忍受的。因此更改方案为：
做一个 Winform 应用程序来定时访问这些页面，30 秒一个，一个半小时能完成一个循环，对正常浏览的影响非常小。
| 发布选项 \ 项目类型 | Web 窗体网站 | Web 应用程序 （Web 窗体） | Web 应用程序 （MVC） | ASP.NET Core Web 应用程序 |
在发布期间预编译 Precompile during publishing | 若勾选，将 .cs 文件编译为 .dll | 无论是否勾选，都将 .cs 文件编译为 .dll | ||
允许更新预编译站点 Allow precompiled site to be updatable | 若不允许，则会将 .aspx 等页面也一同编译，并以内容“这是预编译工具生成的标记文件，不应删除!”代替 | |||
未进行完整的测试和分析，总结有误请指正。