微信支付商户平台注册时填写的企业法人为超级管理员，此处对比的是在“员工账号管理”中添加的“管理员”身份的账号，并且“配置权限”中勾选了所有权限。
| 超级管理员 | 员工管理员 | |
| 接收在“下载证书”、“设置操作密码”等操作中下发的短信验证码 | ✔ | ❌ |
| 开发配置（配置支付授权目录、配置扫码回调链接） | ✔ | ❌ |
| AppID 授权管理 | ✔ | ❌ |
| 随时补充 |
于 2024 年 8 月：
查看空间占用
主菜单“云数据库 RDS” - 选择相应实例 - 自治服务 - 一键诊断 - 空间分析 - 立即分析 - 几分钟后就能看到报表（经济版 / 企业版可以开启自动分析）
如果没有可清理的空间，可以直接扩容（有条件）：实例 - 基本信息 - 变更配置 - 立即升配
慢查询（索引优化建议）
主菜单“云数据库 RDS” - 选择相应实例 - 自治服务 - 慢SQL
2019 年 5 月前：
查看空间占用
主菜单“云数据库 RDS 版” - 选择相应实例 - 二级菜单“CloudDBA” - 空间管理
主菜单“混合云数据库管理 HDM” - 选择相应实例 - 二级菜单“库表空间” - 数据空间
注意“数据空间”只是数据的大小，跟磁盘占用有直接关系的是“表空间”，某些表（如日志表）记录频繁插入删除的，表空间会比较大，应执行“优化表（OPTIMIZE TABLE）”，优化过程中会影响表的写操作
慢查询（索引优化建议）
主菜单“云数据库 RDS 版” - 选择相应实例 - 二级菜单“CloudDBA” - 性能优化
主菜单“混合云数据库管理 HDM” - 选择相应实例 - 二级菜单“请求分析” - 慢日志
无法向会话状态服务器发出会话状态请求。请确保 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
重启系统。
场景：每天带笔记本电脑上班，公司使用固定 IP 上网，家里网络的网段又跟公司不一样。
方法 1：两个网络环境分别使用有线连接和无线连接（鉴于笔记本无线网卡不支持 5G（802.11ac），或者有其它需求必须都使用有线连接的不适用此方法）。
方法 2：修改家里路由器的局域网 IP 地址，使其网段与公司相同（虽然仅需要一次修改，但部分路由器不允许修改局域网 IP 地址）；
方法 3：使用第三方软件一键切换（有安全隐患，且可能导致电脑网络设置出现错误）；
方法 4（推荐）：设置电脑网络连接同时使用两个 IP，具体方法如下：
打开“以太网 属性”，双击“Internet 协议版本 4 (TCP/IPv4)”，配置其中一个网络环境的 IP 地址和网关（例如我在公司上网的 IP 是 192.168.1.5，网关是 192.168.1.1）
点击“高级”，在 IP 地址栏添加另一个网络的 IP（如 192.168.31.5），在“默认网关”处添加这个网络的网关（如 192.168.31.1）
这样设置后，不管到公司还是回到家，只要网线一插就能上网，不需要每天更换 IP 地址设置了。
（图中显示了两个网络名称）
这是一篇可能解决困扰了 .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 方式发布。
spacedesk 是一款非常强大的虚拟投影软件，可以将其它电脑、苹果设备（iPhone、iPad）、安卓手机甚至 HTML5 浏览器作为第二屏幕。本文以一台笔记本的屏幕作为另一台笔记本的扩展记录安装配置过程。
主笔记本安装 spacedesk DRIVER
扩展笔记本安装 spacedesk VIEWER
为了保证屏幕最佳的显示效果，我们希望两台笔记本最终的显示分辨率与物理分辨率一致。
我的主笔记本分辨率 1920x1080，扩展笔记本分辨率 1366x768
主笔记本
首先在扩展笔记本中打开 spacedesk VIEWER，连接主笔记本。
在主笔记本，桌面右键“显示设置”，分别针对 1 和 2 显示器设置分辨率：
当然还可以在上上图中的“重新排列显示器”中拖动来实现屏幕内容的显示位置。
扩展笔记本
打开 spacedesk VIEWER，在菜单的 Settings 中选择 Resolutions 可设置显示分辨率：
选择 Compression Quality 可设置显示质量：
压缩（Compression）如果选择 Off，那得看你的电脑能否吃得消，否则显示效果会更卡。我的配置是压缩选择 On，颜色深度选择低，快速，质量 100，帧率选择 60 FPS：
这样比默认设置的显示效果要好很多。
如果有条件用有线连接的话，尽量不要用无线连接，能减少不少延时。
如果你是刚入手的小米 WiFi 电力猫，那么按说明书一步一步配置即可。这里记录一下移机的重置方法。
本次移机的场景是电力猫从一台小米路由器更换到另一台小米路由器的配置，两台小米路由器 WIFI 的 SSD 不同（假设为 WIFI-A 和 WIFI-B）。
错误做法：打开米家，切换到 WIFI-B 所在的房间，点击右上角的添加新设备，根据介绍插上子猫，并按子猫的配置键 5 秒以上。连上“xiaomi-plc-xxx”，米家显示正在连接，但到达 100% 后显示连接超时。
可能的错误原因：
没有插上主猫
该电子猫已经在米家上添加过了（在 WIFI-A 所在的房间），就无法添加到其它房间了（仅猜测，未实测）
于是，同时插上主猫和子猫，并且路由器和主猫使用网线连接，什么都不设置，过一两分钟，两猫自动会变成蓝灯（表示连接成功）。这时，如果刚才那步没有重置成功的话，打开米家主界面上的“小米电力线wifi扩展器”（如果没有删除过，还在 A 房间），里面会显示网络名称为 WIFI-A，还可能没有开“WIFI漫游”。这样虽然能连接上网，但有两个 SSD，不能实现漫游。
这时，按子猫配置键 5 秒以上，并静等一分钟以上，变回蓝灯后，再打开米家，就会看到网络名称可能是 WIFI-B-Plus，这时"WIFI漫游”也能打开了，完美扩展了 WIFI。
综上实践得出：
WIFI 是由子猫负责的，所以跟 SSD 有关的配置由子猫负责；
一台设备（这里指电子猫套餐）只能添加到米家一次，但可以更改设备所在的房间。
正确的重置电力猫步骤是：
同时插上主猫和子猫
主猫连上路由器
子猫按配置键 5 秒以上，等待一分钟以上
打开米家，进入“小米电力线wifi扩展器”，打开 WIFI 漫游
以上仅在使用小米路由器情况下实测，非小米路由器未尝试。
这是一个数据可视化项目，基于D3.js。能够将历史数据排名转化为动态柱状图图表。
先来看看效果：
https://xoyozo.net/Demo/BarGraph
作者 Jannchie 见齐还提供了官方视频教程：
https://www.bilibili.com/video/av28087807
不过由于开源项目的不断更新，该教程的部分内容已失效，本文针对 2018-12-25 版本总结了一些常用的配置说明，仅供参考。
从 GitHub 下载源代码，在 src 目录中可以看到 4 个文件：
bargraph.html --> 运行示例页面
config.js --> 配置文件
stylesheet.css --> 样式表
visual.js --> 核心文件
作者并没有将代码封装为插件的方式，所以我们是通过修改 config.js 配置文件的方式应用到自己的项目中的。
visual.js 虽然是核心文件，但作者将部分示例中的代码也包含其中，但并不影响我们直接在自己的项目中引用。
以下是 config.js 中的主要属性：
| 属性 | 说明 | 参考值 |
| encoding | 数据源（csv、json）等的文件编码 | GBK / UTF-8 等 |
| max_number | 每个时间节点最多显示的条目数 | 10 |
| showMessage | 控制是否显示顶部附加信息文字 | true / false |
| auto_sort | 时间自动排序（详细含义、作用及限制见代码中注释） | true / false |
| timeFormat | 时间格式，显示于图表右下角的时间 | %Y、%Y-%M-%D 等 |
| reverse | 是否倒序 | true / false |
| divide_by | 类型根据什么字段区分？如果是 name，则关闭类型显示 | |
| divide_color_by | 颜色根据什么字段区分？ 须要注意的是，如果配置成 name，则各条颜色不同（因为 name 值各异），如果配置成 type 等，那么相同 type 值的条颜色相同。 | 字段名 |
| color | 指定部分或所有条的颜色，该项与 divide_color_by 设置有关。 | 以 divide_color_by = 'name' 为例，"中国"是其中的一项 name 值，那么该项将显示 #D62728 色： color: { '中国': '#D62728' } |
| changeable_color | 若 true 则颜色的深浅将根据数据的增长率实时改变 | |
| itemLabel | 左边文字 | |
| typeLabel | 右边文字 | |
| item_x | ||
| interval_time | 时间点间隔时间 | 2 |
| text_y | ||
| text_x | ||
| offset | ||
| display_barInfo | 如果希望不显示，则可以设置较大的值，单位像素 | |
| use_counter | ||
| step | ||
| format | 格式化数值 | |
| left_margin | ||
| right_margin | ||
| top_margin | ||
| bottom_margin | ||
| dateLabel_x | ||
| dateLabel_y | ||
| allow_up | ||
| enter_from_0 | ||
| big_value | ||
| use_semilogarithmic_coordinate | ||
| long | ||
| wait | 数据加载完成后开始播放前的等待时间 | 0 |
| update_rate |
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 作服务端接口时，如果客户端以 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="^\&(.*)" />
</conditions>
<action type="Redirect" url="{R:1}?{C:1}" appendQueryString="false" redirectType="Temporary" />
</rule>
</rules>
</rewrite>我们要把这段代码复制到开发环境源代码的 web.config 中，以免发布网站时将我们设置好的配置覆盖掉。