谢谢！已经发邮件了

该问题不易重现，同样的笔记，在不同时期有时候卡顿，有时候不卡顿。今天同样笔记就不卡顿了。

另外一个发现是，在卡顿发生时，似乎是在拼音输入时，每输入一个字，还在拼音备选时，就发生卡顿，可以看到输入的文字，在思源里渲染时，会一步一步地逐步变成最终选择的汉字

打开开发者工具，陆续测了一段时间，重现并不是每次都可以，大多数情况如下：

1。单一笔记文件，使用无序列表，300 个列表项以上，几乎没有双链

2。层级 4 级以上

3。在每个层级录入时，每录入几个汉字时，在拼音选择时，就开始出现卡顿了，几乎在每次录入时，80% 以上概率会出现卡顿

4。上下卷动笔记时，大概 60% 以上概率会出现卡顿

5。卡顿时，观察开发者工具 network，耗时较多环节为：

transactions

getTreeStat

getBlockBreadcrumb

getDocOutline

通常，卡顿时，这几个连续动作，至少有一个会出现 300ms 以上的响应时间，大概 40% 的概率会在 800ms 以上，多时会达到 1-2s（主要是 transactions）

这些 300ms+ 的耗时高频出现，几乎每录入几个字就会出现，体验上就是几乎没法继续顺畅录入了。

好的，我试试

看到这个调整计划了，感谢 D 大还在考虑兼容 git 场景的用户，会注意关注，相关变更烦请继续告知，谢谢！

由于整个团队都在使用，目前没有升级到 2.2.0 版本，都统一在 2.1.14.

刚才的问题，在重建索引后解决，可以正常建立 daily notes 了

但行好事，莫问前程。

思源是好的开发者开发出来的好产品。

好的开发者会一直成长，好产品会一直成长，伴着好产品的用户一起成长。

成败是非是历史快照，成长是永恒的流，流不断，希望不断。

支持思源，支持 D 大 V 大团队。

在 360 杀毒的白名单里加入文件夹白名单，思源的安装和下载文件夹都列入这个白名单，以后就不会杀了

360 不止是误杀思源，也杀 remnote，包括大名鼎鼎的 SAS 都杀，所以今天忍无可忍，卸载 360，启动微软 defender。重启，世界清净了 ... ...

几点浅见：

1. 对于单一搜索关键词而言，将所有自身 Content 匹配的块（不论是容器块还是叶子块，只要这个块本身的内容（包含扩展属性）匹配搜索条件）作为搜索结果逐条显示，应该符合搜索者的直观期望，所以建议结果中保留这些容器块，可以通过图标和排序的方式（类似于文件命关键字搜索结果中的匹配文件夹和匹配文件的排列）来区隔
2. 如果除了想获得匹配搜索的节点，还想看到节点归属的各上级容器节点，建议是否可以在结果里包含”块面包屑路径“且路径上每个节点都可以直接点击查看；这样可以解决”查看包含 < 关键字 > 的容器节点“的需求，目前思源给出了结果块归属的文档路径（全路径，但每个节点不可单独点击），是否可以再给出块的面包屑 —— 例如：查询包含 CNN 内容的节点，以及包含这些节点的各层容器块，查询结果中仅列出实际包含该内容的某个块，通过这个块的面包屑路径，自然带出各容器节点，上述容器节点不会直接列在查询结果中，既压缩了结果占用的空间，又可以通过这个结果节点的面包屑直观访问
3. 对于 fangly 用户提出的复合关键字查询，且每个关键字匹配在不同层级节点的情形，这个在理解上可以类比网页搜索，查看同时包含"foo"和"bar"的内容，一个 content="foobar"的节点属于直观匹配，但是一个二级子节点包含"foo"且四级子节点包含"bar"的容器节点，是否应该符合”直观“的匹配结果呢？如果这个节点符合，那么包含这个节点的所有容器节点，乃至整个文档，以及该文档的父文档，是否也应该算符合呢？毕竟思源笔记的架构上，文档-子文档-容器块-叶子块，在使用逻辑上是无缝的；网页的搜索结果会把包含"foo"和"bar"的网页全部展示，只是按 page ranking 排序，匹配的字加亮显示。因此这样的需求，可能不同的搜索者，期望不同，用”宁可重复，也不漏掉“的原则处理似乎是恰当的。

