后端工程师的后端工作，远不止写接口那么简单。工程上周我review一个同事的师岗代码，发现他在订单查询接口里直接循环调用数据库，位职一次请求打了47次SQL。后端问他为什么，工程他说功能跑通了。师岗功能确实跑通了，位职但线上环境两千个并发进来，后端数据库连接池瞬间打满，工程整个服务雪崩。师岗这就是位职后端工程师日常要面对的真实问题——代码能跑和代码能扛，中间隔着一整套工程判断。后端

核心职责第一条：设计并维护服务端的工程数据流转。用户在前端点一下按钮，师岗后端要决定这个请求走哪条链路、经过哪些服务、在哪个环节落库、返回什么结构。拿我做过的一个支付回调来说，第三方把钱打过来，我们得校验签名、幂等处理、更新订单状态、通知业务方、记录流水。每一步都可能出错。签名校验失败怎么办？重复回调怎么保证不重复发货？这些不是边角料，是后端工作的主体。写代码的时间可能只占三成，剩下七成在想异常路径。

接口设计和数据库操作是每天都要碰的。但很多人把这两件事做得很糙。接口返回结构随意改，前端骂娘；SQL没有索引，慢查询日志一天几百条。我见过一个查询用户订单列表的接口，表里三百万数据，没加索引，每次查询全表扫描。后来加了一个联合索引，响应时间从2.3秒降到18毫秒。后端工程师得对数据库有基本的敬畏心，知道什么时候该加索引、什么时候该分页、什么时候该走缓存。

缓存不是万能药，但不用缓存很多场景根本撑不住。我们有个热点商品接口，QPS峰值一万二。直接查数据库肯定不行，加了Redis缓存之后，数据库压力降到每秒几十次。但缓存带来一致性问题。商品价格变了，缓存怎么更新？删缓存还是更新缓存？先删数据库再删缓存还是反过来？这些问题没有标准答案，得根据业务容忍度来选。我倾向于先更新数据库再删缓存，配合一个短过期时间兜底。不是最优解，但够用。

服务拆分和治理是另一个绕不开的活。单体应用拆成微服务之后，调用链路变长，问题定位变难。一个请求超时了，是网关的问题、服务A的问题、还是服务B的问题？得靠链路追踪。我们用的SkyWalking，每个请求打上traceId，从入口一路跟到数据库。有一次线上响应变慢，通过链路追踪发现是某个下游服务在批量调用时没控制并发，把线程池打满了。这种问题不看链路根本找不到。

还有日志和监控。后端工程师得知道自己写的代码在线上跑成什么样。我习惯在关键路径打点，比如订单创建成功打一条info日志，失败打error并带上上下文。监控面板上配好QPS、响应时间、错误率三个核心指标。有一次凌晨两点收到告警，错误率突然从0.1%飙到15%。爬起来看日志，发现是某个第三方接口改了返回格式，解析失败。如果没有监控和日志，这个问题可能要等到用户投诉才发现。

最后说一句实在的：后端工程师的职责边界在扩大。以前只负责写服务端逻辑，现在要懂一点运维、懂一点前端联调、懂一点产品思维。不是要你什么都干，而是出了问题你得能定位到是哪一层的事。数据库慢了找DBA，但DBA问你SQL怎么写的，你得答得上来。这就是后端工程师的日常——在代码、数据、流量和故障之间，找到那条能走通的路。