CAREER · BACKEND

后端这五年，我真正赚到的三件事

阿衡 · 后端工程师 · 支付 / 交易系统

很多人问我：后端要不要死磕框架、要不要天天刷题、要不要尽早转架构。我的答案一年变短——框架会过时，题库会贬值，真正拉开差距的，是你有没有把线上系统当成「自己的责任田」。

这篇不教你怎么背八股，只写我在支付链路里踩过、修过、复盘过的东西：三条观点，两段案例，再给刚入行的同学几句掏心窝的话。

三条我反复验证过的观点

观点 01

会写接口，不等于会扛流量

CRUD 谁都会。差别在高峰时限流怎么配、超时怎么设、降级会不会把核心链路保下来。后端的本事，往往藏在「出错之后还能不能活」里。

观点 02

日志不是事后补丁，是设计的一部分

凌晨三点排障，最恨「成功了打一行、失败了什么都没有」。关键路径要有 traceId、要有业务单号、要有明确错误码。可观测性不是运维的事，是你代码里就该留的钩子。

观点 03

技术争论输赢不重要，线上指标才说话

同步还是异步、强一致还是最终一致，会议室里吵不完。把假设写成可灰度方案，用错误率、延迟、资损风险说话。能落地的方案，比「理论上更优雅」值钱。

数字做过脱敏，过程尽量写清楚，方便你对照自己的系统。

CASE 01 · 大促支付超时

P95 从 800ms 飙到 3.2s，不是「再加点机器」能解决的

背景　某次大促第二波流量上来后，支付确认接口大面积超时。扩容两轮，CPU 并不高，DB 连接池却打满。值班群里有人要「先重启」，有人要「关非核心入口」。

排查　顺着 trace 发现慢在一次「查单 + 更新状态」的串行事务里，热点商户把同一行行锁抢爆。扩容只会让更多线程去排队抢锁。根因是模型设计把热点写路径塞进了同一行。

动作　短期：对该类商户做排队与限流，保护全局。中期：状态流转拆成「受理 / 确认」两段，热点用分片键打散；补超时重试幂等键，避免用户连点造成双花风险。

结果　当晚核心成功率回到 99.95%+；事后把「热点行锁」写进评审清单。我学到：性能问题常常是数据模型问题，不是机器台数问题。

CASE 02 · 一次「看起来成功」的资损隐患

回调重复了三次，业务侧却只看见一次成功

背景　渠道回调偶发超时，我们侧重试；下游订单服务按「收到即入账」处理。灰度期间资损巡检发现：极少数订单被重复入账，金额不大，但性质很严重。

根因　幂等键只做了「请求指纹」，没覆盖「业务结果落库」的唯一约束。重试到达时，第一次其实已经成功，第二次仍走了入账分支。

动作　以业务单号做 DB 唯一键；入账前先查终态；回调与主动查单共用同一套状态机。补对账任务，按分钟级扫差异单。

结果　同类重复入账归零。评审会上我只强调一句：支付系统里，「成功」必须可证明、可去重、可对账——否则它只是日志里的一句安慰。

1.　先把主链路画清楚：请求从哪进、状态怎么变、失败怎么回滚。画不清楚，就不要急着上新框架。

2.　值班不是受罪，是最快的成长场。每次故障写一页复盘：现象、时间线、根因、动作、防再发。半年后你会感谢这些文档。

3.　Code Review 别只盯风格。多问：超时怎么办？重复请求怎么办？依赖挂了怎么办？这三问比争论命名更接近生产。

4.　别急着「转型架构」。先把一个子系统从需求到上线到稳定性全部扛住。标题会来，但能力不会因为换 title 自动变强。

你在后端路上，最近卡在哪一关？

关注后持续更新线上复盘与工程笔记

关注公众号