我相信这是有意为之，但与 append 函数本身无关。这只是关于语法的问题。例如，参见 #12105 或 #1206。
我会保持开放，以防 @griesemer 有其他补充。

这可能自gofmt的早期阶段以来就一直是这样。为了比较，各种表达式的格式化：

x = 1 * 2
x = (1 * 2)
x = f(1 * 2)
x = g(1, f(1*2))

我同意在复合字面量元素列表和参数列表之间几乎没有区别，这是一个不一致之处。
我们不清楚是否应该改变它，因为这可能会引起相当大的混乱。如果我们这样做，我们可能希望将其与一些更多的gofmt清理/改进结合起来。

相关： #11497

在赋值中连接字符串需要在 + 周围加上空格，同样地，对于只有一个参数的函数调用内部，如果有 , ,那么 + 就不能有空格。

以下是关于该问题的粗糙补丁。它可以通过一个相对任意的 "-o" 选项启用。就我个人而言，我认为 gofmt 应该有一个可配置的样式选项库，然后暴露每个预定义选项，以便它们可以被修改。例如，--style-rules +spacesAroundBinaryOps,-keepSingleLineBlocks,+somethingElse 或者甚至更全面类似 astyle 's options 的东西。试图向大众精确地说明你的代码应该如何格式化是一种不好的做法。标准和风格指南没有问题，但不允许有替代方案会显得有点专制或僵化。

我刚刚遇到了这个问题，是因为我在处理合并请求时，经理指出了代码中所有压缩在一起的+操作符。我几乎完全遵循gofmt的规定，实际上通过一些探测和查找，我发现这种不想要的压缩(我认为大多数人都会同意它不太易读)只发生在函数调用的参数列表内部，而且只有当有多个参数时才会发生。

我想逻辑是这样的：这可以更清晰地分组参数，但我认为不应该这样做。我也认为它不会像它(据我所知)那样破坏太多的代码，因为它只影响函数调用和结构化字面量(我认为也包括结构体和切片字面量)。

我正在努力说服我的经理，gofmt解决的问题比它创造的问题要多，我不认为这是一个高优先级的问题。无论如何，许多Go用户在运行linter之前使用gofmt作为准备工作，但只有linters会破坏CI/CD管道，但是，由于这是一个普遍的、尽管微不足道的变化，我可以理解为什么有人认为这是一个2.0版本的改变。但是，由于gofmt已经实现了这一点，我怀疑没有一个linter会将这种连接作为错误标记。