服务起不来时，我排查端口、进程、配置的顺序
服务启动失败这件事，最怕的不是问题复杂，而是人一慌就到处乱看。2016 年自己管机器的时候，我也吃过这种亏：一发现接口没起来，就先怀疑代码、怀疑框架、怀疑依赖版本，结果折腾了半天，最后只是端口被别的旧进程占着。
从那以后，我给自己定了一条顺序。只要服务起不来，我就按一个固定路径查，不让注意力到处飘。
第一步：先看端口是不是已经被占了
这一层最值得先查，因为它便宜、直接，而且能快速排除大量误判。
如果目标端口已经被占用，新的服务自然绑不上去；如果端口空着，也能说明问题大概率还没走到真正 listen 的那一步。
这一层查清楚以后，心里会立刻少一半噪音。
很多“服务没起来”的描述，其实并不精确。准确一点说，可能是：
- 进程根本没启动
- 进程起来了，但没监听目标端口
- 端口监听了，但反向代理没转过去
先分清这三种状态，比直接翻业务日志更有效率。
第二步：再看进程到底有没有活着
端口没占，不代表程序没问题；有时候进程刚启动就崩了，只是退出得太快。
这时候我会特别关注两个问题：
- 进程是没启动，还是启动后马上退出
- 退出是因为权限、路径、环境变量，还是运行时异常
如果连进程的生死状态都还没确认，就开始看业务逻辑，通常会把问题越看越偏。
第三步：配置文件和运行环境要单独看
这一步我后来越来越重视。因为很多线上问题根本不是代码错，而是配置指向错了环境：
- 连接了错误的数据库
- 读了旧版配置文件
- 端口号改了，但 Nginx 还指向老地址
- 日志路径不存在，启动流程被卡住
这些问题有个共同点：看代码时完全看不出来，只有把“程序运行时到底拿到了什么配置”单独拎出来看，才会现形。
最后才轮到代码本身
不是说代码问题不重要，而是它不应该成为第一怀疑对象。
如果端口正常、进程稳定、配置正确，这时再去看异常栈、框架版本和业务逻辑，思路会清晰得多。
我后来处理线上启动故障时，反而不喜欢一上来就打开 IDE。先用系统视角确认服务有没有真正跑起来，常常能节省大量时间。
这一套顺序为什么有效
因为它把“猜问题”变成了“缩范围”。
- 端口这一层在确认入口是否被占
- 进程这一层在确认程序是否存活
- 配置这一层在确认运行上下文是否正确
- 代码这一层才是最终实现逻辑
一层一层往下排，信息是收敛的；反过来东看一眼西看一眼，只会不断制造新的假设。
小结
服务起不来时，情绪很容易先冲上来，但排障最怕情绪驱动。那几年把机器和服务都自己盯着之后，我反而越来越相信简单顺序的力量。先端口，后进程，再配置，最后代码。它不高级，却能让很多线上问题更快落地。