一个人部署 Go 服务，最省心的方式
我现在的做法是：编译出一个二进制文件，用脚本推上去，重启进程。没有编排文件，没有容器，没有额外的控制面。一个人部署 Go 服务最省心的方式，就是把部署动作压缩成一条命令加一次重启。
口径先摆清楚，这套适合单机、单服务、不能忍受长时间中断的项目，也就是我这种一人公司的项目。
前提：一个人部署 Go 服务最省心，先确认你不需要的东西
不需要容器编排，不需要多机调度，也不需要复杂的发布系统。
判断标准是你有几个服务、多久部署一次。只有一个服务、一周部署几次的时候，上面那些东西带来的维护成本会大于收益。
上了用不上的东西，后面每次排查都要多走一层。
第一步：把配置从代码里拿出来
编译前先确认配置不是写死在代码里的。
我这边的做法是配置全部走环境变量，由部署脚本注入。这样同一个二进制能在本地和线上跑，不用为不同环境编译不同的包。
动作：检查一遍代码里有没有硬编码的地址或路径，有就挪出去。
第二步：交叉编译出目标平台的文件
在本地按目标平台编译，得到一个不依赖运行时的可执行文件。
这是 Go 省心的地方：目标机器上不需要装语言运行时，把文件放上去就能跑。少一层依赖就少一类故障。
动作：固定一条编译命令写进脚本，别每次靠记忆敲。
第三步：先传文件，再重启
顺序很重要。先把新文件传到目标位置，确认传完了，再重启进程。
如果先停再传，中间就有了一段服务不可用的时间，传文件慢了这段时间还会拉长。先传后切，用户几乎感觉不到。
动作：脚本里明确写成两步，别合并。
第四步：准备好回滚路径
发布脚本里必须留着上一个版本。
出问题时最怕的是「新版本有问题，旧版本已经被覆盖了」。保留上一份文件，回滚就是再切一次，几十秒的事。
动作：每次发布前把当前版本另存一份，脚本里写死这个动作。
同时让进程自己扛住退出。收到退出信号时，要先把正在处理的请求做完再退出。
不做这件事的表现是：每次发布，都有一小批用户请求失败。一人项目里这种小范围报错很难被发现，但会一直存在。接住退出信号，停止接收新请求，处理完在途请求再退出。
容易卡住的三个点
第一个是文件传上去了但没生效。检查进程有没有真的重启，别只看文件时间。
第二个是重启后起不来。多半是配置缺项，所以启动时要做一次校验，缺关键项直接退出，别带着半份配置跑。
第三个是回滚时发现旧文件没了。这是发布前没留备份，属于流程问题，不是技术问题。
一个人部署 Go 服务最省心的地方在于，整套流程你能背下来。背不下来就说明它太复杂了，该减。
常见问题
Q：一个人部署 Go 服务最省心的方式是什么？
A：本地交叉编译出二进制文件，脚本上传后再重启进程，并保留上一个版本用于回滚。单机单服务场景下这套最轻。
Q：为什么不直接用容器部署？
A：服务少、部署频率不高时，容器的首次搭建和日常排查成本会超过它带来的好处，等环境问题反复出现再引入也不迟。
Q：部署时怎么做到用户几乎无感？
A：先传文件再切进程，并让进程在退出前把在途请求处理完。这两件事做好，发布期间的失败请求会明显减少。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」