不知道从哪个版本的 Chrome 或 Edge 开始，我们无法通过 ctrl+v 快捷键将时间格式的字符串粘贴到 type 为 date 的 input 框中，我们想办法用 JS 来实现。

方式一、监听 paste 事件：

const input = document.querySelector('input[type="date"]');
input.addEventListener('paste', (event) => {
    input.value = event.clipboardData.getData('text');
});

这段代码实现了从页面获取这个 input 元素，监听它的 paste 事件，然后将粘贴板的文本内容赋值给 input。

经测试，当焦点在“年”的位置时可以粘贴成功，但焦点在“月”或“日”上不会触发 paste 事件。

方式二、监听 keydown 事件：

const input = document.querySelector('input[type="date"]');
input.addEventListener('keydown', (event) => {
    if ((navigator.platform.match("Mac") ? event.metaKey : event.ctrlKey) && event.key === 'v') {
        event.preventDefault();
        var clipboardData = (event.clipboardData || event.originalEvent.clipboardData);
        input.value = clipboardData.getData('text');
    }
});

测试发现报错误：

Uncaught TypeError: Cannot read properties of undefined (reading 'getData')

Uncaught TypeError: Cannot read properties of undefined (reading 'clipboardData')

看来 event 中没有 clipboardData 对象，改为从 window.navigator 获取：

const input = document.querySelector('input[type="date"]');
input.addEventListener('keydown', (event) => {
    if ((navigator.platform.match("Mac") ? event.metaKey : event.ctrlKey) && event.key === 'v') {
        event.preventDefault();
        window.navigator.clipboard.readText().then(text => {
            input.value = text;
        });
    }
});

缺点是需要用户授权：

仅第一次需要授权，如果用户拒绝，那么以后就默认拒绝了。

以上两种方式各有优缺点，选择一种适合你的方案就行。接下来继续完善。

兼容更多时间格式，并调整时区

<input type="date" /> 默认的日期格式是 yyyy-MM-dd，如果要兼容 yyyy-M-d 等格式，那么：

const parsedDate = new Date(text);
if (!isNaN(parsedDate.getTime())) {
    input.value = parsedDate.toLocaleDateString('en-GB', { year: 'numeric', month: '2-digit', day: '2-digit' }).split('/').reverse().join('-');
}

以 text 为“2023-4-20”举例，先转为 Date，如果成功，再转为英国时间格式“20-04-2023”，以“/”分隔，逆序，再以“-”连接，就变成了“2023-04-20”。

当然如果希望支持中文的年月日，可以先用正则表达式替换一下：

text = text.replace(/\s*(\d{4})\s*年\s*(\d{1,2})\s*月\s*(\d{1,2})\s*日\s*/, "$1-$2-$3");

处理页面上的所有 <input type="date" />

const inputs = document.querySelectorAll('input[type="date"]');
inputs.forEach((input) => {
    input.addEventListener(...);
});

封装为独立域

避免全局变量污染，使用 IIFE 函数表达式：

(function() {
  // 将代码放在这里
})();

或者封装为函数，在 jQuery 的 ready 中，或 Vue 的 mounted 中调用。

在 Vue 中使用

如果将粘贴板的值直接赋值到 input.value，在 Vue 中是不能同步更新 v-model 绑定的变量的，所以需要直接赋值给变量：

<div id="app">
    <input type="date" v-model="a" data-model="a" v-on:paste="fn_pasteToDateInput" />
    {{a}}
</div>
<script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>
<script>
    const app = Vue.createApp({
        data: function () {
            return {
                a: null,
            }
        },
        methods: {
            fn_pasteToDateInput: function (event) {
                const text = event.clipboardData.getData('text');
                const parsedDate = new Date(text);
                if (!isNaN(parsedDate.getTime())) {
                    const att = event.target.getAttribute('data-model');
                    this[att] = parsedDate.toLocaleDateString('en-GB', { year: 'numeric', month: '2-digit', day: '2-digit' }).split('/').reverse().join('-');
                }
            },
        }
    });
    const vm = app.mount('#app');
</script>

示例中 <input /> 添加了 data- 属性，值同 v-model，并使用 getAttribute() 获取，利用 this 对象的属性名赋值。 

如果你的 a 中还有嵌套对象 b，那么 data- 属性填写 a.b，方法中以“.”分割逐级查找对象并赋值

let atts = att.split('.');
let target = this;
for (let i = 0; i < atts.length - 1; i++) {
    target = target[atts[i]];
}
this.$set(target, atts[atts.length - 1], text);

外星人笔记本电脑键盘突然失灵，尝试过重启电脑、长按电源键（强制关机、切换电脑性能）、卸载键盘驱动、BIOS 恢复默认设置都没有效果。多次尝试后恢复正常，总结经验：

