fmt.Printf或fmt.Sprintf写拼装字符串业务 在日常开发 Go 工程中，我们经常会用fmt.Printf或fmt.Sprintf去写类似的拼装字符串的业务。 如下代码： 1 fmt.Printf(Hello Gopher %s, you are %d years old and your
fmt.Printf 或 fmt.Sprintf 写拼装字符串业务在日常开发 Go 工程中，我们经常会用 fmt.Printf 或 fmt.Sprintf 去写类似的拼装字符串的业务。 如下代码：
这业务迭代迭代着，日积月累的，有一部分常变的拼装逻辑会来越长。小小的电脑显示屏已经不足以让代码在一行内显示了。 有许多特性会把字符串转为变量，但后面那串又臭又长的变量依然无法简单甩掉，因此有大部分同学会选择把代码格式化了。 如下代码：
你可能以为这是个例？实际并不，很多人都遇到了。 简单字符串插值这在 Go issues 中社区讨论了三四年了，@Ian Lance Taylor 发起了新提案《proposal: spec: add simple string interpolation similar to Swift》。 希望能够得到更多的讨论，增加新特性解决这个问题。 这个新特性，类似于 Swift 中的字符串插值的简单版本。我们直接看例子：
对应的输出结果： Ken Thompson is 79 years old The time is 2023-01-04 16:22:01.204034106 -0800 PST 提案计划新增的 “字符串插值”，规范如下：
上面的例子中，以下几个都是字符串插值：
会有同学疑惑像 person 看起来就是结构体的是怎么取值的？ Go 有一个神奇的约定方法，像结构体这类类型，如果有 String() string 方法，将会调用该方法以获取字符串值。 如果没有 String 方法，需要是字符串、整数、浮点数、复数、常量或布尔值等类型，可以取值后格式化。否则将会报错。 其他语言例子Swift
Kotlin
C
Rust
争论矛盾点当前的主要争论点之一，像是 fmt.Sprintf 等方法也可以完成字符串插值一模一样的效果，为什么还要新增这个功能特性（或是语法糖）？ 主流观点是现有的格式化字符串的方法，在参数数量多了后，很容易出错（例如：顺序搞错），也比较松散，一大坨代码。 在新增字符串插值的特性/语法糖后，可以更好阅读、更好修改，不需要过于依赖编写变量的顺序、更紧凑。 具体的例子如下，现有版本代码：
应用新特性后会变成：
总结其实我们在工作中都经常遇到这个问题，甚至在 issues 中有同学反馈，他经常要写 50 个以上参数的格式化参数，在 Go 这维护起来比较痛苦。 如果你是长期维护某几个项目的开发者，不断持续新增、变更的现有格式化字符串的方法，和新增的字符串插值。 在接下来的几年中，你会选择哪一个？或是有没有新的想法？ |
2022-04-28
2022-04-21
2022-05-13
2022-08-17
2022-02-25
