博客 (102)

本文讲述使用网页开发适用于宴会、活动、年会现场 LED 大屏幕显示抽奖、抢楼、游戏、视频等互动界面，通过在浏览器中打开后 F11 全屏投影到大银幕上。

设计思路：

1. 为了保证最佳的显示效果，设计稿的尺寸按大屏幕的“宽高比”来做（本文以4米*3米的大银幕为例，设计稿以800*600像素为例）。

2. 由于电脑的视频输出分辨率很有可能与大银幕的宽高比不同，那么我们全屏投影后会界面会有变形，但是投影设备接收到电脑视频信号后再全屏显示到大银幕时，界面又会变回正常。

3. 按设计稿的尺寸开发网页，并使用 CSS3 的 scale 实现整体伸缩，目的是自适应窗口尺寸来全屏显示内容，无留白、无裁切。整体拉伸的要求是文字、图片、背景、间距、iframe 等所有元素以统一的比例拉伸，无错位。

4. 网页上通过 JS 设置一些快捷键来实现页面展示内容的切换。

5. 若投影设备功能有限或操作员水平有限等原因导致无法顺利设置输入输出分辨率时，网页可设置 x 轴和 y 轴两个方向的伸缩系数、定位偏移量等，更灵活地实现完美投影需求。
   

开发要点：

• 网页尺寸按设计稿来定（以 800x600 为例）。

• 使用 CSS3 的 transform 的 scale 来实现缩放，以电脑显示器分辨率 1920x1080，宽放大 1920/800 倍，高放大 1080/600 倍，即可将设计稿全屏展示到电脑显示器上。为了更灵活，我们使用窗口大小来代替显示器分辨率，这样不管怎么改变窗口大小或者全屏，设计稿都能完整地显示在窗口上。

• 在页面初始化和窗口尺寸变化时重新调整设置上述比例。

代码参考：

• jQuery 示例

• Vue3 示例

今天发现，阿里云 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" />

无法向会话状态服务器发出会话状态请求。请确保 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

重启系统。

用过 FlashFXP 的朋友可能会它强大的功能赞不绝口，但不免费啊，用破解版对咱们的账号安全也存在一定风险。所以平常用得最多的是免费开源的 FileZilla。

今天我把觉得 FileZilla 最应该支持的“计划任务”和“站点对传”两个功能在官方论坛进行了咨询。据 FileZilla 官方回复，暂时没有支持“计划任务”的时间表，而且由于不兼容 SFTP 的原因，服务器对服务器的直接传输也无法实现。（他可能误解了我说的“站点对传”的意思了吧）

这是一篇可能解决困扰了 .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。

整理成表格：

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 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
  

【推荐】临时口令和会话口令合二为一的流程（适合随时授权）

前提：

小程序已绑定到微信开放平台。

分两种场景：

场景一：仅需要获取 unionid，且不需要获取头像昵称等用户信息，且已经有很大部分用户仅通过 code2Session 就能获取到 unionid（如：已关注了绑定同一微信开放平台的其它公众号，参 UnionID 机制说明）；

场景二：仅需要获取 unionid，或需要获取 unionid 及头像昵称等用户信息，或很大部分用户不能通过 code2Session 获取到 unionid。

场景一步骤：

1. 小程序调用 wx.login()，将 code 发送到开发者服务器

2. 开发者服务器请求微信接口 code2Session，获得 session_key、openid，有机会获得 unionid

3. 若没有返回 unionid，尝试用 openid 从数据库中获取 unionid

4. 如果数据库中没有找到对应的 unionid，告知小程序端使用 button + getUserInfo 的方式请求用户授权

5. 授权允许（判断 detail.errMsg 是否为 getUserInfo:ok）则将加密数据传回开发者服务器进行解密，得到 unionid、头像、昵称等信息，保存到数据库

6. 若授权拒绝，则无动作，用户再次点击 button 会重新弹起授权框

* 该流程仅部分用户的首次使用才要求授权。其它注意事项和流程细节见下方流程图。

场景二步骤：

1. 小程序调用 wx.login()，将 code 发送到开发者服务器

2. 开发者服务器请求微信接口 code2Session，获得 session_key、openid

3. 尝试用 openid 从数据库中获取 unionid 和/或 用户信息

4. 如果数据库中没有找到对应的 unionid 和/或 用户信息，告知小程序端使用 button + getUserInfo 的方式请求用户授权

5. 授权允许（判断 detail.errMsg 是否为 getUserInfo:ok）则将加密数据传回开发者服务器进行解密，得到 unionid、头像、昵称等信息，保存到数据库

6. 若授权拒绝，则无动作，用户再次点击 button 会重新弹起授权框

* 该流程仅每个用户的首次使用才要求授权。其它注意事项和流程细节见下方流程图。

上述两种场景的设计流程，只要数据库中已保存用户的 unionid（和/或 用户信息），都不再需要用户再次授权（即使在“设置”中关闭了“用户信息”授权，点击小程序右上角三点按钮，选择关于小程序，点击右上角的三点，选择设置）。

场景一流程图：

场景二流程图：

流程图中的“临时口令”仅用于关联“通过 code2Session 获得的 session_key”，并在用户授权后带回换取 session_key。原因是 session_key 是机密数据，不允许被传到小程序端。临时口令用完即删（设置表 dt__weapp_code2session 中相应记录的该字段为空）。

【推荐】临时口令和会话口令合二为一的流程（适合随时授权）

如果你是刚入手的小米 WiFi 电力猫，那么按说明书一步一步配置即可。这里记录一下移机的重置方法。

本次移机的场景是电力猫从一台小米路由器更换到另一台小米路由器的配置，两台小米路由器 WIFI 的 SSD 不同（假设为 WIFI-A 和 WIFI-B）。

错误做法：打开米家，切换到 WIFI-B 所在的房间，点击右上角的添加新设备，根据介绍插上子猫，并按子猫的配置键 5 秒以上。连上“xiaomi-plc-xxx”，米家显示正在连接，但到达 100% 后显示连接超时。

可能的错误原因：

1. 没有插上主猫

2. 该电子猫已经在米家上添加过了（在 WIFI-A 所在的房间），就无法添加到其它房间了（仅猜测，未实测）

于是，同时插上主猫和子猫，并且路由器和主猫使用网线连接，什么都不设置，过一两分钟，两猫自动会变成蓝灯（表示连接成功）。这时，如果刚才那步没有重置成功的话，打开米家主界面上的“小米电力线wifi扩展器”（如果没有删除过，还在 A 房间），里面会显示网络名称为 WIFI-A，还可能没有开“WIFI漫游”。这样虽然能连接上网，但有两个 SSD，不能实现漫游。

这时，按子猫配置键 5 秒以上，并静等一分钟以上，变回蓝灯后，再打开米家，就会看到网络名称可能是 WIFI-B-Plus，这时"WIFI漫游”也能打开了，完美扩展了 WIFI。

综上实践得出：

WIFI 是由子猫负责的，所以跟 SSD 有关的配置由子猫负责；

一台设备（这里指电子猫套餐）只能添加到米家一次，但可以更改设备所在的房间。

正确的重置电力猫步骤是：

1. 同时插上主猫和子猫

2. 主猫连上路由器

3. 子猫按配置键 5 秒以上，等待一分钟以上

4. 打开米家，进入“小米电力线wifi扩展器”，打开 WIFI 漫游

以上仅在使用小米路由器情况下实测，非小米路由器未尝试。

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 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 操作）：

>>> 过滤信息：

如分页、搜索等

>>> 常用状态码：

>> 错误处理：

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 版本：

https://myssl.com/