golang 一个很神奇的问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 438 天前的主题，其中的信息可能已经有所发展或是发生改变。

有谁能帮解释一下这是啥原因？

使用 strings.TrimLeft app- 的a哪去了？

第 1 条附言 · 2023-08-30 09:20:50 +08:00

感谢个位大佬的讲解，之前确实没注意到有 TrimPrefix 这个函数。
学习了！

第 2 条附言 · 2023-08-30 11:12:43 +08:00

别骂了别骂了，要脸

37 条回复

loveuer

2023-08-29 18:44:50 +08:00

看文档。。。

hsfzxjy

2023-08-29 18:46:28 +08:00 via Android

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

deplivesb

2023-08-29 18:49:56 +08:00

给你贴一个 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"` 的左侧被移除。

deplivesb

2023-08-29 18:53:05 +08:00

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

bruce0

2023-08-29 19:19:03 +08:00

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

jiang1234321

2023-08-29 19:20:33 +08:00

没复现，能贴一下源码吗

j0hnj

2023-08-29 19:52:34 +08:00

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

yyf1234

2023-08-29 20:17:10 +08:00 via iPhone

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

lsk569937453

2023-08-29 20:18:49 +08:00

@j0hnj 笑死。。。。

Ericcccccccc

2023-08-29 20:29:47 +08:00

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

yuk1no

2023-08-29 20:39:38 +08:00 via iPhone

RTFM

1423

2023-08-29 20:41:29 +08:00

离谱,也太水了吧

Xusually

2023-08-29 20:46:03 +08:00

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

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

zlstone

2023-08-29 20:56:00 +08:00

@j0hnj #7 哈哈哈哈

nulIptr

2023-08-29 20:56:47 +08:00

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

zlstone

2023-08-29 20:58:52 +08:00

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

Baloneo

2023-08-29 21:27:09 +08:00

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

orangie

2023-08-29 21:44:50 +08:00

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

realpg

2023-08-29 22:11:59 +08:00

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

skywalkerfc

2023-08-29 22:32:30 +08:00

[提问的智慧-在提问之前]( https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md#%E5%9C%A8%E6%8F%90%E9%97%AE%E4%B9%8B%E5%89%8D)

learningman

2023-08-29 22:51:14 +08:00 via Android

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

realpg

2023-08-29 22:52:07 +08:00

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

dyllen

2023-08-29 23:24:10 +08:00

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

dobelee

2023-08-29 23:47:06 +08:00

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

Jirajine

2023-08-30 01:40:01 +08:00 via Android

@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 。

flyqie

2023-08-30 02:49:59 +08:00

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

func TrimLeft(s, cutset string) string

是 cutset 而不是 prefix 。。。

flyqie

2023-08-30 02:52:28 +08:00

@Jirajine #27

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

iseki

2023-08-30 05:21:07 +08:00

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

westoy

2023-08-30 05:45:12 +08:00

@iseki

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

largezhou

2023-08-30 08:22:32 +08:00

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

ysz1121

2023-08-30 08:47:29 +08:00 via iPhone

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

bruce0

2023-08-30 09:04:55 +08:00

@flyqie #27

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

我觉得你这个可以提个 issue 🤣

PTLin

2023-08-30 09:09:21 +08:00

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

bruce0

2023-08-30 09:45:00 +08:00

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

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

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

iseki

2023-08-30 10:08:43 +08:00 via Android

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

flyqie

2023-08-30 11:56:53 +08:00 via Android

@bruce0 #32

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

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

cooltechbs

2023-08-30 12:04:20 +08:00 via Android

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