strings.split 会保留连续分隔符产生的空字符串，遍历时需手动跳过空串以防 panic；等效 python str.split() 应用 strings.fields；注意类型匹配、utf-8 安全性及 split/join 不可逆性。
strings.Split 会把空字符串切出来，小心切完遍历时 panic
Go 的 strings.Split 在分隔符连续出现或位于首尾时，会保留空字符串元素。比如 strings.Split("a,,b", ",") 返回 []string{"a", "", "b"}，不是你直觉以为的三元组过滤后结果。
常见错误是直接用 for _, s := range strings.Split(s, ",") { ... } 然后在循环里对 s 做非空判断前就调用 len(s) 或取首字符——一旦遇到空串，s[0] 就 panic。
- 需要空串过滤时，手动遍历检查：
if s == "" { continue } - 想等效 Python 的
str.split()（忽略空白+自动去空），得用strings.Fields，它按 Unicode 空白字符切且自动跳过空项 - 若分隔符是固定单字节（如逗号、冒号），
strings.Split性能优于正则；但分隔符含特殊含义（如多个可选符号），改用regexp.Split
strings.Join 要求输入是 []string，别传错类型
strings.Join 第二个参数是 string 没问题，但第一个参数必须是 []string。常见错误是传了 []byte、string 或自定义切片类型，编译直接报错：cannot use ... (type []byte) as type []string。
尤其容易踩坑的是：从 bytes.Split 拿到的是 [][]byte，不能直接喂给 strings.Join；或者误把单个 string 当成切片传进去。
立即学习“go语言免费学习笔记（深入）”；
- 转换
[][]byte→[]string：用make([]string, len(bs))+ 循环string(b) - 如果只是拼接几个已知字符串，别绕路建切片，直接用
fmt.Sprintf("%s,%s,%s", a, b, c)更轻量 -
strings.Join对空切片返回空字符串，对单元素切片直接返回该元素——这点和Split的空串行为不对称，注意逻辑一致性
Split 后再 Join 不一定还原原字符串，分隔符位置信息丢了
strings.Split(s, sep) 再 strings.Join(..., sep)，结果很可能不等于原字符串。因为 Split 无法区分“分隔符之间是空还是根本没分隔符”——例如 "a,b" 和 "a,,b" 经 Split(",", Join(",")) 都变成 "a,b"。
这在解析配置、日志字段、CSV 等场景特别危险：原始格式中的空字段语义被抹掉了。
- 需要保真还原，别用
Split/Join做 round-trip，改用strings.Index+ 手动截取，或引入encoding/csv包处理带引号/转义的字段 - 如果只是做简单标记替换（如模板填充），用
strings.ReplaceAll比先 Split 再 Join 更安全、更快 - 性能上，
Split分配新切片，Join预估总长做一次分配；频繁操作建议复用strings.Builder手动拼接
中文或 emoji 字符串用 Split 没问题，但别假设 rune 数 = 字节长度
strings.Split 是按字节切的，不是按 rune。这对 UTF-8 编码的中文、emoji 完全没问题——因为它们本身就是合法的 UTF-8 字节序列，不会被错切成半截。但如果你后续要统计“字符数”，别用 len(s)，得用 utf8.RuneCountInString(s)。
真正出问题的是：用 Split 切完，再对某个子串用 s[i] 取字节、然后当成 ASCII 处理——遇到中文就会读到乱码字节，甚至越界。
- 只要你不手动索引字节、不拿
len()当字符数用，Split处理中文和 emoji 是安全的 - 如果要按“视觉字符”（grapheme cluster）切分（比如一个带修饰符的 emoji ??），
strings包做不到，得用golang.org/x/text/unicode/norm或第三方库 - 所有标准库字符串操作函数（包括
Split、Join、Index）都只认字节，这是设计使然，不是 bug
Split 结果多出不可见的空项。 
