倾向于用一组特别命名的私有方法去处理副作用，甚至单独封装成一个内部类，把状态对象的修改都放到里面，visitor 像调用纯函数一样调用这组方法。

在 windows 下只在睡眠模式下成功过，休眠模式失败，雷蛇笔记本。
linux 没试过 wifi ，只试过 lan 。
这个也分电脑。

你要想充分利用 git merge 的自动冲突解决能力，就不要做 squash 、fixup 、amend 、cherry-pick 这类会修改 commit 的操作，你必须在 merge 时原样保留各路 branch 。
你只要记住，如果你要 merge branch ，一定要保留 branch 原来的样子。因为 git 就是利用 branch 和 merge commit 来决定冲突解决结果的。

@netabare 我这样整体地描述该模式，看看是否命中了你的疑惑，因为我觉得可能你对这个模式的运转方式理解错了。

首先有一组固定类型的 object ，每个 object 内有多种类型的 element ，然后有多个 visitor 可以处理这组 object 。
每个 visitor 定义了一种将这组 object 输出为一种形式的业务逻辑，那么多个 visitor 分别代表可以输出不同形式的业务逻辑，visitor 之间是互相独立的。每种 element 需要对应一个 visitor 的 visitXXXElement 方法的实现。该方法的调用通过 element.accept 来做 dispatch ，这样就避免了业务侧用 switch case 做模式匹配，仅需 iterate elements 的 accept 方法即可完成调用。
其中关于 accept 的返回值，如果对这组 object 进行 visit 的结果是顺序的列表，自然可以直接将返回值简单地 map 为顺序列表。但如果 visit 的结果是其他复杂的类型，这部分业务逻辑必须由 visitor 在内部暂留状态，在整体 visit 结束后通过注入 end 的方法返回。这完全取决于要处理的业务，这部分不是该模式的核心。
其中关于 iterate elements ，这部分甚至也可以做到 visitor 的基类中，取决于 elements 的顺序如何产生，是统一的还是无关的。这部分不是该模式的核心。

举个例子，把一种 tree 输出为 json 、xml 、table 不同格式的业务。这里 tree 就是 object ，各种 tree node 就是 element ，json xml table 各需要一种 visitor. 其中对于 xml 如果选择用 element 嵌套的格式来表示输出形式，那么自然不可能直接由 accept 返回，因为整体结果是个 xml root element.

再补充一些各类现实情况：
- 什么情况下不能用开关控制：各定制功能客户要求不能将自己分支的源代码或功能泄漏给第三方。
- 什么情况下不适合用开关控制：定制功能基本没有共性，但代码同时存在，存在被互相引用的风险（当然这个可以用 lint 或 review 来控制）
- 多个定制方都需要相同的功能：1. 尽量从一开始设计好 2. 开发时，应从 base 分支创建分支，然后将该分支合并到各定制业务分支上
- 什么情况下不要用分支管理，而是分 repo：业务的技术实现会完全分叉，不管是基础库，还是业务框架，都会变得迥异，那么就没必要使用分支来确保同一个 base 代码了

我想说，大概就是因为你搞错了翻译，使得你理解错了这个模式。
visitor 不是观察者，visitor 是访问者。
visitor 模式用来解决的业务问题是——将访问图等各类对象数据结构的算法和其具体的业务逻辑分离，这里面 visitor 指的是 visit objects 。

至于该模式的具体实现，是否 accept 有返回值，不是首要重点，但也很重要，符合了最广泛的一种业务模式。
像 https://refactoring.guru/design-patterns/visitor 中的实现，无返回值。试想，如果 client 调用各类 ele 的 accept 返回各种 node 的处理结果，那么这些结果就需要由 client 自己集合为最终结果，但这部分是具体业务逻辑，应该由具体的 visitor 实现来负责。

对于 git 来说，你这两种模式没区别，都是 branch.
你说 fork 的时候是不是指 github 上的 repo 。这时候这两者的区别在于 repo 层面的管理，包括 org 、member 、permission 什么的。

你这种需求——拆出去、合回来，用 branch 管理是最合适的，设计好各种条件下如何建分支就好了。不要用什么 cherry-pick 甚至多项目。

大概是运行时生成的代码吧

能流畅使用基本的编辑功能就够了。
其他 IDE 能覆盖的也不需要费劲折腾 vim

可以从日常开发找痛点和提效出发

你通过代码写单例，和 node 包管理机制导致的单例，那也是两码事。
对于后者的 commonjs ，清除 require cache 重新 require 就会创建一个新实例，旧的还会存在。

关于 ioredis 的阻塞调用，你可以看 https://github.com/redis/ioredis?tab=readme-ov-file#pubsub ，这是 pub sub 相关的。
你上面贴的 redis 代码里几句注释里的 single-thread 是 redis 程序自身的，不是指 node 的。而且这段只适用于普通的非阻塞调用命令。
总之，实例、连接、线程、调用，这是四种概念，还要分开是 node 进程的还是 redis 进程的，不能一概而论。
最后，具体情况具体分析。

单例是 nodejs 运行时的对象实例分配的事情，库的功能还要结合对应的中间件或者服务考虑，不能一概而论，这个得结合对应的库的功能实现来考虑。
举个例子，prisma+底层数据库，底层调用有连接池，此时用单例也不会影响并发调用；而 ioredis 单实例的调用内部是单连接，调用 subscribe 或者 block 调用就会阻塞其他调用。
另外，复杂的框架还要针对各种库进行封装，以适应不用的业务需要。

区分清楚，字符序列分别在编程语言中的字符串类型表示和其本身实际的字符内容。

在短暂的进入时间线修改了保留设置后，我又无法进入时间线了。

我按照上面做了，重启之后还是没有出现时间轴的入口。
但是我现在可以从 google 的时间轴提醒邮件里点进去了。

恐怕你的需求目前没有通用支持。
可以从而一窥相关技术实现
https://www.electronjs.org/docs/latest/api/browser-window#winsetcontentprotectionenable-macos-windows

Google Keep ，比滴答清单更简洁，后者还是偏重于提醒和长短笔记
尤其是 Android 上前者有 widget ，后者没有

最近两个月什么生活习惯变了，另外环境哪里变了，也不排除是这段时间里那个时间点出现噪声，比如装修

@neptuno 有几个相关概念叫 Call Hierarchy 、Call Chain 、Find Usage 之类的