之前写过一篇Mac蓝牙鼠标卡顿、飘的临时解决方案，但当时这种方法其实现在感觉一般其实还有一个简单粗暴的办法，打开活动监视器，搜索bluetoothd（其实只要搜索blu三个字母就出来了）。然后直接杀掉这个进程。
因为这个是系统服务，你杀完后他会自动重启，这时候晃晃鼠标什么的，就又会自动连上了。
卡顿的问题基本上确实就是：2.4G的wifi冲突，当然还有可能是某些中断导致。但一般重启一下bluetoothd服务就能解决90%以上的问题。
再不济，重启吧
2022 年 11 月
rpm数据库修复
因为偷懒，在腾讯云上使用的时候，就直接用了bt面板的镜像，这个镜像用的是centos，也因此就有了yum 和rpm数据库的问题。
因为某次在更新的时候嫌慢，所以直接ctrl+c，然后。。。再次启动的时候就：
yum update
错误：rpmdb: BDB0113 Thread/process 8643/139904725112896 failed: BDB1507 Thread died in Berkeley DB library
错误：db5 错误(-30973) 来自 dbenv->failchk：BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
错误：无法使用 db5 - (-30973) 打开 Packages 索引
错误：无法从 /var/lib/rpm 打开软件包数据库
CRITICAL:yum.main:
Error: rpmdb open failed
---看这个样子，就是数据库坏了。
看起来没什么特别好的办法，只能重建，于是：
# mkdir /var/lib/rpm/backup
# cp -a /var/lib/rpm/__db* /var/lib/rpm/backup/
# rm -rf /var/lib/rpm/__db.[0-9][0-9]*
# rpm --quiet -qa
# rpm --rebuilddb
# yum clean all
yum clean all运行完后会显示 ：
已加载插件：fastestmirror, langpacks
Repository epel is listed more than once in the configuration
Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast
正在清理软件源： centos-sclo-rh epel extras os updates
Cleaning up list of fastest mirrors
至此，修复完毕，因为用的腾讯云，所以直接将源切到腾讯：CentOS (tencent.com)，先用yum version看看版本，然后下载相应的repo。最后运行：
yum clean all
yum makecache
世界清静了
引入unplugin-auto-import无效
前段时间用React，这段时间用Vue3（用uniapp写小程序的时候也尝试切换到vue3了），本来觉得很累的，毕竟在每次使用都要import {vue} from 'vue'之类的，在使用了unplugin-auto-import插件后，真的少写了好多。但也要看unplugin-auto-import是不是支持。
比如我现在直接引用了vue，象现在onMounted/ref等都不再定义了。
然而刚开始的时候却是怎么都没法用，这时候才发现虽然我代码都是用JS写的，但auto-import插件是ts写的，必须要引入typescript组件，然后他才生成一个：auto-imports.d.ts的文件，这时候配合<script setup>这个所谓vue3的黑魔法，才是妥妥的。
没什么大东西，就是这么记录一下
华为平板M5的webview的一个BUG
用flutter的webview来展示一个数据页面，因为这个页面如果用原生开发，得费不少时间，而且中间还要显示图表，也可能随时要调整，所以最后改用了webview。
项目是检测内容的结果，因为要检测七大类，每个类都有一个图表和相应的数据呈现，但因为设计稿已经预先有了外框结构，因此内嵌的这个webview的宽度大约在800左右 ，触发了tailwind的sm的效果。所以原来一个检测结果 两列显示的，变成了一列，也因此400左右的高度的，变成了800左右，而有7个项目，则成了5600的高度。
利用webview的jschannel，在resize获取到高度后通过postmessage发送回flutter，flutter获取高度后再setState一下。看起来没差，在小米上很轻松的就显示了。但华为的机器就是不行。中间一块黑屏。
查看LOG，发现一堆bindTextureImage的错误，抛的异常也是Exception updateTextImage，可是我页面上并没有TextImage，所以就开始怀疑Webview了。之前为什么没有怀疑呢，就是因为其他页面上的webview是正常的。
1、将元素中用到Image的先屏蔽一下，仍然报错
2、将webview禁用，无错
3、打印postmessage的值，发现是49xx左右 ，于是强制设定webview的高度为1024，正常
4、不停调整webview的高度，直到3200左右直接黑屏
5、本来在考虑是否用Scrollbar，但事实上因为这个页面的设计稿正好将检测报告放在正中，四周都有内容，不方便全屏到底
最后，将检测报告改用tabbar的HTML来展示 。这样单个Tabbar的高度就算扩展到1000左右也不影响显示，经过测试一切正常。
华为这台机器真LOW啊，然后查了一下，海思960s，还是960的降频版，内存4G，鸿蒙2.0，用了大概3小时，无故大崩了3次，其中2次重启一次是refresh。虽然这是2~3年前的机器，但这也太。
navicat连接腾讯云轻量数据库的一个小坑
买了腾讯云的轻量数据库，便宜（其实现在和直接买1c1g的数据库也差不多了）。在做数据迁移的时候直接用了navicat的data transfer（这功能真方便）
因为数据库不大，只有2~300M，用datatransfer走起来非常快。基本上3分钟左右 就搞定了。如果我dump sql，再upload & import sql，反而比这个速度还要慢一点。
然后问题就来了，查询的时候，全是乱码，这个很明显，是latin1的问题了，于是上数据库 执行了一下：SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然
character_set_client latin1
character_set_client_handshake ON
character_set_connection latin1
character_set_database utf8mb4
character_set_filesystem binary
character_set_results latin1
character_set_server utf8mb4
character_set_system utf8
character_set_client_handshake ON
character_set_connection latin1
character_set_database utf8mb4
character_set_filesystem binary
character_set_results latin1
character_set_server utf8mb4
character_set_system utf8
这个就纠结了，即使我set names utf8mb4，用datatransfer也是这个问题。
我导数据过来的那一台，也是轻量级数据库，理论上不应该会有这个问题，于是我看一下connection的相关信息。发现正常的那台，encoding居然选的是auto，而这台不正常的选择的是utf-8，难道是因为这个原因？于是切回auto重连。
再次运行SHOW SESSION VARIABLES LIKE 'character\_set\_%';果然 character_set_client 已经恢复成utf8mb4了。
这个问题也真是妖~
