阿白笔记

感谢，这个方法成功了。

专门比较了 16 和 17 的文件结构，看起来是一样的。不知道为什么，以前的版本我的 TC 可以自己自动展开到 app-64.7z 内部，从 17 开始就不行了。

+1，当前文件搜索还弹窗，体验实在过于割裂了。

每次发新版之后，都删掉旧版解压出来的文件，把新版重新解压出来用就好。

现在就是绿色版，直接把扩展名从 exe 改成 zip，之后解压，把里面一堆文件拷贝出来就行，我一直都是这么用。比如截图是 2.12.8 解压的文件（我用 total commaner，不知道哪个插件生效了改名后打开就这样，用一般的解压软件文件结构可能会不同，在某个文件夹里面，打开应该是这样的）：

我记得思源并不推荐使用 webdav，有丢失或损坏数据的风险。

我在 chatgpt 的帮助下写了一个类似的脚本

我记得思源早期版本的同步和历史版本比对用的是 git，后来逐渐改成现在这样了。

肝 D 的名头可不是虚的

老哥你讲的话里虽然我认识绝大多数字，但是看不懂你的意思。

安排生二胎，你这到底是奖励还是处罚很难说啊。

+1

要是要求各种复杂的字体字号颜色等格式设置是有点太重了，但其实换行是个很基本的需求。

+1

实话说，我无所谓

奇怪。那有可能是因为我把操作系统从 win11 换成 win10，系统占用 cpu 明显降低了。
但我在 win10 下用 274 也没感觉到便流畅。很奇怪。

感觉 276 的搜索速度比 274 有很大提升，同一个工作空间，我依旧设置搜索结果显示数量是 3200，ctrl+p 显示结果的速度显著快于以前的版本，是 276 在这方面做了改进吗？

笔记本电脑型号和配置咋样？虽说我的破笔记本也觉得卡，但没到需要开两次的程序。

用 listary，wox 之类的现有工具不行吗？为什么要自己开发一个新的呢？

我能理解你限制命中条数的思路了。确实是，可以通过优化关键词和添加其他限制条件来提高命中结果的精确程度，但是目前存在两个问题：

1、目前的搜索 ui 不够完善，想达到以上目的只能使用 sql，这个门槛太高了。我日常使用的一些商业化网站（用于搜索法规或者搜索上市公司公告，都是各类纯文本内容），几乎都能做到分别针对标题、内容、发文单位、所在板块、发文时间等多个主题设置不同的关键词，且允许设置多个关键词之间的且和或的关系，还允许设置多个关键词之间是在同句、同段或同篇文字出现，以及明确排除某些关键词（即制定不包含某些关键词）。做的好的，甚至能够就特定事项列出专门的搜索框（例如某事项是否审核通过，因为这类事项不是类似发文单位这种文件中现成且固定出现的内容，通过简单的搜索关键词很难保证结果全面，网站应该是做了专门的工作，感觉属于语义分析范畴）。而思源目前的搜索离我举的例子还有很大差距。

2、即使做到以上程度（或者用 sql），在我的使用场景中，如果程序存在对命中条数的限制，因为没办法准确记得自己想要找到的完整内容，依旧会有搜不到特定内容的可能（我无法判断是我的搜索条件设置不准确导致搜不到，还是我的笔记不包含相关内容，或者是被程序的命中条数限制了所以不显示）。因此，最终还是需要通过比较简单的关键词来显示一个比较大范围的命中结果（确保包含了我目前笔记中的全部相关内容）之后进行肉眼筛选。所以，前段时间上线的分组功能很重要，即使命中结果很多，我也可以依据法规名称快速排除我不需要的项目（这种判断依靠的是我对该法规所覆盖内容的记忆，感觉很难简单的通过各种关键词设置来实现相同的目的）。

所以，在我的使用场景中，优化搜索功能很重要（完善 ui，优化性能），希望 D 大考虑一下，是不是把相关优化工作的优先级提升一下 🙏

我把思源笔记当做一个法规库来用，目前管理了大概 400 多份法规原文以及差不多体量的我自己整理的笔记，因为有些细节规定很难靠大脑准确记住，工作中有需求的话我都随时用思源来搜索，类似一个本地版的“北大法宝”。所以，搜索结果的完整性对我很重要，我担心那个变量设置太小的话，即使我本地已经有相应的法规，但搜索的时候还是找不到它，所以就随手设置了一个比较大的值，其实到底是 2000 还是 3000，就我目前的数据库来说，应该都不影响结果的完整性。

所以我其实不太能理解设置这个限制的意义（性能影响除外），如果搜索到的结果是不完整的，那笔记的价值不就大打折扣了吗？搜不到的笔记和没有这条笔记感觉没区别。

我没有导入新的工作空间（还在上班），仅仅是把搜索条目限制还原到 64（原先是 3200），感觉速度有明显改善。

这个设置应该是影响因素之一。

但是为了确保搜索结果没有遗漏，我还是不愿意把这个参数调的太小，不知道是不是还有其他的改进思路？

我虚拟引用一直是开的，跟楼主的感受也差不多，就最近两三个版本开始明显变慢了。前面的版本都还好。我的比计数据量比较大（纯文本 52MB），不知道是否跟这个有关系。

systemlog.zip

已提供日志。

刚才又仔细观察了一下，我所说的搜索时间长是指从输入完整的关键词到 ctrl+p 界面完整显示内容需要比较长的时间，中间大部分时间页面是空白的转圈状态，所以，不一定是搜索效率低，也可能是显示内容需要的时间长。

同感，感觉目前的搜索时长已经接近无法忍耐的边缘了。

我也有类似的需求，目前用类似 markdown 的 front matters（好像是叫这个名字吧）的方式来标记（似乎是 yaml？就是在文件开头两行---之间夹着 tag:xx 之类的内容）主要用途是给文章打标签和做分类，方便批量导出程 markdown 文件，之后能够无缝被 hugo、hexo 之类的博客系统自动识别。

但是思源目前缺乏 front matters 信息的管理，如果能支持就更好了。

我觉得目前的分组展示样式还不错，没必要搞得更复杂了。

搜索这个确实希望早点改进。目前的实在不够用。

D 大考虑做一下软件版本和数据版本匹配性检查吧，不匹配时不能打开软件，或者强制提醒用于本地备份。这样至少安全很多。

@88250

改成左中右三栏后还有一个明显的好处，页面标签所处宽度永远等于编辑区宽度，视觉上更加整齐一致。

+1，个人也觉得对于宽屏笔记本，左中右三栏布局比上中下三栏布局更合适。