办法一：关机、拔掉电源、插上电源、再开机，就能恢复正常。

办法二：长按电源键直到关机成功，长按电源键直至开机完成。

若无效，强制关机、插拔电源，多试几次。

总之，这电脑不用的时候尽量关机，直接合上盖子会出现自动苏醒、键盘失灵等一系列问题。

2023年9月补充，最近发现直接合上盖子没有出现自动苏醒，先睡眠再拔电源也没有出现苏醒，可能与我经常在 Alienware Update 和 SupportAssist 中更新驱动和固件有关。

论坛出现动态页面打开或刷新非常慢（超过半分钟），甚至打不开，该页无法显示，502 Bad Gateway 等情况，TTFB 计时需要好几秒。

切换 nginx 版本、php 版本 等均无效果，甚至购买新的 ECS 重新搭建环境也是效果甚微。

最终在阿里云 RDS 管理中，手动主备库切换，问题得以解决。

因此大概率是原主库有问题（有损坏的表需要修复或锁等情况）。

查询故障时间段的慢 SQL，发现某表的锁等待时间特别长，不知道是不是这个表的原因导致的。

次日，提交工单得到回复是原主库（现备库）会自动修复，经再次主备库切换测试得到了肯定的结果。

再次日，又遇到同样的打开慢的情况，这次直接找到慢 SQL 中锁等待时间较长的表，优化（OPTIMIZE TABLE）（虽然是 InnoDB），立刻解决了问题。

• 在 vue 实例化之前，jQuery 绑定事件无效
  

已使用指定的进程(“Web Management Service”)连接到远程计算机，但未能验证服务器的证书。如果你信任该服务器，请再次连接并允许不信任的证书。  在以下位置了解更多信息: https://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED。

基础连接已经关闭: 未能为 SSL/TLS 安全通道建立信任关系。

根据验证过程，远程证书无效。

在 Discuz! 论坛中，帖子的楼层号是从主题开始计的，即“楼主”是 1#，“沙发”是 2#，“板凳”是 3#，“地板”是 4#，从 5# 开始直接以数字显示，所以我们在计算中奖楼层时，应排除主题帖所在的 1#。以活动截止时的最大楼层号 1000# 为例，允许中奖的楼层数应为 999。据此设计了以下中奖算法：

1、将****年*月*日的上证指数收盘价（含两位小数）×100
2、将得到的 6 位数字按倒序排列
3、用这个新的 6 位数除以总的回复楼层数（即活动截止时的最大楼层号－1），得到余数
4、将余数＋2 即为中奖楼层
以2020年9月30日上证指数收盘价为例：3218.05×100=321805，倒序后是 508123，若截止时间前的最大楼层号为 1000，那么 508123÷(1000－1)=508 余 631，则中奖楼层号为：631＋2=633。

注：

股市 15:00 收盘，但更新收盘价会延迟若干秒，因此稍候查看收盘价更为准确。

论坛发帖会有延时，特别是在抢楼这种高并发的情况下，在“抢楼主题”类型中设置了结束时间后，实际结束时的最终一个回帖的时间仍然可能超过活动截止时间（比如超过 1 秒），所以应在活动说明中明确具体以哪一个楼层结束。

其它活动说明：如不按规定回复中奖无效，不重复中奖的顺延方案，中奖楼层不存在的顺延方案等。

上证指数实时获取接口：http://hq.sinajs.cn/list=sh000001

返回结果例：var hq_str_sh000001="上证指数,开盘价,昨收价,最新价,最高价,最低价,0,0,总手,金额,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,日期,时间,00,";

特别注意，传入不同股票代码返回结果数据中的保留小数位数不同，上证指数保留了四位小数，应四舍五入保留两位小数后参与计算。

在数据库连接字符串可设置是否将 tinyint(1) 映射为 bool，否则为 sbyte：

TreatTinyAsBoolean=false/true

tinyint(1) 一般用于表示 bool 型字段，存储内容为 0 或 1，但有时候也用来存储其它数字。

以 Discuz! 的表 pre_forum_post 为例，字段 first 和 invisible 都是 tinyint(1)，但 first 只储存 0 和 1，invisible 却有 -1、-5 之类的值。

因此我们一般设置 TreatTinyAsBoolean=false，程序中 first 与 invisible 均以 sbyte 处理。

设置 TreatTinyAsBoolean=true 后，EF 或 EF Core 自动将该类型映射为 bool，方便在程序中作进一步处理。

一旦设置 TreatTinyAsBoolean=true，那么所有查询结果中 tinyint(1) 字段的返回值永远只有 1 和 0（即 True/False），即使真实值为 -1，也返回 1。

因为我们必须在确保所有的 tinyint(1) 类型字段都仅表示布尔值是才设置 TreatTinyAsBoolean=true。