问题解决。之前从 git pull 的时候设置的 ignore list 有问题，有些 1.2.6 的文件没复制全。现在都可以了，针对工作区仍然可以通过 git 团队分享。多谢解答。

好的，我们明天再试试

这个笔记本 ID 和用户名有绑定关系吗？

没有，也是本地打开的思源笔记帮助

我们试了，在一个空的 data 里，复制了其它电脑上的 data 目录中的笔记本目录，思源应用内不显示这个笔记本。只有在本地思源建立的笔记本，才被识别。别的电脑上只能复制子目录下的内容过来。

深以为然！

1. 文件名的纠结，我们实践里的理解是：习惯于一段内容在一个可见的文件里，然后以文件名看更新，以文件或文件夹移动或复制内容，习惯这样的话，文件名不用改成 ID，随便改动一些都会不好找；如果是以内容块来组织的话，移动，查找和复制都是块的内容（包括块的嵌套），习惯了这样，焦点就在内容里，而且是每个组织好的要点里（在 RemNote 里是一个 Rem)，这对于知识的组织管理而言，是更顺畅的。文档名，只是应用内一个大容器块的标签管理，，如果需要文件级的交换，用导出 md 后的 pandoc 类的方法，转成 ppt 也行。
2. 修改历史管理，我们也是用 git 来做的，而且是团队协作，十几个成员，从需求到设计到开发代码到测试，直到交付和销售支持材料，甚至开发者自己的学习笔记，都用思源做源头内容管理，3 个月时间我们用思源已经发布了两个产品都在 B 端客户进入部署阶段。git 管理协同，相对于飞书和语雀的在线历史管理，优势不仅在于可以管理到每个 commit 的每个要点，而且在于文档的发布范围，可以多分支管理，小组的 feature 开发的需求文档，和主版本分离，没啥问题。
3. 思源的 json 格式，是我们团队选择思源并且每人购买会员的理由，不仅 ID 和标签的对应可以管理，而且节点间的关系，完全可以还原；如果改了数据库作为主存，反倒会引起我们很大担心，且不说如何用范式化 schema 适应 nosql 的定义场景，字段映射的管理，元数据和实际内容的对应查看，引用完整性的潜在风险这些坑，光是实时分享版本改动引起的数据字段结构和值域定义更新问题，就成了一个麻烦。
4. 还是那句话，思源笔记作为知识管理工具，而不是编辑排版工具的方向，非常认同；知识图谱的 schema，就是图；比起范式化的二维表，protege 这类知识定义 rdf 工具，是和 json 这种格式具有好得多的亲和力的，而且思源支持的 graphviz，可以直接和 protege 进行转换。
5. 同样，也是期望思源尽快梳理出稳定的开发接口，sql 查询的数据库元数据和字典文档开放程度能更好一些，便于跟进；如果有一天，思源把主存储改为封闭数据库，不再坚持“本地 + 文本格式”，也希望及时告知，恕不能够继续一路升级同行了。
6. 思源用户圈子建立很难得，大家场景不同，需求各异，求同存异不容易，一方面让开发者协调取舍，一方面多交流，理解，分享一些不改版本条件下解决问题的方法吧。

谢谢！目前这个选项就够用了 👍

我也是遇到同步失败，上传到云端，提示错误信息：

同步笔记本 [L:< 本地目录名 >\04Sync] 失败：push output [Warning: Permanently added 'siyuan.b3logfile.com,8.136.157.37' (ECDSA) to the list of known hosts. auth failed rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(228) [sender=3.2.3] ], err [exit status 12]

从新手变成会员了 🎉

非常感谢