kuanat

@liyafe1997 #5

感谢指正，我确实说错了。

这里用技术语言来描述：S0 正常状态，S3 睡眠（持久化到内存），S4 休眠（持久化到硬盘）。

原始问题是，S3->S4 ，中间要经过 S0 吗？技术层面答案是要，但一般语境中认为不需要。操作系统在进入 S3 的时候，会注册一个目标时长的 wake event 回调，即特定时长之后转睡眠。当硬件到达特定时间点，就会 S3->S0 ，此时操作系统会检查唤醒原因，如果是用户的操作，那就继续完全恢复至 S0 ，如果是自己注册的睡眠回调，那就在只唤醒硬盘等必要设备，然后完成休眠准备进入 S4 。

排查故障先看是否能手动进入休眠，很多支持 Modern Standby 的新设备都不支持休眠了。

如果能手动休眠，大概率是 bios 问题，可以反编译 acpi 看哪里出了问题。

unbind key 的语法类似于

```
[
{
"context": "Editor",
"bindings": {
"ctrl-space": null,
}
}
]
```

回复里可能排版不正常，你可以看一下默认 key bindings 的写法，context 是上下文状态，将对应按键设置成 null 就可以。


插件我没有做，执行 `fcitx5-remote -s keyboard-us` 切换是很容易的，官方扩展 api 里面有个 process 模块。但是没有一个好的切入点让这个插件版的命令在 vim 退出插入模式的时候自动执行，最后还要回到 task 上面来。跟我这个方案没区别。

另外 zed 在某个版本之后修改了底层 key handling 的逻辑，比较接近 DirectX 这样从底层取按键状态，而不是取窗口管理器传递的按键消息，所以对输入法造成了很大影响，特别是在 pre-edit 状态下，输入法和 zed 本身在按键处理上可能产生混乱。开发者明显是不懂 ime 的，所以 cjk 用户提的方案很难被接受，尽管开发者很努力地尝试理解，但在这个底层处理机制之上做修改还是太难了。现在什么情况我不太清楚。

实践中所有这种需求场景几乎都采用人工复核的方式，倒不是因为人一定对，而是因为人可以担责。如果你的方案里要求去掉人，那这个问题就无解，除非你能为出错的数据兜底。你能兜底的程度越低，相应的置信度阈值就要拉得越高，实践中能够自动化识别的样本比例就越低。

另外单据 ocr 识别是个多少年的需求了，做这个的外包公司或者团队怕不是遍地走。这事根本没必要上大模型，传统 ocr 算法完全够用。

各种 ocr 算法方案在归一化之后的性能表现差距很小。差别大的方面是，在没有前置信息的情况下，先识别出哪里有文字，字符间如何分隔，以及判断文字可能的语言的阶段，以及整体的识别速度。

对 2000 年前后基于传统算法的方案来说，ocr 识别能力属于有多少人工就有多少智能的水平。只要是标准化印刷单据加手写的识别场景，几乎都可以暴力解决。算法判定不准文字位置、字符集，但是人知道啊，提前对单据照片或者扫描图进行畸形校正、裁切和二值化，再把手写的部分抠出来切分，最后只把识别的过程交给 ocr 。这个流程差不多是过去 20 年最主要的方案，基本上只看你归一化做得是不是细致。据我了解有些团队做久了，积攒下几千种不同的单据模板。

2010 年之后 ocr 算法过渡到了 cnn 为主，但相对于之前的暴力解法来说，没什么差别。原来甲方用了 ocr 还是要有个人负责复核，现在一样需要这个人，就算用上了什么大模型，即便出错概率极低，还是需要一个人来兜底。

如果是同一个语言的微服务，最起码还可以直接引入代码。如果是不同语言的项目混用，那几乎就只有 dsl 代码生成这一条路了。

抽象出来 common 包存放数据结构之类的定义，这个思路是对的。我大概几年前也经历过类似改造，尽管项目本身不大，但这个过程挺痛苦的，因为这个改造看的其实是自动化的水平。

我印象当时选定的方案是 git submodules ，因为这个功能在之前的工作流中几乎用不到，还专门开会做团队培训……然后是几个人花了几天抽象了一个公共数据结构定义，写了个 common 包，准备一个一个微服务重构。

这个过程中发现的各种不一致的 bug 就不提了，最大的障碍是没人敢直接用新实现替代旧的版本，尽管初期改的几个包都是挑的代码少的软柿子。而且 submodules 方案也增加了开发人员的心智负担，因为一般的特性分支工作流，需要经常在维护旧代码和开发新功能上来回切换，用 submodules 就要注意每个分支和 common 依赖版本的对应。最后是自动化运维的部门出了大力，在生产环境做了个流量镜像，复制了一部分请求到新版本部署的测试服务器上，然后看执行结果和原版是否一致。

在这之后又增加了一个人为规定，就是所有项目 repo 都必须包含构建脚本，其实就是几个 hooks 检查 submodules 是否更新或者版本对应正确。因为我们用的是特性分支工作流，只要核心的 master/dev/staging 几个分支提前做好与 common 分支的对应（技术上是对应到 commit ），common 的更新就可以通过特性分支简单合并到每个项目中，实现由上至下的传播，开发人员只要知道在当前项目的哪个分支上工作即可，不需要关心依赖的手动更新。

这样改完了效果还是挺明显的，没有各种重复、不一致的定义，ide 补全也可用。只是增加管理成本，特别是负责 common 维护的。因为基础数据结构的改变，可能影响 API ，还可能影响 ABI ，即便是结构体增加一个字段，都有可能不兼容。同时 common 的改动要伴随所有微服务模块的改动，测试一定要跟得上才行。

至于常量的部分，我认为需要根据常量本身来区分。如果是那种界面上的文字肯定是放到直接使用的包比较好，剩下大部分常量，比如服务器地址这些，我认为还是在环境变量中设置比较好。体现到项目中就是 dotenv 这种，环境不同设置也不同。这个方案需要额外处理两个细节，一个是如何集中管理或者持久化，二是一些类似密钥的不适合用明文的要如何处理。

对于单语言项目，简化处理可以用公共 constant 包，对于多语言项目来说，一般是集中定义，然后通过 sed 之类的工具在源码级别上做替换。

我的话一般会停止服务，不过这个行为取决于备份粒度。一般来说我不会把很多服务的数据放在一起备份，而是单独处理。

从应用或者服务的层面看，大多数写入行为都是非同步的，像数据库一般会设计成 WAL 同步写，主库带缓冲的形式，暂停服务可以降低不一致的“来源”。

如果备份行为是复制，还要多考虑同一批文件由于备份这个行为的造成的时间差异，这也是不一致（匹配）的来源。如果是在 CoW 系统上，先创建快照，再将快照持久化备份会好一些。

当然这个事情还是看需求场景，只是一般来说，维护一个高可用系统的备份和恢复机制更麻烦一些，停止备份再恢复相对来说更容易自动化。

@codehz #8 感谢解释。

我这边检查了一下，是我之前拦截了对 localhost 的访问，我还以为之前的 PNA 通过了呢。

我又回头确认了一遍，RCE 是两部分共同实现的，通过 api 控制是 POST/json ，本身是需要跨域的，但 clash 默认允许……第二个漏洞是配置项在 unmarshalling 的时候，解析的路径没有检查就直接使用，所以可以下载任意文件并执行。

现在 chrome/firefox 应该都会默认阻止对 localhost 端口的非直接访问，这个第一步应该就执行不下去。