网页是富文本… ob渲染出来的样式就是网页，很显然，它没搜索html标签 
markdown的标记和html的标签是完全同性质的东西，都是标记语言的标记。==囗囗==正是被定义成<mark>囗囗</mark>的。==、*、**、> 等当然不应被搜索出来，或者至少应该存在忽略标签搜索的选择。
markdown只是一种较为简单的标记语言，一种保证了可读性的标记语言而已。即是说，它的源码看起来和（可能的）渲染结果差别不大，但它毕竟还是源码。
你能想象浏览器在执行网页检索时，不对连续的文本进行检索，却对html源码进行检索吗？那简直是灾难，会导致检索功能完全不可用。而对于markdown，仅仅是由于md的标记较少而过于简单，所以造成的后果不太明显而已，但偶尔^1还是有的。更重要的是，对源码进行带标签检索根本上不符合markdown的设计逻辑。从设计逻辑上来说，对不带语义标签的纯文本进行检索才是一个markdown查看器^2应有的基本功能，而带语义标签检索才应该是可选的、拓展的、增强的功能。^3
你能想象纯文本搜不到等号吗 我们不谈这玩意儿是否合理，从实现上来看，去除markdown标记进行搜索其实比较容易，在原有的基础上封装一层正则表达式就好了，写个插件的事。然而那么久都没有插件，可能这玩意儿并不是刚需。
是的，正如我前面提到的，md当初设计的目的就是为了让源码看起来尽量接近渲染效果嘛，所以应用偷点懒，该操作渲染结果的地方直接去操作源码，几乎也能实现差不多的效果，而不会造成太大麻烦。但总是会造成麻烦的，比如帖主。
（这几天才来玩儿Obsidian论坛，这会儿发现注释语法似乎在这儿不能用？）
这个需求小还有一个原因，前面有评论提到了。
那就是，一般搜索都是以关键词为单位搜索，很少会拿较长的词组甚至句子去搜索；而正常的标签一般不可能去隔断词语，所以把标签纳入检索，一般不会造成影响。
不过不管怎么说，以上都是对为什么在Obsidian这么设计的情况下，却没有产生要求改进的需求的解释，这和Ob的这个设计有问题是不矛盾的。
现在好像有这种了，不知道能不能此贴完结。
1 个赞
你好，你有办法让obsidian的全局搜索栏能够按照文件名匹配-文件内容匹配的顺序显示吗？比如当我搜索vscode的时候，我希望vscode_mdnotes.md这个文件排在最前面，而不是带有vscode关键词的、所谓的最近修改的文件排在最前面。
1 个赞
我因为我说的哪个搜索问题，没在使用obsidan了，，你说的这个我不知道obsidian是否支持“只在文件名中搜索”。。我现在用思源笔记，非常完美。你说的功能，可以通过选搜索类型，只勾选“文件名”，就能只搜文件名了。。强烈推荐你使用思源：开源、支持第三方同步、搜索功能强大且无问题、所及即所得（不会给你高两个窗口，一个源代码、一个预览）
我已经没在使用了，现在在使用思源笔记。但是我估计没有解决把。。空格隔开什么的，我都懒得反驳了，如果真觉得这样搜出大量无效结果，都能接受，那也没问题
实际使用中，这种情况估计比较少，只要不长句搜，搜关键词应该问题不大，多个关键词限定后，多余的结果应该比较少了。
哦哦，原帖表达的意思是搜索关键词需要用空格隔开，不是正文，主要是介绍 Ob 的搜索语法 line:() 等。思源的文档我记得不是 Markdown，而是软件自己适配的格式，同一个生态内搜索起来确实更方便吧。
就像我上面所说，空格+关键词方法，基本上能满足要求，但并不能覆盖所有场景，但，特殊情况再配合正则几乎能满足绝大多数场景。极端情况很少了。算是目前最佳实践了。毕竟很少有把关键词内部加代码的场景。本来搜索长句被匹配到的可能性就小，通常我们搜索时也只能零星的想起一些关键词。
使用 Obsidian 的用户群体主要是英文用户。英文是用空格进行分词的，所以英文用户不太可能会遇到这样的麻烦。他们输入的搜索内容其实可以看成是一个个关键词。
但这对中日韩语言来说，输入的搜索内容只会被认为是一句话，而不是一个个关键词。
我理解这样的困惑。我认为一些用户没必要过度地反对这样的抱怨。
在别的非 Markdown 笔记软件上，明明直接搜“弟弟很好”就能搜到，但在 Obsidian 上可能就要想着分为多个关键词，或者用什么特别的搜索技巧。这对普通用户来说，确确实实不够直观，需要转个弯理解。
至于解决该问题所付出的技术代价，这是开发团队自己应该要权衡的事情。
就目前各個筆記軟件的全局搜索使用下來的體驗是類似notion 那樣的模糊搜索並且智能判斷的模式是比較好用的，而且內部還提供了ai搜索，我目前還沒遇過找不到筆記的問題。
因為在很多時候我們其實忘記了想找到的那個筆記的關鍵詞是什麼，在單全局搜索這方面我認為這應該是未來的趨勢，除了提供精確搜索以外還應該提供模糊搜索的功能才是，就像我們使用搜索引擎那樣。