软件开发上线后常见bug排查清单：90%的问题都出在这几个地方

上线是软件开发的*后一道关，也是*容易出乱子的一关。很多团队在测试环境跑得好好的，一上线就各种报错。根据我们多年交付项目的经验，90%的上线问题都集中在几个固定的环节。下面这份清单，是我们内部排查时常用的，你可以直接拿去对照。

环境差异：代码没变，配置变了

测试环境能跑，生产环境不行，**个要查的就是配置。常见的有：数据库连接串指向了测试库、缓存地址没改、第三方接口的密钥用的是沙箱的。这类问题排查起来快，但上线时一慌就容易漏。建议上线前把生产环境的配置文件跟测试环境做一次diff，重点看数据库、缓存、消息队列、外部API这四个地方。另外，环境变量和启动参数也要核对，特别是容器化部署时，经常出现环境变量没注入的情况。

数据库相关：慢查询和锁等待*要命

上线后如果出现页面加载慢、接口超时，先看数据库。新上线的功能往往伴随新的查询语句，测试环境数据量小，跑得快，生产环境数据量一大，慢查询就暴露了。排查时先看慢查询日志，重点检查新加的SQL有没有走索引、有没有全表扫描。另一个高频问题是锁等待：批量更新或者事务里做了太多操作，导致其他请求被阻塞。判断标准很简单，如果数据库的活跃连接数突然飙升，同时CPU不高，大概率是锁的问题。

还有一点容易被忽略：数据库连接池配置。测试环境连接数少，生产环境并发高，连接池不够用就会报连接超时。上线前根据预估的并发量调整一下*大连接数，通常设为峰值并发的1.5倍左右比较稳妥。

缓存与中间件：穿透、雪崩、序列化

缓存用得好是加速器，用不好就是故障源。上线后常见的缓存问题有三个：一是缓存穿透，查一个数据库里也不存在的key，每次都打到数据库；二是缓存雪崩，大量key同时过期，请求全落到数据库上；三是序列化不一致，比如测试环境用JSON，生产环境用JDK序列化，导致反序列化失败。排查时先看缓存命中率，如果命中率骤降，基本就是上面这几个原因。中间件方面，消息队列的积压、消费失败也要重点看，尤其是新上线的消费者，有没有正确处理异常和重试。

代码逻辑：边界条件和并发

测试用例覆盖不到的地方，往往是bug的藏身之处。上线后集中暴露的逻辑问题有两类：边界条件没处理，比如空值、超大数值、特殊字符；并发场景没考虑，比如同时下单导致库存超卖、重复提交表单。这类问题排查起来需要结合日志和业务数据，先定位到具体的请求参数，再复现。建议上线后头几个小时，安排人盯着错误日志和业务监控，发现异常立即回滚或热修复。

依赖服务与网络：超时和重试策略

你的系统不可能孤立运行，依赖的第三方服务、内部微服务出问题，也会让你背锅。上线后如果出现大量超时，先检查依赖服务的健康状态和网络延迟。常见错误是超时时间设置不合理：测试环境网络好，超时设了5秒，生产环境跨机房，5秒根本不够。另外重试策略也要注意，无脑重试可能把下游打垮。建议对关键依赖设置合理的超时和熔断，重试要加退避策略。

上线后的头两小时，盯紧这几个指标

问题排查得再快，不如提前发现。上线后建议重点盯五个指标：接口错误率、平均响应时间、数据库慢查询数、缓存命中率、消息队列积压量。任何一个指标异常，都值得停下来查一查。另外，日志的采集和检索要提前配好，否则出了问题只能靠猜。*后提醒一句：回滚方案一定要在上线前准备好，并且验证过。真出问题时，快速回滚比现场调试更靠谱。