很多人从 C、Java 转到 Go 时，第一次遇到 a++ 不能参与赋值、条件判断，往往会觉得“不顺手”。但这并不是语法上的随意取舍，而是 Go 有意用更少的写法换更清晰的代码路径。下面就从常见困惑出发，看看 Go 为什么坚持把 ++ 和 -- 设计成语句，以及这种限制到底解决了什么问题。
从类 C 语言里的经典困惑说起
如果你写过 C 或 Java，大概率见过这类代码：
int a = 1;
int b = a++; // b是多少？a又是多少？再进一步，还可能出现这样的写法：
int c = a++ + ++a; // 这又是什么结果？这类代码的“问题”不在于能不能写，而在于它把修改变量和参与计算揉在了一起。读代码的人必须同时判断运算优先级、求值顺序，以及自增发生在表达式前还是后。语法越灵活，越容易制造理解成本，甚至埋下不容易定位的问题。
也正因为如此，类似表达式常常会变成面试中的“陷阱题”。它测试的并不是业务能力，而是你是否记得某种语言细碎而容易混淆的规则。
Go 中 `++/--` 的规则到底是什么
Go 对这个问题的处理很直接：++ 和 -- 只能作为独立语句出现，不能嵌进表达式里使用。
正确写法如下：
a := 1
a++ // 正确：独立语句
fmt.Println(a) // 输出：2
// 以下写法在Go中都是错误的：
// b := a++ // 错误：不能用于赋值
// ++a // 错误：没有前缀形式
// if a++ > 0 { // 错误：不能用于表达式按规则拆开看，Go 主要做了两层限制：
- 没有前缀形式：只支持
a++、a--，不支持++a、--a - 不能作为表达式组成部分：不能拿去赋值，不能放进条件判断，也不能和其他运算混在同一表达式里
这意味着在 Go 中，a++ 的语义非常单纯：就是把 a 增加 1，然后这一行结束。它不返回值，也不承担额外计算职责。
Go 为什么要故意这样设计
可读性优先，先让代码容易被看懂
Go 的设计哲学一直偏向“少一点技巧，多一点明确”。当 ++ 不再参与复杂表达式时，阅读者就不必停下来分析这一步到底是先取值、后自增，还是先自增、后参与比较。
换句话说，Go 并不是在削弱能力，而是在限制那些会增加理解负担的写法。代码能被团队成员快速读懂，比单行里塞进更多动作更重要。
直接避开求值顺序带来的歧义
像 b = a++ + ++a 这样的写法，在很多语言里之所以让人头疼，就是因为它同时依赖变量变化和表达式求值。只要顺序稍微复杂一点，就容易引发误判，严重时还会带来隐藏 bug。
Go 的做法不是补更多规则，而是干脆取消这类组合方式。你不能这么写，问题也就不会进入代码库。
让团队风格更一致
在允许前缀、后缀、嵌套表达式多种混用的语言里，不同开发者往往会形成不同习惯。有人偏爱短小写法，有人强调显式拆分，最后同一个项目里就会出现风格分裂。
Go 一向倾向于缩小“可选项”的范围。选择少，不代表能力弱，反而意味着团队更容易形成统一写法，代码评审和维护成本也更低。
实际开发里怎么写更符合 Go 的思路
很多人担心，既然 ++ 不能做表达式，那是不是会影响日常开发效率。实际上，Go 保留的正是最常见、最实用的那部分场景。
例如下面这些写法，在 Go 里都完全成立：
// 循环中的典型用法
for i := 0; i < 10; i++ {
// 循环体
}
// 计数器增量
count++也就是说，循环变量递增、计数器累加这类高频操作并没有受影响。被拿掉的，主要是“顺手但不够清楚”的混合表达式写法。
如果你原本想写成一行完成多件事，Go 更鼓励拆成多行：
a++
b := a表面上看，代码行数变多了一点；但从维护角度看，每一行只承担一个动作，语义反而更清晰。出了问题，也更容易定位到底是哪一步造成了结果变化。
这不是功能缺失，而是明确的工程取舍
Go 把 ++ 和 -- 定义为语句而不是表达式，并不是因为语言“不完整”，而是因为它更重视代码的可读性、确定性和可维护性。
从这个角度看，Go 的思路其实很一致：宁可牺牲一部分语法上的灵活度，也要减少歧义、降低误读概率，让团队协作时的代码更容易达成共识。对于工程实践来说，这种取舍通常比“什么都能写”更有价值。
