年轻时候挑语言看谁酷，特性多、语法花哨才带劲，写得越炫越有面子。等真开始带人、扛交付，才懂最让人安心的反而是那种不跟你较劲的。我现在离不开Go，理由特别务实。
go fmt是第一件治愈的事。早些年团队里为了缩进、括号换不换行能吵一下午，review一半精力花在挑格式上。Go一句话把这场架摁死了，想争都没缝儿钻。风格统一靠工具而不是靠自觉，这才是成年人该有的解法。
编译快到经常怀疑自己没保存就跑过去了。部署更省心，丢一个静态二进制出去就能跑，不用背着一包依赖，服务器上也不用先烧香拜佛配环境。被甲方改过四十七稿的人，最珍惜的就是"能跑、别出幺蛾子"。
报错也实在，像老朋友拍你肩说"你这儿写岔了"，新手自己就能看明白哪崩了，不用层层扒栈猜谜。
语言没高低，合不合脚自己知道。我现在图的就一个词：省心。
error那段得补一刀：Go默认error不带调用栈，线上崩了你只知崩了不知从哪崩，得自己fmt.Errorf(“%w”)包一层，"老朋友拍肩"才成立。静态二进制那条我深有同感，我以前996最怕的就是部署现场烧香拜佛。
我年轻时候也为了代码风格跟人较过劲，那会儿觉得谁先松口谁就丢了面子。后来想想，那种架本来就不该靠自觉去解，交给工具摁死最干净。其实不过省心归省心，该下场拼的时候还是得下场，老缩在舒服的地方待着，人容易把那股往上走的劲头也搁凉了。
丢个二进制就跑 这踏实感 被甲方改怕过的人都懂
到了咱们这个年纪，越来越觉得"不跟你较劲"比"写得漂亮"要紧。你讲go fmt把格式架吵一锅端那段，我读着直乐。会好的人和人之间多少闲气，其实是靠把退路堵死才消停的，规矩替人做主，反而大家都落个轻松。
读到你说的「合不合脚自己知道」，忽然觉得这哪只是选语言的事。人到了某个岁数，好像都会悄悄从「想要被看见」转到「想要省点心」。年轻时总觉得平淡是种无能，后来才慢慢懂，那种不跟你较劲、不出幺蛾子的安稳，其实是种很厚的善意。
go fmt 那段尤其戳我。多少团队把脾气耗在缩进和换行上，仿佛格式之争里也藏着尊严。一把工具把这种虚火摁下去，反倒人人都松了口气。省下的哪里是那点排版功夫，是人和人之间不必再为无意义的事彼此较真。话说回来
说实话
你现在图的这份省心，我倒觉得比年轻时追过的那些酷要难得得多。
go fmt 把那场格式架摁死真解压，少内耗多干事才对路，稳！卧槽我现在就图个利落，能跑别出幺蛾子就完事。
你这"风格统一靠工具不靠自觉"一句，我大体赞成，不过用在go fmt身上，范围其实比你想的窄些。
go fmt统一的是缩进、括号换行、字段对齐、import分组这类纯机械的东西。它管不到的至少有三块：一是命名约定，比如首字母缩写ID该大写还是小写、包名用不用缩写；二是代码结构，一个包拆几个文件、方法的接收者用单字母还是全拼；三是错误处理与注释习惯，error要不要wrap、公共函数注不注文档。而这三块，恰恰是一段代码过review时最容易被挑、也最耗口舌的地方。
现成的证据：Google的Effective Go、Uber那份公开的Go Style Guide，细到上百条，没有一条是go fmt能替你定的。换句话说，fmt把最低成本、最没意义的架吵摁死了，这是大功一件；可是团队真要"不较劲"，还得在fmt之上再立一层成文约定，靠一次次review把默契磨出来。工具消的是表层摩擦，深层共识终究得人去建。
所以"省心"我信，但想把它拆开说：fmt给的是下限的省心，真正的安心，来自你们把那些fmt管不着的事也谈拢了。你们组现在除fmt外还立了别的硬规矩没？
go fmt那条太顶了，省下吵架的功夫我都够泡壶茶眯一觉了
看着你从比谁特性酷到现在图个省心，这弯转得挺自然。不过说go fmt把格式之争彻底摁死了，我有点保留。缩进统一了，评审里的"审美官司"换个战场接着打，命名和抽象层级照样能让人吵一下午。
go fmt那一段太有同感了，以前为了缩进能较劲半天，现在这种不用吵的格式统一真省心。
以前混过一阵子团队的人，大抵都见过为了代码风格拍桌子的场面。我那会儿组里为了花括号放哪一行能争一下午，现在回头想想，那点精神头干点啥不好。所以看到 go fmt 那股"没得商量"的劲儿，心里是真松快，省掉的无谓口舌比想象中多。
不过"省心"这词轻巧，真到要跟性能、跟底层死磕的时候，省心跟够用到底是两码事。Go 是好，但也不是什么活都合脚的鞋。我这人脾气简单：工具是伺候人的，别叫它拿捏住。你图它省心，它就算值回票价；哪天活儿变了，需要再往前够一够，换一双也不丢人。
合不合脚自己知道。我这双老脚踩过不少坑，如今也就图个踏实。
go fmt真把最无聊的架给摁死了，我们以前为空格还是tab能吵一下午，现在回想纯属浪费生命
你提到 go fmt 把缩进和换行的架给摁死了，这点我基本同意，但顺着"风格统一靠工具而不是靠自觉，这才是成年人该有的解法"这句话，我想补一刀：gofmt 解决的其实只是 formatting 里最小公约数那部分。
具体的——gofmt 只保证 AST 层面的规范格式，它不替你决定要不要开 golangci-lint、要不要强制 error wrapping、prod 路径里能不能写 panic。这些规则一旦写进 .golangci.yml，反而成了新战场。我见过好几个团队，当年为 tabs 还是 spaces 吵一下午，现在改成为 cyclomatic complexity 阈值设 10 还是 15 吵一下午，本质没变，只是把吵架的地方从代码挪到了配置文件。
再说个 gofmt 的真盲区：它不负责折行。一行写超了，gofmt 没法智能断就直接留着，200 字符的函数签名它也不会替你拆。真要做到"零格式争议"，往往还得配 goimports 甚至自定义 formatter，那套工具链本身又得团队达成共识。
其实
所以"靠工具而不是靠自觉"这话只对了一半。工具把最没营养的架摁死了，省下的精力确实挪到了更高层——但只要是多人协作，自觉和协商就永远省不掉，只是换了个更值钱的议题。
你那句"被甲方改过四十七稿的人最珍惜能跑"我深有同感，既然说到部署省心，有个坑顺带提一句：默认开 CGO 的时候，二进制还是动态链 glibc 的，真要纯静态得显式 CGO_ENABLED=0 或者 -extldflags “-static”，不然丢到 Alpine/musl 环境照样给你蹦 libc 找不到的错。静态二进制的"温柔"是有前提的。
你们组现在 gofmt 之外还跑哪套 lint？我好奇实际落地时争论最多的是哪条规则。
关于静态二进制这点，补一个容易踩的坑。纯 Go 代码确实能编出单个不依赖外部库的二进制，部署省心是实打实的。但只要引入了 CGO（比如为了用 SQLite、某些加密库），默认就会动态链接 glibc，最后那文件丢到缺对应版本 libc 的机器上照样起不来。所以"丢一个二进制出去就能跑"得加个前提：没开 CGO，或者显式用 CGO_ENABLED=0 编译，且目标架构对得上。
我前阵子有个服务就栽在这，本地编完丢到老版本 centos，直接起不来，查了半天才回过味来是 CGO 惹的祸。后来 CI 里统一加 CGO_ENABLED=0 才算踏实。
想图省心，这块还是值得在团队约定死的，不然哪天还是得在服务器前烧香（笑）。