一旦部分 tinyint(1) 类型字段用于存放 0 和 1 以外的数，那么就应该设置 TreatTinyAsBoolean=false。

在数据库优先的项目中，以 TreatTinyAsBoolean=false 生成数据模型后，可将明确为布尔类型的字段改为 bool。列出 MySQL 数据库中所有表所有字段中类型为 tinyint(1) 的字段值

以 .edmx 为例：

在项目中搜索该字段名，在搜索结果中找到 .edmx 文件中的两处。

.edmx 文件中的注释已经表明其包含 SSDL、CSDL、C-S mapping 三块内容，

在 SSDL content 下方找到该字段：

<Property Name="字段名" Type="tinyint" Nullable="***" />

改为

<Property Name="字段名" Type="bool" Nullable="***" />

在 CSDL content 下方找到该属性：

<Property Name="属性名" Type="SByte" Nullable="***" />

改为

<Property Name="属性名" Type="Boolean" Nullable="***" />

在解决方案管理器中展开 .edmx ->库名.tt -> 表名.cs 文件，

将模型类中的属性

public sbyte invisible { get; set; }

改为

public bool invisible { get; set; }

或 sbyte? 改为 bool?。

在 EF Core 中，直接打开对应数据表的 .cs 文件，更改属性类型即可。

相关报错：

错误: 指定的成员映射无效。类型中的成员的类型“Edm.SByte[Nullable=False,DefaultValue=]”与类型中的成员的“MySql.bool[Nullable=False,DefaultValue=]”不兼容。

InvalidOperationException: The property '***' is of type 'sbyte' which is not supported by the current database provider. Either change the property CLR type, or ignore the property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.

尝试先连接一次能解决此问题（概率），非常的莫名其妙：

using Data.Discuz.db_bbs2021Context dbd = new();
var conn = dbd.Database.GetDbConnection();
conn.Open();
conn.Close();

参考：

https://mysqlconnector.net/connection-options/

https://stackoverflow.com/questions/6656511/treat-tiny-as-boolean-and-entity-framework-4

2023年1月注：本文适用于 Pomelo.EntityFrameworkCore.MySql 6.0，升级到 7.0 后会出现：

System.InvalidOperationException:“The 'sbyte' property could not be mapped to the database type 'tinyint(1)' because the database provider does not support mapping 'sbyte' properties to 'tinyint(1)' columns. Consider mapping to a different database type or converting the property value to a type supported by the database using a value converter. See https://aka.ms/efcore-docs-value-converters for more information. Alternately, exclude the property from the model using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.”

解决方法：https://xoyozo.net/Blog/Details/the-sbyte-property-could-not-be-mapped-to-the-database-type-tinyint-1

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

重启系统。

附加消息：暂无该开发者或未上传过应用

原因： 没有上架应用（隐藏的不算上架），应用设置显示后记得在版本管理中将版本也设为显示。

附加消息：抱歉，开发者验证无效

原因：可能是没有达到认证要求，不允许加群（譬如：需应用最低总安装量 1000 次）

DZ 水很深，慎入：http://open.discuz.net/?ac=document&page=xootan

2018.8.14 踩坑：

还有，加群要开发者中填写的 QQ 才能加，因为验证是全自动程序判断的。

如果要跳过安装量 1000 次的要求，就直接花钱购买会员，不过购买会员也是一件非常艰难的事情，在与“Q群管家”这个机器人 QQ 的对话中发送“@购买vip”，绝对能让你体验到一种有钱也花不出去的感受。

做这么多花哨的东西，不如踏踏实实把产品做好。

2018.8.15 踩坑：

跟Q群管家对话，@login 时，由于密码过于复杂，消息没反应，特殊符号别提了，连纯大小写字母数字也不行，后改成纯数字密码登录成功。

加群完全看基本信息中填写的 QQ 客服 号，群主是机器人，只要应用是上架显示的，版本是显示的，就可以用这个QQ客服申请入群，（可以改）。

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。

体验“全表扫描”

首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s

表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。

索引对 ORDER BY 的 ASC 和 DESC 的影响

我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s

创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。

试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s

结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。

索引字段的次序对 WHERE 和 ORDER BY 的影响

删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s

结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s

原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。

索引中的字段必须依次使用

保持上例创建的索引不变，即 `time`, `a_id`。

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s

上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s

WHERE 和 ORDER BY 混合

保持上例创建的索引不变，即 `time`, `a_id`。

先来执行这两句：

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s

为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。

现在把索引改成只有 `time` 一个字段。

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s

因为索引里有 `

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s

第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。

索引中的字段越多越好

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。

SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 0.013s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 15.015s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s

可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。

索引对 INSERT / UPDATE / DELETE 的效率影响

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。

一些误区

“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。

另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！