# 意外的搜索行为：当'commands'找不到'/commands' **URL:** \ **Category:** Bug\ **Tags:** search\ **Created:** [2024年七月6日 04:27 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217 "2024-07-06T04:27:02Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年七月6日 04:27 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/1 "2024-07-06T04:27:02Z")
我在文档中记录了用反引号代码格式设置的 `/commands`。但是，如果我搜索“commands”，则没有结果。搜索必须是 `/commands` 才能显示该主题。 这是故意的行为吗？我不希望用户在命令前加上斜杠来搜索特定命令 - 两种方式都应该找到该主题。 编辑；代码格式化无关紧要，因为仅“/commands”就会出现相同的问题。 编辑 2；在这种情况下，我无法用例如“.command”重现此问题，搜索“command”会得到预期的结果。 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年八月12日 07:19 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/2 "2024-08-12T07:19:27Z")
希望的顶帖。😄 ---
**Author:** ![j.jaffeux](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/j.jaffeux/32/60297_2.png) [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)\ **Post date:** [2024年八月12日 21:09 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/3 "2024-08-12T21:09:18Z")
当我搜索 `/commands` 时，我没有重现此问题： ![Screenshot 2024-08-12 at 23.08.55](https://global.discourse-cdn.com/meta/original/4X/c/6/2/c62d36ef64cf9b9064117ca767e5d3b383093c69.png) 我们只是未能找到 `commands`，我们可以争论它应该找到，但这本身并不是一个错误。 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年八月12日 21:10 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/4 "2024-08-12T21:10:01Z")
我查找了与“搜索”相关的设置，但没有找到任何明显的内容。有什么线索该找什么吗？ ---
**Author:** ![j.jaffeux](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/j.jaffeux/32/60297_2.png) [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)\ **Post date:** [2024年八月12日 21:10 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/5 "2024-08-12T21:10:37Z")
不，我认为这种行为是符合预期的 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年八月12日 21:17 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/6 "2024-08-12T21:17:14Z")
> [@j.jaffeux](#): > > 我们只是未能找到 `commands`，我们可以争论它应该能找到，但这本身并不是一个错误。 对了，我不希望我的用户预先知道他们需要包含“/”才能找到它。这种行为是否符合预期，或者是否有可能的解决方法？因为它严重影响了我文档的可搜索性。 ---
**Author:** ![j.jaffeux](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/j.jaffeux/32/60297_2.png) [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)\ **Post date:** [2024年八月12日 21:30 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/7 "2024-08-12T21:30:02Z")
搜索是一件复杂的事情 🙂 你希望搜索到这个内容，但如果你还有其他包含“commands”的文档，而你又不想在这种情况下面显示包含“/commands”的文档呢？ 你可以使用一个技巧，在你的帖子中加入关键词： `Keywords: commands` ![Screenshot 2024-08-12 at 23.31.40](https://global.discourse-cdn.com/meta/original/4X/f/3/1/f319a48db3e58b27f4b0d9f533072215af13c588.png) ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年八月12日 21:40 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/8 "2024-08-12T21:40:10Z")
我确实同意这很复杂！虽然 `/commands` 是一个例子，但我可能记录了 100 多个命令。因此，虽然使用关键字可能是一种替代方案，但它并不理想。 > [@j.jaffeux](#): > > 还有其他包含“commands”的不同文档，而您不希望包含“/commands”的文档在这种情况下显示，对吗？ 如果某个词在某处找到，它就应该出现在搜索结果中，这是我的理解。例如： /testcommand \> query: testcommand \> 🚫 betacommand! \> query: betacommand \> ✅ !betacommand \> query: betacommand \> ✅ 这里的 `/` 和 `!` 有什么区别？ ---
**Author:** ![j.jaffeux](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/j.jaffeux/32/60297_2.png) [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)\ **Post date:** [2024年八月12日 21:49 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/9 "2024-08-12T21:49:09Z")
这是由于我们索引数据的方式： “test /command” → “‘/command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B” “test !command” → “‘command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B” 请注意，在第二种情况下我们丢失了 `!`。我们决定不保留 `!`，我怀疑标点符号在搜索中不被视为相关字符。 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年八月12日 22:00 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/10 "2024-08-12T22:00:12Z")
我明白了，依我看 `/` 也不应该相关？不确定索引是如何工作的，但一个更改此设置的选项将对我大有帮助。 我注意到“somequery”作为 URL 的一部分会返回结果 `https://domain.com/somequery-article-today`，如果此 URL 在论坛的某个位置。这是预期行为——我不知道它们的相关性如何，但觉得在这种情况下 `/` 不相关很有趣。 在深入研究了一下之后，我注意到的另一件事是：我们有一个用斜杠分隔的字符串：query1/query2。 `query1` 返回一个结果，`query2` 不返回任何结果，您认为这也是预期行为吗？因为在我看来，这更像是一个错误。🤔 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年十月20日 04:03 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/11 "2024-10-20T04:03:58Z")
我还在讨论这个问题，因为我仍然认为它对搜索影响很大……我最近遇到的一些烦恼： Github 链接 \> 用户名或仓库名称都无法搜索…… X 链接 \> 用户名无法搜索 还有很多其他例子，如果你不经常依赖搜索，这些事情可能不会被注意到，因为它实际上不影响你在搜索中看到的内容，而是影响你没有看到的内容。我们不应该一直考虑一个主题是否需要关键词才能找到。 这一点 **尤其** 适用于草稿/员工部分，这些帖子根本没有完成，有时会停留数年，或者沟通以较短/内部格式进行。_如果没有添加这些……，我将无法通过关键词“员工”和“内部”找到此帖子，因为 Discourse 决定它们不相关？为什么？_ 我很难同意这不是一个 bug，而是一个搜索索引决策非常不寻常的方法。 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2024年十二月29日 10:27 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/12 "2024-12-29T10:27:55Z")
我今天做的一些测试似乎表明这可能已经修复了？不确定是否是故意的，但还是谢谢！ 编辑；算了……行为还是一样。 ☹ ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2025年二月6日 04:10 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/13 "2025-02-06T04:10:13Z")
> [@MarcP](#): > > 我很难同意这不算是一个 bug，这更像是一种非常不常见的搜索索引决策方法。 请注意，这实际上是 postgres sql 词干提取器/分词器的工作方式，我们对像 url 这样的边缘情况有一些变通方法，因为这可能会令人困惑，但总的来说，我们把很多这类工作外包给了 pg。 有趣的是，几年前我们有一个用于“在 URL 中进行额外索引”的 hack，但后来被 @tgxworld 由于索引膨胀而删除了。 我想说的是，是的，我们正在考虑搜索中的这类边缘情况，但要让我们推动围绕 pg fulltext 的现有框架进行大量修改，这需要付出很多努力。 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2025年二月6日 08:58 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/14 "2025-02-06T08:58:39Z")
我感谢你的回复，Sam！ 我明白这是一项复杂的技术，希望你们能找到一个好的解决方法——在此期间，我已经适应并尝试使用隐藏的关键词和创造性的方法来绕过这个限制！ ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2025年二月6日 09:22 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/15 "2025-02-06T09:22:52Z")
我认为将隐藏的关键词作为第一类公民是很有趣的 ---
**Author:** ![MarcP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/marcp/32/160184_2.png) [@MarcP](https://meta.discourse.org/u/MarcP)\ **Post date:** [2025年二月6日 09:27 UTC](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/16 "2025-02-06T09:27:48Z")
在本次讨论中已建议过；[Unexpected Search Behavior: When 'commands' Doesn't Find '/commands' - #7 by j.jaffeux](https://meta.discourse.org/t/unexpected-search-behavior-when-commands-doesnt-find-commands/315217/7?u=marcp)