ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式：
内存缓存：https://xoyozo.net/Blog/Details/aspnetcore-memory-cache
SQL Server 缓存：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache
Redis 缓存：https://xoyozo.net/Blog/Details/aspnetcore-redis-cache
MySQL 缓存：https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache
Nuget 安装：Pomelo.Extensions.Caching.MySql
Nuget 安装：Pomelo.Extensions.Caching.MySqlConfig.Tools（用于在 MySql 数据库中创建表和索引以进行分布式缓存的命令行工具(dotnet-mysql-cache)）
2019.11 MySqlConfig.Tools 最新版本（2.0.2）不支持 .NetCore 3.0，暂时可手动创建表和索引。
2021.11 MySqlConfig.Tools 最新版（2.1.0）不支持 .Net 6.0。
未完待续，后续步骤类似于：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache
services.AddDistributedMySqlCache()
确保磁盘未满，否则会提示各种无法连接。
在“小米WiFi”App 中开启对应路由器的“SAMBA 协议”（工具箱 - 更多工具 - SAMBA）。
在“小米WiFi”App 中开启相应电脑或设备的“全盘访问”。
通过 miwifi.com 下载安装 PC 客户端。
打开“此电脑”，“映射网络驱动器”或“添加一个网络位置”，填写路由器的地址和目录，如：“\\192.168.31.1\下载”。
如果上一步无法成功添加，那么首先需要检查 samba 服务器是否正常，可以在 iPhone 上安装“Remote File Manager”来验证。
如果 iPhone 连接正常，那么在电脑上打开“本地组策略编辑器”（命令行：gpedit.msc），在“计算机配置 - 管理模板 - 网络 - Lanman 工作站”右侧，双击“启用不安全的来宾登录”，改为“已启用”。Win7 用户参考此文。
注意：电脑必须运行 PC 客户端才能访问小米路由器硬盘。
ASP.NET Web API 返回 Unauthorized 401 未授权代码：
return Unauthorized(new AuthenticationHeaderValue("getUserInfo"));响应的头部信息是这样的：
以微信小程序中获取 header 的 www-authenticate 为例，不同操作系统中获取的 key 是不一样的：
iOS：
Android：
微信开发者工具：
所以，小程序端获取该值，暂时使用以下代码吧：
let www_authenticate;
if (!www_authenticate) {
www_authenticate = res.header['Www-Authenticate']; // iOS
}
if (!www_authenticate) {
www_authenticate = res.header['WWW-Authenticate']; // Android / 微信开发者工具
}
if (!www_authenticate) {
www_authenticate = res.header['www-authenticate']; // ASP.NET Web API 原始输出
}
if (!www_authenticate) {
www_authenticate = res.header['WWW-AUTHENTICATE']; // 其它情况
}这是一篇可能解决困扰了 .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。
整理成表格：
| 1 | 允许更新预编译站点 aspnet_compiler.exe -v / -p \Source -u \TempBuildDir 重复发布后 bin 目录文件数：不会增多（页面不进行预编译） |
| 2 | 不允许更新预编译站点，不合并 aspnet_compiler.exe -v / -p \Source \TempBuildDir 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
| 3 | 不允许更新预编译站点，不合并。为每个页面和控件创建单独的程序集 aspnet_compiler.exe -v / -p \Source -c -fixednames \TempBuildDir 重复发布后 bin 目录文件数：不会增多（编译后的文件名固定，FTP 方式的部分 App_Web_*.dll 文件可能实现增量上传） |
| 4 | 不允许更新预编译站点，将所有输出合并到单个程序集，不勾选“视为库组件” aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：不会增多（.compiled 固定名称，App_Web_*.dll 合并为一个） |
| 5 | 不允许更新预编译站点，将所有输出合并到单个程序集，勾选“视为库组件” aspnet_compiler.exe -v / -p \Source \TempBuildDir aspnet_merge.exe \TempBuildDir -o 程序集名称 -copyattrs AssemblyInfo.dll -a -r 重复发布后 bin 目录文件数：不会增多（.compiled 固定名称，App_Web_*.dll 合并为一个） |
| 6 | 不允许更新预编译站点，将每个文件夹输出合并到其自己的程序集，前缀 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -prefix 前缀 -copyattrs AssemblyInfo.dll -a 重复发布后 bin 目录文件数：.compiled 不会增多，App_Web_*.dll 增多 |
| 7 | 不允许更新预编译站点，将所有页和控件输出合并到单个程序集 aspnet_compiler.exe -v / -p \Source -c \TempBuildDir aspnet_merge.exe \TempBuildDir -w 程序集名称 -copyattrs AssemblyInfo.dll -a 重复发布后 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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
CloudFS 是一款将阿里云 OSS 对象存储挂载为 Linux 本地目录的工具软件，目前已经从阿里云市场下架了。
在云监控中查看到进程 cloudfs 占用大部分内存，可以打开文件 /usr/local/cloudfs/conf/cloudfs.conf 进行配置。
默认值：
BLOCK_SIZE=1048576
MAX_CACHE_LIMITS=10485760
根据实际情况进行修改，然后重启 cloudfs，相关命令：
启动：service cloudfs start
停止：service cloudfs stop
重启：service cloudfs restart
查看状态：service cloudfs status
在学习和使用 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 操作）：
| 方法 | 功能 | ASP.NET Web API 接口返回类型（一般的） |
|---|---|---|
| GET | 取一个或多个资源 | T 或 IEnumerable<T> |
| POST | 增加一个资源 | T |
| PUT | 修改一个资源 | T |
| DELETE | 删除一个资源 | void |
| PATCH | 更新一个资源（资源的部分属性） | |
| HEAD | 获取报头 | |
| OPTIONS | 查询服务器性能或资源相关选项和需求 |
>>> 过滤信息：
如分页、搜索等
>>> 常用状态码：
| 200 | OK | 指示请求已成功 |
| 201 | Created | 资源创建成功（常见用例是一个 PUT 请求的结果） |
| 202 | Accepted | 该请求已被接收但尚未起作用。它是非承诺的，这意味着HTTP中没有办法稍后发送指示处理请求结果的异步响应。 |
| 204 | No Content | 成功 PUT（修改）或 DELETE（删除）一个资源后返回空内容（ASP.NET Web API 中将接口返回类型设置为 void 即可） |
| 400 | Bad Request | 服务器无法理解请求（如必填项未填、内容超长、分页大小超限等），幂等 |
| 401 | Unauthorized | 未授权（如用户未登录时执行了须要登录才能执行的操作），通俗地讲，是服务器告诉你，“你没有通过身份验证 - 根本没有进行身份验证或验证不正确 - 但请重新进行身份验证并再试一次。”这是暂时的，服务器要求你在获得授权后再试一次。 |
| 403 | Forbidden | 服务器理解请求但拒绝授权（是永久禁止的并且与应用程序逻辑相关联（如不正确的密码、尝试删除其它用户发表的文章）、IP 被禁止等），通俗地讲，是服务器告诉你，“我很抱歉。我知道你是谁 - 我相信你说你是谁 - 但你只是没有权限访问此资源。” |
| 404 | Not Found | 找不到请求的资源（指资源不存在，如果找到但无权访问则应返回 403） |
| 405 | Method Not Allowed | 请求方法被禁用（HTTP 动词） |
| 500 | Internal Server Error | 服务器遇到阻止它履行请求的意外情况（如数据库连接失败） |
| 503 | Service Unavailable | 服务器尚未准备好处理请求（常见原因是服务器因维护或重载而停机，这是临时的，可用于在单线程处理事务时遇到被锁定时的响应，如抽奖活动、抢楼活动，防止因并发导致逻辑错误） |
>> 错误处理：
C# 例：throw new HttpResponseException(HttpStatusCode.NotFound);
PHP 例：throw new Exception('文章不存在', 404);
>>> 返回结果：
JSON/XML
不要返回密码等机密字段
>>> 其它：
身份验证窗口（浏览器弹窗，类似 alert，非页面表单），明文传输，安全性不高，不建议使用。实现：
在 Headers 中添加 Authorization:Basic “用户名:密码”的 Base64 编码
请求被中止: 未能创建 SSL/TLS 安全通道。
The request was aborted: Could not create SSL/TLS secure channel.
或
基础连接已经关闭: 发送时发生错误。
出现这个异常原因是请求的 SSL/TLS 版本与对方支持的不一致。
加上这段代码可解决：
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;Tls12 表示请求的安全协议是 TLS 1.2，您可以断点查看原来的 ServicePointManager.SecurityProtocol 值，只要设置为对方网站支持的版本即可。
使用下面这个工具可以查看对方网站提供的 SSL/TLS 版本：
Dark Mode 亦称为 暗黑模式、黑暗模式、暗色模式、黑夜模式、深夜模式、夜间模式 等，以下介绍几种常用软件的 Dark Mode 的设置方法。
iOS：
【iOS 13+】在 设置 - 显示与亮度 - 选择“深色”
【iOS 11+】在 设置 - 通用 - 辅助功能 - 显示调节 - 反转颜色 中开启“智能反转”。
“智能反转”缺点：第三方应用上显示的图片会以“经典反转”的方式展示。
Android：
设置 - 显示 - 主题模式，选择“暗色主题”
版本支持：Android 9.0 - Pie（Android P）
macOS：
系统偏好设置 - 通用 - 外观，低版本系统中勾选“使用暗色菜单栏和 Dock”，高版本系统中直接点击预览图选择主题。
版本支持：在 OS X Yosemite 10.10 中提供支持，在 macOS Mojave 10.14 中全新升级。
Windows：
桌面右键“个性化”（或从 Windows 设置中打开），在“颜色”选项卡，选择默认应用模式“暗”。
版本支持：Windows 10 October 2018 Update（版本 1809）
Microsoft Office：
文件 - 选项 - 常规 - Office 主题：黑色
在一个组件中设置后（如 Word），会在其它的组件中同时生效（如 Excel）。但 Visio 没有“黑色”主题（至少在 2019 中），我尝试更改为“深灰色”，Word 也变为“深灰色”，然后在未关闭 Visio 的情况下再次更改 Word 为“黑色”，Visio 界面竟然也变成了“黑色”，设置选项中为空白。
版本支持：Office 2016
Adobe Photoshop：
点开 菜单：编辑 - 首选项 - 界面，根据自已喜爱更改颜色方案。
版本支持：Photoshop CS6（可能更早），新版中已默认启用
CorelDRAW：
点开菜单：工具 - 选项，左侧展开 工作区 - 外观，主题选择“暗”或“黑体”。
版本支持：CorelDRAW X8（可能更早）
Microsoft Visual Studio：
点开菜单：工具 - 选项 即可更改颜色主题为“深色”（左侧选项卡为 环境-常规）。
版本支持：Visual Studio 2012
微信开发者工具：
点开菜单：设置 - 外观设置，选择“深色主题”
仅在文件代码面板有效
Microsoft Edge：
设置 - 自定义 - 选择一个模式 - 暗
Chrome：
在 Chrome 74 版本中支持。
其开发者工具（F12）早在 50 版本中已提供 Dark 主题，在开发者工具右上角展开竖状三点图标 - Settings - Theme: Dark
Windows 的 Chrome 的 Dark 模式无需设置，会根据 Windows 自身是否为暗模式来调整。
因其 Dark 模式不容易区分当前标签页，如需禁用 Dark 模式，参此文
Adobe Acrobat Reader DC：
点开菜单：视图 - 显示主题 - 深灰
HBuilder X：
点开菜单：工具 - 主题 - 酷黑
Code Write：
设置 - Editor - Theme - Dark（默认已启用）