凌晨一点，我盯着支付回调的日志，屏幕上两笔一模一样的订单流水几乎是挨着出现。笔数不多，但每一笔都对应着真实的用户扣款。那一刻我意识到，自己平时写业务代码时太依赖“直觉”，把太多基础知识点当成了理所当然。这个项目本身不复杂——接入新支付渠道、把回调落到订单表、再跑对账——但正是因为不起眼，才把许多我平时“以为自己会”的东西全部照了出来。
我想把这些最近遗漏的知识点按真实场景记录下来。它们各有各的触发条件，但共同点是：都藏在文档里，不踩坑时根本不会在意。这篇既是复盘，也可以当一份排查清单来用。
1. 幂等设计：重复回调这件事，我当时处理得太天真
1.1 为什么支付渠道会重复通知
接入支付回调时，我的第一版逻辑很直白：收到通知，验签，通过订单号查订单，然后更新状态。对照渠道方的接口文档时，一切看起来都顺理成章。直到联调环境里我手动点击“重发通知”，线上服务同时收到两条内容一致的回调，两个线程都经过“查订单”的步骤，发现状态都是待支付，于是走了两次相同的更新逻辑。虽然没有报错，但支付流水记录被写入两次，用户收到的扣款通知也变成两条。
后来翻渠道方日志才发现，回调并不是“成功就通知一次”，它们的服务端会在一段时间窗口内按 1 分钟、5 分钟、15 分钟的间隔持续重试，直到商户接口返回明确成功，或者最终放弃。这背后的原因是：任何网络传输都不能保证“恰好一次”，TCP 只能保证不丢包，不能保证业务系统处理成功。回调接口被设计出来的那一刻，就已经默认了消费方必须做到幂等，也就意味着我不能依赖“渠道不会重复通知”这个假设。
1.2 从“先查再插”到唯一约束的调优过程
错误的做法是“先查订单，再决定是否更新”。这个做法在低并发下很好用，但一旦两个请求同时到达，它们都可能读到“待支付”的状态，然后各自完成更新，窗口期里没有原子性。要解决并发下的重复，第一步是把业务更新语句改成带状态条件的：
UPDATE orders SET status = '已支付', paid_at = NOW() WHERE order_no = '20231223001' AND status = '待支付';受影响行数为 0，说明这条通知之前已经被处理过了，可以直接返回成功，不需要再做业务变更。注意，这里不能只依赖“先查后改”，因为查询和更新之间总有间隔，并发请求正是钻这个空子。状态条件更新把“判断和处理”合并成一条原子 SQL，比任何锁都直接。
但在复杂的支付场景里，单靠订单状态还不够。渠道交易号本身也应该具备唯一约束。我当时补了一张通知流水表，把每次回调原始报文都存下来，再给渠道侧的交易号加唯一索引。处理流程变成：先写入流水表，如果插入重复，直接忽略；只有第一次插入成功，才继续去更新订单状态。这样即使下游业务逻辑写得再粗心，唯一的约束都会在数据库层拦住重复。
1.3 通知流水表不只是防重，更是排查工具
这张流水表后来的价值远超我的预期。联调阶段，渠道方偶尔反馈“某个通知你那边返回异常”，我可以通过订单号反查出这个订单从早到晚被回调了几次、每次间隔多久、是验签失败还是写入失败。如果把所有回调都只当“防重复”处理而不落库，排查时只能靠应用日志，日志一旦被滚动冲掉，就只能靠猜。
更进阶的用法是拿它做对账。每天凌晨从流水表里拉取已经成功的通知记录，和渠道后台的交易列表做一次对比，看哪些交易渠道扣了款但我们没有处理记录，哪些我们记录了但渠道列表里不存在。对账关注的是全量流水和终态结果的差集，而不是“最后一次同步状态”。如果没有这张独立于业务表之外的流水表，对账很可能要从业务单据里反推支付记录，容易漏掉中间状态。
2. 索引失效：EXPLAIN 结果里的全表扫描让我沉默了两次
2.1 隐式类型转换：varchar 与 int 的意外陷阱
幂等处理好之后，压测才开始，慢查询就陆续冒出来。我看了一眼其中一条 SQL，发现订单号列明明是varchar(64)，但查询条件写的是order_no = 20231223001，没有加引号。MySQL 在比较字符串列和数字常量时，会默认把字符串转成数字再比较，而不是把数字转成字符串。这一转换会让索引失去原本的字符串有序性，优化器只能放弃索引，走全表扫描。
这种隐式转换并不限于单表查询。A 表的主键是bigint，B 表关联字段是varchar，两张表 JOIN 时同样会触发转换，导致 B 表索引失效。我后来在项目里定了一条规则：关联字段的类型定义必须完全一致，包括长度、有无符号、字符集。因为字段定义一致，才能从根本上让数据库的优化器老实走索引，而不是靠每次写 SQL 都要记得“加引号”。
另一个容易忽略的写法是查询YEAR(create_time)、DATE_FORMAT(create_time, '%Y-%m')这类函数包裹列。索引的核心优势是 B+ 树内部按原值排序，一旦列参与函数运算，每个候选值都要先被算一遍才能比较，无法利用“有序”这个前提，索引自然失效。解决办法很简单：把函数计算挪到常量那一边，而不是套在列上。
比如统计某天的订单，我过去习惯写：
SELECT COUNT(*) FROM orders WHERE DATE_FORMAT(created_at, '%Y-%m-%d') = '2024-06-01';后来改成区间扫描：
SELECT COUNT(*) FROM orders WHERE created_at >= '2024-06-01 00:00:00' AND created_at < '2024-06-02 00:00:00';左边保持列本身不参与任何计算，优化器就能直接走索引区间。这个知识点我确实早知道，但实战时还是习惯写前者，因为读起来更接近自然语言。直到线上全表扫描的数据量打到几十万行，压测响应时间一口气翻了好几倍，我才真的长记性。
2.2 复合索引的列顺序：范围查询后还有没有机会
复合索引的列顺序也踩过坑。当时索引建的是(merchant_id, create_time, status)，查询条件依次是merchant_id = ? AND create_time > ? AND status = ?。这里的问题在于：create_time是范围条件，范围条件一旦出现，索引后面的status就没办法继续利用有序性进行精确定位了。优化器只能快速定位到商户和时间范围，再在这个范围内逐行检查status。
要优化这类查询，需要重新思考列顺序。如果status的选择性更强，把索引调整成(merchant_id, status, create_time)，优化器就可以先用前两列等值定位，再把create_time作为范围压入一个较紧的子区间。这个决策完全取决于实际数据分布，并不存在一个万能顺序。我的经验是先看区分度，再配合EXPLAIN的key_len判断优化器用了索引前缀到哪一列。
2.3 上线前多看几眼 EXPLAIN 的输出
其实上面两类问题，只要在发版前跑一次EXPLAIN，看一眼type是不是ALL、rows是不是整表行数，基本都能提前发现。关键是要养成本能习惯，而不是等项目跑挂了再回头检查。我现在每次写完涉及生产表的 SQL，都会顺手在测试环境用EXPLAIN ANALYZE跑一遍，把type和rows截图贴在 MR 描述里。哪怕接口只改一个过滤条件，这个步骤也不省。压测里很多“突然变慢”的接口，追根溯底都是新增条件时没重新确认索引利用率。
3. TIME_WAIT 与端口耗尽：压测报告里的连接错误
3.1 TCP 主动关闭方为什么要等 2MSL
第三件事发生得很有意思，接口本身吞吐量没有变化，但压测脚本突然开始大面积报Cannot assign requested address。服务端 CPU 和内存都很平稳，数据库也没有问题，问题完全出在客户端。
我那时候才真正花时间去理解 TIME_WAIT，而不只是背“主动关闭方会进入 TIME_WAIT”。TCP 连接断开后，网络上还可能残留着旧连接的报文迟到、重传，如果端口马上被新的连接复用，旧报文可能被误认为是新连接的数据或确认号，造成数据混乱。TIME_WAIT 持续时间为 2MSL，就是让这一段网络上的潜在残留报文全部自然消失，保证旧连接的“幽灵”不会污染新连接。2MSL 通常对应一到两分钟，内核参数里的默认值不建议乱调，这是 TCP 自己的保护机制，不是可以随手优化的“垃圾回收”。
3.2 客户端同一时刻到底能用多少个端口
之所以报错，是因为我的压测脚本里每次请求都用fetch新建连接，请求结束就断开。客户端发起连接时，需要从ip_local_port_range里挑一个可用端口，与目标 IP 和端口组成四元组。默认范围一般是从 32768 到 60999，也就是两万多个端口。每次短连接释放后，客户端端口会进入 TIME_WAIT，在这段时间里无法被再次使用。当压测持续一段时间后，可用端口就被消耗干净，新的连接自然建立不起来。压测脚本的并发量不算高，但架不住每秒都在新建，几分钟就吃满了端口。
那个时刻我再回头看netstat -tan，满屏都是 TIME_WAIT，就一点也不意外了。要理解这里，必须分清“连接”和“请求”的区别：连接是四元组维度的，短连接模式下每次请求都消耗一个新的四元组，长连接模式下同一个四元组可以承载很多请求。
3.3 正确解法：连接复用，而不是粗暴调内核
最有效的解决方式是连接复用，也就是连接池。HTTP/1.1 的 keep-alive 本身就是这个目的。我调整了压测客户端，让所有请求复用同一个连接，TIME_WAIT 的数量立刻降到几乎为零。生产环境里的服务如果偏向短连接，重点也应该放在接入连接池上，比如数据库连接池、Redis 连接池、HTTP 客户端连接池，而不是一味地优化内核参数。
如果确实存在大量无法复用的短连接，Linux 里可以考虑打开net.ipv4.tcp_tw_reuse。这个参数允许客户端在发起新连接时安全重复使用处于 TIME_WAIT 的端口，注意它只作用于发起连接的一方。至于tcp_tw_recycle，这类需要谨慎，尤其不要部署在 NAT 环境里，因为它依赖时间戳判断，同一 NAT 后面的多台机器会被误伤，出现连接不可达的诡异现象。我不会在没搞清网络拓扑前开启它，更多时候连接池已经足够解决问题。
4. 时区与夏令时：订单日期差了一天这种Bug，最让人恼火
4.1 存储一律用 UTC，展示时才转本地
第三个踩坑的地方是时间。订单表最初存的paid_at是timestamp类型，数据库和服务器时区都配的北京时间，项目初期完全没感觉有问题。后来业务覆盖到其他地区，用户反馈“订单日期比实际少了一天”，我才开始追时区链路。
问题出在整套链路里许多环节各自有时区默认值：数据库连接参数里有一个时区，应用服务器的系统时区是一个，日志打印时还会再转一次。用户提交的时间字符串本身带它自己的时区偏移，到了后端按应用服务器时区解析。三者只要有一个不同，最终展示就会出现小时级的偏移，跨过某个临界点，日期就变成“昨天”或者“明天”。
后来我统一了规则：数据库里存 UTC 或 Unix 时间戳，应用层收发协议只认带时区的 ISO 8601 字符串，解析后立刻转成 UTC 存起来，展示时由前端或 API 层按用户的时区翻译。这样时区就只出现在边界，业务代码永远在 UTC 语义下运算。PostgreSQL 里直接用timestamptz，它在内部以 UTC 保存，但在计算时又能正确理解带偏移的输入值，比timestamp省掉很多隐式转换的麻烦。
4.2 夏令时给周期计算带来的 23 小时和 25 小时
时区的另一半坑是夏令时。某些地区春季会有一天只有 23 个小时，因为凌晨时钟往前拨一小时；秋季则有一天有 25 个小时。如果计算周期时写死“加上 24 小时”，跨过切换点的那一排任务，时间就会整体错位一个小时。
这类问题典型出现在每日跑批、账单周期、订阅到期时间上。比如“订阅本月底到期”，如果从月初加 30 个自然日，与“下月 1 日零点”在夏令时切换时会差出整整一小时。处理原则是：要算“日历上的下一天”就不要用now + 24h，而应该用日期时间库里的“加一天”语义。Java 里用ZonedDateTime.plusDays()，Go 里用time.AddDate()，前端用dayjs().add(1, 'day')，这些方法会基于日历语义去处理小时数的浮动，而不是简单做固定秒数运算。如果非得用 duration，就必须显式固定一个 UTC 偏移，避免走到“时钟往回拨一小时”的区间。
4.3 导出文件名和定时任务，全都没有幸免
时区问题还藏在一个最容易忽视的地方：文件名。我当时导出的对账单以日期命名，布尔变量叫todayStr，直接用服务器本地时间生成。结果某一天生产服务器的时区和业务预期不一致，文件生成出来以后，业务人员看到文件名里的日期和账务日期对不上，排查了很久才发现是服务器时区问题。
类似的还包括定时任务。很多调度框架在没有显式时区时，默认使用运行进程的系统时区。两个容器如果分别部署在不同时区的主机，同一个cron表达式就会在不同时刻触发。我的处理方式是把调度任务里的时区写死，让任务表达式带上timezone字段，比如0 0 2 * * * America/New_York。所有日志也统一输出带时区的 RFC3339 时间戳，这样跨系统排查时，只要时间格式标准，就不至于因为日志格式不统一而互相扯皮。
5. HTTP 缓存：新旧文件混用和“304”背后的协商机制
5.1 Cache-Control 和文件名指纹，缺一个都不行
最后一个知识点来自前端发布。重构上线后，总有一部分用户打开页面时还在请求旧版本的脚本，控制台里能看到 HTML 是新版本，但 JS 和 CSS 还是旧缓存。问题出在缓存策略配得不够细。
最稳妥的静态资源方案通常是这样：构建工具给每个文件内容生成唯一的哈希文件名，比如app.8f3d9c.js。这些带哈希的文件可以直接给很长的强制缓存时间，例如Cache-Control: public, max-age=31536000, immutable。因为文件名变了，浏览器没有理由拿旧文件；文件名没变，说明文件内容确实没变，本地缓存一年反而最优。而入口 HTML 文件不能这样做，否则浏览器会一直拿旧入口，永远不知道引用了新资源。HTML 应该用no-cache，让浏览器每次回源验证，配合协商缓存拿到最新入口信息。
5.2 ETag 和 Last-Modified，它们不是强制缓存
很多人会把强制缓存和协商缓存搞混。max-age是强制缓存，命中后浏览器不会再发请求，直接用本地副本；ETag 和 Last-Modified 是协商缓存，命中后还是要发一次请求，服务端返回304 Not Modified，不发响应体，从而省流量。两者解决的问题并不一样，也不冲突。
ETag 的常见生成方式是文件内容的哈希，或者是 inode、文件大小、修改时间的组合。浏览器在后续请求时带If-None-Match，服务端自动比较当前资源的 ETag，相同则返回 304。我踩过的一个细节是：某些网关会自动为响应生成 ETag，它可能基于内容的压缩后表示，也可能基于响应头的一部分排序结果。如果服务端调整过资源返回头的生成顺序，原来相同的资源会被误判为变更，304 命中率会断崖式下降。修改类似逻辑时，要在灰度环境观察状态码分布，再推到全量。
5.3 代理缓存和 Vary 头，这个坑很隐蔽
如果资源经过 Nginx 或 CDN，还需要关注Vary响应头。Vary的意思是：同一个 URL 在不同请求头条件下，可能返回不同的内容。典型例子是Accept-Encoding: gzip和br。如果源站本应根据请求头返回不同压缩格式，但没有在响应里写Vary: Accept-Encoding，代理层就可能把“gzip 压缩版”缓存下来，之后发给不接受 gzip 的客户端，导致乱码或者空白页。
只要同一个 URL 会因为 Cookie、User-Agent、地区参数而变化，就都应该通过Vary把差异表达清楚。代理层缓存 key 的生成默认只考虑 URL 和 Vary 指定头部，如果后端忘了，就会把不该公用的内容当成同一份缓存。出于稳妥，拿不准的接口宁可设no-cache，也不要让代理层缓存过头。
5.4 一个可以直接复制的最小 Nginx 配置
最后放一个最常用的静态资源配置，生产环境按实际目录结构调整即可：
location /static/ { add_header Cache-Control "public, max-age=31536000, immutable"; } location = /index.html { add_header Cache-Control "no-cache"; etag on; }带哈希的静态文件用一年期强缓存，HTML 入口走协商。这个配置不需要什么高级技巧，但能把“用户更新后仍访问旧版本”的问题挡在门外。任何前端缓存策略都必须回答两个问题：入口文件怎么保证最新，构建产物怎么最大程度复用本地缓存。
最后分享一个小习惯。这次项目结束之后，我在每个模块的提交清单里都会多问三个问题：这段逻辑会不会被重复调用且没有幂等保护？这个时间在目标用户的时区里看起来是否正确？这个响应被缓存后，会不会让用户看到过时的内容？这三个问题都来自这次踩坑经历，看起来很简单，但它们每一个都让我在深夜多花过几个小时。如果这些记录也能让读到的人少走一次弯路，那今天这篇文章就没白写。
