解析域名、挂载磁盘（若有另购）、修改实例名称、配置安全组、设置快照策略、安装云监控插件并在应用分组添加服务器、云安全中心防勒索安装客户端并配置策略资产
远程连接进入 ECS（若解析未生效可以先用 IP）
开启 Windows 防火墙（使用推荐设置）
Windows 更新
安装 IIS：服务器管理器-添加角色和功能-勾选“Web 服务器(IIS)”包括管理工具
建议勾选：
默认已勾选项
按需安装 IP 和域限制
跟踪（即“失败请求跟踪”）
请求监视器、日志记录工具、
按需安装 ASP
按需安装 ASP.NET 4.8（会同时勾选 .NET Extensibility 4.8、ISAPI 扩展、ISAPI 筛选器）
按需安装 WebSocket 协议
应用程序初始化（建议安装）
管理服务（用于 Web 部署）
细节：设置任务栏；设置桌面图标；个性化-颜色-勾选“标题栏和窗口边框”；设置输入法；
下载 URL 重写（文件名：rewrite_amd64_zh-CN.msi）
下载 MySQL Connector/NET（文件名：mysql-connector-net-8.0.19.msi）
下载 ASP.NET Core 运行时 Hosting Bundle（文件名：dotnet-hosting-*.*.*-win.exe）
下载 .NET 桌面运行时 Windows x64（文件名：windowsdesktop-runtime-*.*.*-win-x64.exe）
下载 Web Deploy（文件名：WebDeploy_amd64_zh-CN.msi）
服务：设置“ASP.NET State Service”自动启动
IIS 日志：路径（如 D:\wwwlogs），每小时（统一设置一个全局的就行了，不需要设置每个网站），按需勾选“使用本地时间进行文件命名和滚动更新”
IIS 导入证书：个人、允许导出证书。参
设置权限：设置网站所在分区（如 D 盘），安全，添加 IIS_IUSRS，全部拒绝（防止跨站）
添加用户：为每个网站创建用户（既能防止跨站，又能跟踪进程），密码不能改、不过期，仅隶属于 IIS_IUSRS，并添加到每个网站的根目录
创建网站：设置访问物理路径的用户；设置应用程序池的“标识”用户；编辑绑定：勾选需要服务器名称指示；检查域名是否绑全；设置写入目录；
重复上面两步
检查所有网站用户是否仅隶属于 IIS_IUSRS（在“组”页面双击 Users 和 IIS_IUSRS 查看成员）
在应用程序池列表页面检查 CLR 版本、管托管道模式和标识；在网站列表页面检查绑定和路径
设置“IP 地址和域限制”
废弃旧服时再次检查：IIS 中各功能设置、hosts、安装的应用程序、启动项、服务、防火墙等
解析各网站域名
其它：资源管理器-查看-选项-查看-去掉“始终显示图标，从不显示缩略图”前的勾
>> 关于域名解析
因各地域名解析生效时间不可控，一般国内域名 1 天内，国际域名 2 天内。
若网站数据库在 RDS、上传文件在 OSS，则解析 48 小时后直接停止原网站即可；（比较理想的）
文件上传到 ECS 的可使用 FTP 等工具定时同步文件，或直接停止原网站。（网友会遇到新文章中图片无法显示等问题）
还有一种方法是新网站提前解析一个备用域名，确保完全生效后再修改正式域名的解析，原网站无条件跳转到备用域名，如果数据库中有保存完整网址路径的，关闭原网站并解绑备用域名之后，进行批量替换。（缺点是可能会影响在搜索引擎的网站权重）
部分有定时器的网站要注意，如果两个网站的定时器都正常开启会导致意外的，需要停止其中一个网站的定时器。
当然每种方法都有优缺点，选择可以接受且方便的一种即可。
更多文章：
Senparc.Weixin.Sample.MP 盛派微信公众平台示例项目在 VS 中运行正常，当发布到 IIS 后出现应用程序池自动停止的情况，在服务器管理器中找到 .NET Runtime 错误，可以看到错误原因：
\App_Data\SenparcTraceLog 目录需要写入权限。
以下目录也需要写入权限：
\App_Data\WeChat_OfficialAccount
\App_Data\NeuChar
按材料
| 铅酸电池 | 成本低、低温性好、性价比高；能量密度低、寿命短、体积大、安全性差。 |
| 镍氢电池 | 成本低、技术成熟、寿命长、耐用；能量密度低、体积大、电压低、有电池记忆效应。含有重金属，遗弃后对环境造成污染。 |
| 锰酸锂电池 | 成本低、安全性和低温性能好的正极材料，但是其材料本身并不太稳定，容易分解产生气体，因此多用于和其它材料混合使用，以降低电芯成本，但其循环寿命衰减较快，容易发生鼓胀，高温性能较差、寿命相对短。 |
| 磷酸铁锂电池 | 是一种使用磷酸铁锂（LiFePO4）作为正极材料，碳作为负极材料的锂离子电池。具有工作电压高、能量密度大、循环寿命长、安全性能好、自放电率小、无记忆效应的优点。电池温度处于500-600℃时，其内部化学成分才开始分解，并且穿刺、短路、高温都不会燃烧或者爆炸，使用寿命也较长。但车辆续航里程一般，当温度低于-5℃时，充电效率低，不适合北方在冬天充电的需求。 |
| 三元锂电池 | 是指正极材料使用镍钴锰酸锂（Li(NiCoMn)O2）或者镍钴铝酸锂的三元正极材料的锂电池。能量密度高、循环寿命长、不惧低温；高温下稳定不足。能量密度可达最高，但高温性相对较差，关于续航里程有要求的纯电动汽车，其是主流方向，且适合北方天气，低温时电池更加稳定。 |
按制造和封装形式
| 1865电池 | 18650是锂离子电池的鼻祖。日本SONY公司当年为了节省成本而定下的一种标准性的锂离子电池型号，其中18表示直径为18mm，65表示长度为65mm，0表示为圆柱形电池。优点：容量大、寿命长、安全性能高、电压高、没有记忆效应、内阻小、可串联或并联组合成18650锂电池组、使用范围广。 |
| 2170电池 | 2017年1月4日，特斯拉官方宣布新一代锂电池“2170”开始量产。直径为21mm、高度70mm。 |
| 4680电池 | 2020年9月特斯拉发布了的新型电池类型，据介绍，相较2170电池，该电池能量方面提高5倍，续航里程提高16%，动力方面提高6倍。2022年初开始量产。 |
| 刀片电池 | 是比亚迪于2020年3月29日发布的电池产品。该电池采用磷酸铁锂技术。“刀片电池”通过结构创新，在成组时可以跳过“模组”，大幅提高了体积利用率，最终达成在同样的空间内装入更多电芯的设计目标。相较传统电池包，“刀片电池”的体积利用率提升了50%以上，也就是说续航里程可提升50%以上，达到了高能量密度三元锂电池的同等水平。 |
| 麒麟电池 | 2022年3月26日，宁德时代首席科学家吴凯在2022年电动汽车百人会论坛上表示：宁德时代通过不断技术迭代，推出了第三代CTP技术，其系统重量、能量密度及体积能量密度继续引领行业最高水平。在相同的化学体系、同等电池包尺寸下，麒麟电池包的电量，相比4680系统可以提升13%。第三代CTP技术，兼顾极速、无损、安全、高效等优势，适用磷酸铁锂、三元电池，涵盖乘用车、商用车领域。 |
前言：
ChatGPT 给了 3 条建议：
在应用程序中正确释放数据库连接。确保在使用完数据库连接后，将其关闭并将其返回到连接池中。您可以使用 using 语句来确保连接在使用完毕后被正确释放。
调整连接池的大小。默认情况下，连接池的最大大小为 100。如果您的应用程序需要更多的连接，则可以增加连接池的大小。您可以在连接字符串中设置 Max Pool Size 属性来调整连接池的大小。
调整连接池的超时时间。默认情况下，连接池中的连接在 30 秒钟内未使用时将被关闭。如果您的应用程序需要更长的连接时间，则可以增加连接池的超时时间。您可以在连接字符串中设置 Connection Lifetime 属性来调整连接池的超时时间。
亲测有效，尤其是第 3 条，原因是 Connection Lifetime 的默认值是 0，即没有超时限制。
—— 2023.5
一般地，我们使用 EF 连接数据库前会先初始化一个数据库上下文：
dbEntities db = new dbEntities();虽然 ASP.NET 会在查询完毕后自动关闭该连接，但是在什么情况下回收等都是不确定的，所以会导致 MySQL 中出现很多 Sleep 的连接（执行命令 SHOW FULL PROCESSLIST 可见），占用数据库的连接数，除非主动调用 Dispose()：
db.Dispose();官方建议的写法是使用 using 语法：
using (dbEntities db = new dbEntities())
{
}using 会自动调用 Dispose()。这样对减少连接数是很有效的，但官方提示为了提高下一次连接的速度，并不会完全关闭所有连接。
C# 8 建议写法：
using dbEntities db = new dbEntities();在实际项目中（该项目有 500+处数据库连接）测试结果，在不执行 Dispose() 时稳定为 140 个左右连接数，使用 using 或 Dispose() 后稳定变为 40 个左右。
如果不小心在 using 外部或 Dispose() 后再次对该上下文执行查询操作会出现异常：
无法完成该操作，因为 DbContext 已释放。
或
此 ObjectContext 实例已释放，不可再用于需要连接的操作。
所以要避免出现这种情况。这里还有一种另类的解决方法（不建议），根据上下文的特性，只要在 using 内查询一次（譬如视图中需要用到的导航属性，即外键关联的表），就可以在外部使用这个属性。
（建议）在 ASP.NET MVC 或 Web API 项目中，如果一个控制器中仅在 Action 外部定义一个 DbContext，那么，只要重写该控制器的 Dispose() 方法即可：
private dbEntities db = new dbEntities();
protected override void Dispose(bool disposing)
{
if (disposing)
{
db.Dispose();
}
base.Dispose(disposing);
}上下文使用 private 修饰即可。
这是一篇可能解决困扰了 .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 方式发布。
Input string is not a valid interger. Path 'batteryLevel', line 1, position 447.
使用 uni-app 开发小程序的时候，获取系统信息（getSystemInfoSync()）在 iPhone X 上报错，原因是电池电量值无法转换为 int 型。出现的情况是偶发性的，但一旦出现，一段时间内会一直出现（可能等电量值更新了才会正常吧）。不知道是 uni-app 的 bug 还是微信小程序的 bug。问了度娘和必应国际，暂时没有找到答案。
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 秒一个，一个半小时能完成一个循环，对正常浏览的影响非常小。
程序设计规范：
【推荐】上传的文件直接保存到文件存储服务（如阿里云 OSS），这样即使被上传了后门 shell，对网站服务器也不会有影响。
否则必须通过文件头来确定文件类型，检查文件十六进制的文件头和文件尾是否合法，并检查文件流中是否包含 php、evel 等字符。
不可直接使用客户端文件名来保存文件，特别是后缀名/扩展名。应生成随机文件名，并通过检验文件头来确定文件类型。必须由程序指定保存目录。
使用 OSS 的应直接上传，不要在 ECS 上临时存放或备份。如必须存放的，应按上述规范操作。
服务器安全设置
CentOS + nginx + PHP：
全站文件取消属性中的“执行”权限（chmod），因为这个“执行”与运行 PHP 无关。而需要上传文件的“目录”需要“执行”权限，原因是需要往该目录创建文件。
仅需要写入的目录或文件设置“写入”权限。如上传图片目录、ThinkPHP 的 Runtime 目录。
凡可写目录或文件均不允许运行 PHP / PY 等 除需要被直接访问的 PHP / PY 文件，其它动态文件均不允许被访问到，在 nginx 的配置文件中添加项，参：https://xoyozo.net/Blog/Details/nginx-location-if，若全站使用统一的入口文件访问，那么设置仅该文件允许运行 PHP 即可。通过 IO 方式被其它文件包含的文件，无需运行 PHP 权限。（“deny all”对 include 起作用，但对 IO 不起作用，因此 Runtime 目录可以继续为 ThinkPHP 提供缓存服务。）这一步非常有用。
使用与 nginx 网站用户不同的用户来部署网站文件，如宝塔面板 PHP 使用 www 用户，那么就使用 root 或其它新用户来上传文件，否则将导致全站目录和文件可写。有条件的建议不同网站使用不同的用户，可防止一个网站被入侵后导致其它网站文件或磁盘上的其它文件被泄露的风险（2022年10月2日从宝塔官方社区获悉，宝塔面板暂不支持使用非 www 用户创建并运行网站）。
Windows Server + IIS + ASP.NET：
配置每个磁盘的安全属性，拒绝“IIS_IUSRS”这个用户组的所有权限。只要设置驱动器即可，子文件夹和文件会自动继承。若运行 .NET Framework 项目，需要设置 C:\Windows\Microsoft.NET\Framework\v*.*.*****\Temporary ASP.NET Files\ 目录可修改写入权限，.NET Core 项目不需要此设置。
为每个网站创建一个新用户，仅隶属于“IIS_IUSRS”。网站根目录安全属性添加该用户，权限选择“读取”。（已测取消“读取与执行”不影响 PHP，“列出文件夹内容”视业务需求开启，建议关闭）。仅需要上传文件的目录或文件设置“修改”、“写入”权限。（修改对应修改文件，写入对应上传文件）
IIS 网站中设置“物理路径凭据”以及应用程序池的“标识”。
IIS 中设置写入目录的“处理程序映射”无脚本。