上个月高新区一家做票务的小公司找我，微信支付回调老是超时，一天丢七八单，老板急得跳脚，说再丢单就要关店了。我远程看了半小时，把过程记下来，遇到类似问题的成都同行照着查，别重蹈覆辙，这种坑踩一次就够了，别拿生意交学费。别慌。
先确认是不是网络
他们服务器在腾讯云成都节点，ping支付网关延迟28毫秒，正常，带宽也没跑满。但抓包发现TCP连接三次握手后，有40%请求卡在TLS握手超3秒。问题不在带宽，在证书链——他们自签证书没配全中间证，部分客户端验证超时。踩过坑的人都知道，超时第一反应别怪代码，先看网络层，能省一大半弯路，乱改代码只会越改越乱，还查不出根因，白白熬夜。
查线程池有没有满
这家用的是Spring Boot默认线程池，最大200，但票务高峰并发到三百，多余请求排队等到超时，日志里全是RejectedExecution。把线程池调到500、加了个Redis排队缓冲后，超时率从6.2%掉到0.3%，老板当天就睡安稳了。说白了，连接数不够就别硬扛，配置跟不上业务量必崩，这是最常见的低级坑，偏偏人人都踩，因为默认配置看着挺大，真到高峰就露馅。
签名和重试的坑
他们回调没做幂等，支付平台因为超时重发了三次，订单重复出票，财务对账对到崩溃。加了订单号唯一索引和状态机后，重复单清零，重发直接丢弃。别被忽悠了，以为接口通了就完事，幂等和重试才是生产环境的真考验，漏掉就天天救火，半夜被电话叫醒的滋味不好受，谁挨过谁知道，那比写代码累十倍。后来他们把这套幂等模板抽出来，新项目直接复用，再没出过重复单，一劳永逸。
给成都同行的清单
超时排查按这个顺序走：网络延迟、DNS、TLS、线程池、慢SQL、第三方限流。我们帮七家公司定位过，六家是线程池或慢查询，只有一家真是支付平台故障，概率很低。工具用Arthas和Wireshark，成都本地的阿里云栖社区每月有次线下答疑，免费的，去听听比瞎搜强，还能认识同行，说不定单子就来了，技术圈就这么小。另外日志一定要留全，我们靠完整日志十分钟就定位到证书问题，没日志只能盲猜，那才叫真抓瞎。