golang 一个很神奇的问题

看文档。。。

热知识：TrimLeft 不等于 RemovePrefix ，在任何语言都是

给你贴一个 GPT 的回答：
`strings.TrimLeft` 函数在 Go 语言（ Golang ）的标准库中用于从字符串的左侧（开头）移除一组指定的字符。这个函数接受两个字符串参数：第一个是原始字符串，第二个是包含所有需要从原始字符串左侧移除的字符的字符串。

下面是一个简单的示例：

```go
package main

import (
"fmt"
"strings"
)

func main() {
originalString := " Hello, world! "
trimmedString := strings.TrimLeft(originalString, " ")

fmt.Printf("Original: '%s'\n", originalString)
fmt.Printf("Trimmed: '%s'\n", trimmedString)
}
```

在这个例子中，`strings.TrimLeft` 函数会移除 `originalString` 左侧的所有空格字符。输出将是：

```
Original: ' Hello, world! '
Trimmed: 'Hello, world! '
```

注意，该函数并不会修改原始字符串。相反，它会返回一个新的字符串。

此外，第二个参数是一个字符集，不是一个前缀字符串。也就是说，`strings.TrimLeft` 函数会从左侧移除所有在该字符集中的字符，而不是移除一个特定的前缀。例如：

```go
result := strings.TrimLeft("123abc456", "123")
```

`result` 的值会是 `"abc456"`，因为所有在 `"123"` 字符集中的字符都会从 `"123abc456"` 的左侧被移除。

都“后端高级研发工程师” 了，我不信你不会查文档。
https://pkg.go.dev/strings#TrimLeft

你想要的 应该是 `strings.TrimPrefix()` 这个 `strings.TrimLeft()` 我以前也没注意到 看了一下文档才了解

没复现，能贴一下源码吗

文档不看，issue 倒是提的很快 https://github.com/golang/go/issues/62344

有这发帖和提 issue 的时间，但凡你点进去看看文档呢。。。无语

@j0hnj 笑死。。。。

这些函数的源码都挺短的吧.

RTFM

离谱,也太水了吧/div>

Doc 里直接写了：To remove a prefix, use TrimPrefix instead.

假如你的 authorization 是"Bearer aeerrr"的话，你会更 rz 的

@j0hnj #7 哈哈哈哈

哈哈哈这种事情我肯定会先反思反思自己的问题，而不是直接去开个 issue

这就是后端高级研发工程师吗

fmt.Println(strings.TrimLeft("Abc123-c12456", "Abc123-")) >> 456

Goland 都提示你了，第二个参数叫做 cutset ，当作字符集合，不是当作字符串。

程序员懂简单英语的重要性：
cutset

居然有人发现行为不符合预期的第一反应是怀疑标准库，也许这就是大师吧

@learningman #21
好不容易学会了 github 提 issue 总得找个地方试试

这么基础的库，用了那么多年了，怎么可能有这样低级的错误

trim 都是用字符集合吧，golang 之外也是一样的。
这么常用且实现简单的标准库函数，开局就是一个 issue 。

@dobelee #24 不一样。把 string 当做 char set ，要么是 API 设计有问题，要么是语言类型系统不足是这种设计成为常规做法。
比如 rust 里类似的函数就没有这种坑 https://doc.rust-lang.org/std/string/struct.String.html#method.trim_start_matches
它的参数类型是 Pattern ，可以是 char/&[char]/&str/fn ，而不是一个当做 char set 的 string 。

你但凡翻下函数签名。。。

func TrimLeft(s, cutset string) string

是 cutset 而不是 prefix 。。。

@Jirajine #27

这个应该不是 bug ，真要怪的话。。怪设计吧，个人觉得这个函数应该用切片比较合适，直接上个 string 的话确实可能会误导。

@dobelee 反正我的话确实只在 Go 里见到了这样的设计，以至于 Go 里所有的文本相关函数我都长了个心眼，其它语言有哪些类似的设计吗？可以举一下，确实没见过

@iseki

php 的 trim
c#的 Trim
python 的 str.strip
ruby 的 str.delete
java apache commons 的 StringUtils.strip
koltin 的 trim

trim 都是这样的，不过我们之前代码中也出现了类似的错误用法

感谢大佬们的讲解，学习了！

@flyqie #27

>这个应该不是 bug ，真要怪的话。。怪设计吧，个人觉得这个函数应该用切片比较合适，直接上个 string 的话确实可能会误导。

我觉得你这个可以提个 issue

@bruce0 op 这种人其实不少，我以前见过一个人碰到问题第一反应就是去论坛，issues 里提问，而不是自己尝试解决，甚至没人给他解决的话他就喷这个东西设计的有问题，喷这个东西垃圾。。。

@PTLin 参与过几个开源社区, 这种遇到的不多, 大多数人还是挺友好的, 如果帮助他们解决了问题, 一般都会感谢, 没解决也不会抱怨, 毕竟大多数社区都是用爱发电的.

上上周吧, 我在用 redis 的时候, 发现 acl 的 rule 重写有点问题, 全网 acl 相关的文章太少了(不论中文还是英文) 官方文档也没有 相关的解答, 我就去 redis 社区, 提了一个 issue

先把我遇到的问题,redis 版本, 复现路径 描述了一下, 然后说了我预期的结果, 就怕不是 bug 闹了乌龙, 丢人丢到国外去, 社区的那个大佬 回复挺快的, 第二天就回复 是个 bug, 晚上顺手就给修了

@westoy kt 的 trim 那是个 predict ，jac 的那个确实是个 string

@bruce0 #32

哈哈哈，issue 提了也没啥用啊，标准库都已经这样了提 issue 也改变不了设计啊，不然兼容性直接打破了。

我唯一能想到的不用切片的理由就是。。字符串可能性能比较好容易做 cache ？但好像标准库也没 cache 啊。。

楼主写 Go 多久了？ Go 相比 C++、Java 之类的语言，一大好处就是标准库代码都摆在明面上（安装就有），也含有和官网一样的文档，查阅非常方便。RTFSC 对于 Go 开发者应该不是玩笑，是日常。