LastIndexOf()的意外行为？

Question

在使用LastIndexOf搜索较长字符串中的短字符串时，我遇到了一些违反直觉的行为：

如果我有干草堆和针头：

var h = "abcabcabc";
var n = "abc";

我告诉LastIndexOf开始在索引3，4搜索，我希望它开始在那里搜索，然后继续到字符串的开头，然后返回3：

012345678
abcabcabc
    abc    <- try index 4, no
   abc     <- found at index 3

..but实际上定位了第一个abc并返回0。它的行为就好像有一个假设：“用户希望开始搜索长度为3的字符串，从索引4开始；字符串不可能发生在任何高于2的索引上，所以搜索将从索引2开始.在索引0处找到”，而如果从字符串的末尾开始搜索，即长度3的指针不可能在haystack.Length-3之前找到，我认为在字符串中间采用这种方法是不符合逻辑的。

另一种看待它的方法是“草堆被减缩，这样它的长度就等于startIndex，然后搜索减缩的干草堆”--但是，我发现砍一个文档并删除一个潜在的匹配是不合理的。

虽然我可以这样推理出搜索逻辑，并试图记住它，但在我看来，以这样的方式操作似乎不合逻辑，所以我在这里问，这种行为是否有什么潜在的原因，使推理变得更容易？

注:也可以说“不，你的逻辑”从4开始，发现3点是不合理的，因为.“--这将有助于调整我认为LastIndexOf应该如何工作的心理模型

Answer 1

从文档 -上面写着

报告此实例中指定字符串的上一次出现的基于零的索引位置。搜索从指定的字符位置开始，然后返回到字符串的开头。

因此，它从值搜索到字符串开头的。不同的起点作为你的期望。

更新:马修·沃森在源代码评论中提到的

特别是对于LastIndexOf，使用“startIndex”和“count”的重载行为与其IndexOf对应的不同。'startIndex‘是执行搜索时应该考虑的最后一个char元素的索引。例如，如果startIndex = 4，则调用方指示“当找到匹配时，我希望您在索引4处包含char元素，但不包括超过该点的char元素。

var h = "abcabcabc";
//index  012345678
//          ^ last element that will be considdered "abca"
var n = "abc";
int result = h.LastIndexOf(n,3); //0