微信支付商户平台注册时填写的企业法人为超级管理员，此处对比的是在“员工账号管理”中添加的“管理员”身份的账号，并且“配置权限”中勾选了所有权限。
| 超级管理员 | 员工管理员 | |
| 接收在“下载证书”、“设置操作密码”等操作中下发的短信验证码 | ✔ | ❌ |
| 开发配置（配置支付授权目录、配置扫码回调链接） | ✔ | ❌ |
| AppID 授权管理 | ✔ | ❌ |
| 随时补充 |
微信支付商户可以直接注册，也可以由公众号、小程序、开放平台等开通。
直接注册时可勾选使用的公众号、小程序、APP、PC 网站等，并填写相应的 APPID。
填写资料提交审核，等待 1~2 工作日。
审核通过后签约，选择“手动提现”或“自动提现”，建议“手动提现”，原因如下：
用户付款、退款、企业付款等流程
以乐趣到家为例，
用户 A 提交搬家需要，并支付 100 元搬家费（其中的 10 元是平台抽成，90 元是服务者 B 的收入）。
那么 A 付款成功后，100 元打入商户的“未结算”中，在结算周期后扣除手续费变成“已结算”（若手续费 0.6% 则变成 99.4 元），如果商户开通了自动提现，则直接打入对公账户。
当 A 申请退款时，如果“未结算”资金充足，那么从“未结算”资金中退款给 A，如果不足，则从“可用余额”中退款（从商户角度来说应该是“企业付款”）。
若服务正常完成，则从可用余额中付款 90 元给 B。
可用余额（简称余额）是专用于支付的资金，其资金来源可以是充值或从“已结算”资金转入（前提是未开通自动提现）。
如果开通了“企业付款”，那么相关资金也是从余额中扣除的。
所以，退款（用户角度的“退款”）直接从“未结算”中扣是最划算的，只当“未结算”中资金不足时采用余额退款（用户角度的“退款”，商户角度的“企业付款”）。
由于退款（商户角度的“退款”）的前提是有相应的订单，所以上例中的 90 元支付给 B 时不能使用商户的退款功能，只能从余额支付（企业付款），而从“已结算”转到“余额”是最划算的，如从“已结算”到“对公账户”再充值到“余额”就会涉及开票缴税。
下面是如何关闭和再次开通“自动提现”。（注意：并非所有的商户都有此功能！据我所知，结算周期为 T+1 的有关闭功能，T+7 的不能关闭）
以上系本人经验总结，仅供交流，不承担任何责任，如有错误敬请指正。QQ 940534113
本文讲述使用网页开发适用于宴会、活动、年会现场 LED 大屏幕显示抽奖、抢楼、游戏、视频等互动界面，通过在浏览器中打开后 F11 全屏投影到大银幕上。
设计思路：
为了保证最佳的显示效果，设计稿的尺寸按大屏幕的“宽高比”来做（本文以4米*3米的大银幕为例，设计稿以800*600像素为例）。
由于电脑的视频输出分辨率很有可能与大银幕的宽高比不同，那么我们全屏投影后会界面会有变形，但是投影设备接收到电脑视频信号后再全屏显示到大银幕时，界面又会变回正常。
按设计稿的尺寸开发网页，并使用 CSS3 的 scale 实现整体伸缩，目的是自适应窗口尺寸来全屏显示内容，无留白、无裁切。整体拉伸的要求是文字、图片、背景、间距、iframe 等所有元素以统一的比例拉伸，无错位。
网页上通过 JS 设置一些快捷键来实现页面展示内容的切换。
若投影设备功能有限或操作员水平有限等原因导致无法顺利设置输入输出分辨率时，网页可设置 x 轴和 y 轴两个方向的伸缩系数、定位偏移量等，更灵活地实现完美投影需求。
开发要点：
网页尺寸按设计稿来定（以 800x600 为例）。
使用 CSS3 的 transform 的 scale 来实现缩放，以电脑显示器分辨率 1920x1080，宽放大 1920/800 倍，高放大 1080/600 倍，即可将设计稿全屏展示到电脑显示器上。为了更灵活，我们使用窗口大小来代替显示器分辨率，这样不管怎么改变窗口大小或者全屏，设计稿都能完整地显示在窗口上。
在页面初始化和窗口尺寸变化时重新调整设置上述比例。
代码参考：
今天发现，阿里云 CDN 的 Refer 防盗链并没有真正防止白名单外的域名调用 OSS 的图片。经过一番研究发现，这跟 https 有关。
我在阿里云开通了 OSS 来存在图片，并使用 CDN 访问，在 CDN 中开启了 https，但并不强制。并且使用“白名单”的方式来设置 Refer 防盗链。关键是开启了“允许空 Referer”。
我在 http://b.com/ 上测试调用 http 和 https 的图片都是打不开的（防盗链有效），但是在 https://b.com/ 上却能显示 http 的图片（防盗链失效）：
究其原因，是 https 页面在调用 http 图片时请求头不包含 Referer 字段，导致 CDN 判断 Referer 为空，这时候如果开启了为空也允许访问的话，就会出现防盗链失效的情况了。
总结：如果 CDN 开启了 https 访问，那么不要允许空 Referer。这里白名单内的网站必须使用与 CDN 一致的 protocol（http 或 https）。建议的写法是：
<img src="//cdn.xxx.com/abc.jpg" />数据表所占用的空间（简称“表空间”）一般会大于其数据空间和索引空间的和。
当数据被删除时，其所占空间并不会立即释放，而是等待新数据写入，这会导致出现许多磁盘碎片。使用 OPTIMIZE TABLE 或 ALTER TABLE 可以回收碎片，重组文件。优化表的过程类似于 Windows 碎片整理。
操作过程会导致该表上的写操作无法执行。
一般在删除了大批量数据或更改了许多可变长度字段后执行优化表。
碎片率 = 100% - (数据空间 + 索引空间) / 表空间
优化后碎片率接近于 0%，数据空间和索引空间也会变小，此时 表空间 接近于“数据空间 + 索引空间”
在 MyISAM 引擎上遇到优化后导致获取行数为 0，SELECT 数据只有 1 条的情况，需要执行修复表（REPAIR TABLE），使数据恢复正常。执行后结果显示：Number of rows changed from 0 to xxxxxx
使用会话状态服务器（StateServer）管理会话状态，可防止网站发布后会话丢失，参 ASP.NET 网站每次发布后丢失 Session 怎么办？
查询数据库时，尽量使用 using 包裹 db 上下文，或者 db.Dispose()，或重写 Dispose()，可以减少数据库连接数（Sleep），参 如何减少 ASP.NET 连接 MySQL 时的 Sleep 查询（即时关闭数据库上下文）
发布时使用预编译功能，参 彻底告别 .NET 网站首次访问速度慢的问题
清理日志不要这样写（先读取再删除）：
db.dt_log.RemoveRange(db.dt_log.Where(c => c.time < dt).OrderBy(c => c.time).Take(count));SQL Server 应该：
db.Database.ExecuteSqlCommand($"DELETE FROM {nameof(db.dt_log)} WHERE {nameof(l.id)} IN (SELECT TOP {count} {nameof(l.id)} FROM {nameof(db.dt_log)} WHERE {nameof(l.time)} < '{dt.ToString("yyyy-MM-dd HH:mm:ss")}' ORDER BY {nameof(l.time)})");注意时间可能需要使用 convert 函数转化，给 time 字段添加索引。
MySQL 应该：
db.Database.ExecuteSqlCommand($"DELETE FROM {nameof(db.dt_log)} WHERE {nameof(l.time)} < '{dt.ToString("yyyy-MM-dd HH:mm:ss")}' ORDER BY {nameof(l.time)} LIMIT {count}");给 time 字段添加索引。
未完待续
于 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
重启系统。
Visual Studio 2019 已于本月早些时候正式发布，但 MySQL for Visual Studio 却迟迟未更新，目前的 1.2.8 版本只支持到 VS2017。表现在 VS2019 上会发生：
在“服务器资源管理器”中添加连接时，或在新建“ADO.NET 实体数据模型”时，无法看到数据源“MySQL Database (MySQL Data Provider)”
在实体数据模型设计器（Entity Data Model Designer）中执行“从数据库更新数据模型”时出现错误：尝试从数据库进行更新时，遇到类型为“System.ArgumentException”的异常。异常消息为:“无法将运行时连接字符串转换为设计时等效项。没有为提供程序“MySql.Data.MySqlClient”安装为设计目的(DDEX 提供程序)启用 Visual Studio 以便与数据库进行通信所需的库。
幸运的是 VS2019 可以与低版本 VS 共存，使用 ASP.NET 连接 MySQL 的开发者们要再等一等才能用上 VS2019 了。
这几天 MySQL 不断有产品更新，相信 MySQL for Visual Studio 2019 也会在不久的将来面世，本站将第一时间更新下载地址。
2019.8.30 Jose Ramirez（来自 MySQL 的 Windows 团队）：MySQL for Visual Studio 的当前版本不支持 Visual Studio 2019。正在努力提供支持，但根据公司政策，我无法披露日期或对何时可用提供任何承诺。查看
2019.9.26 MySQL for Visual Studio 迟迟未更新，但是 VS2019 更新到最新版本（v16.3）已经一切正常了。
MySQL for Visual Studio 的 Repair 功能是鸡肋，有问题的话，Remove 后重新安装才能解决。
这是一篇可能解决困扰了 .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 方式发布。