后端开发就像在雷区行走，技术栈越丰富，踩坑的概率越大。有些坑是教科书上的经典，有些则是只有经历过线上事故才会懂的痛。下面这7个坑，90%的后端都踩过，区别只在于踩得早还是踩得晚。
坑一：盲目上微服务，忘了单体也能打
微服务不是银弹。很多团队业务还没跑通，就急着拆服务、上注册中心、搞链路追踪，结果运维复杂度爆炸，一个请求跨五个服务，排查问题像破案。单体架构在业务初期完全够用，模块化做好，后续再拆也不迟。别为了技术而技术。
坑二：ORM用得太爽，SQL性能全忘光
MyBatis、JPA确实方便，但很多人从此不写SQL，也不看执行计划。一个N+1查询能拖垮数据库，循环里查库更是经典事故。ORM只是工具，不是遮羞布。关键业务必须手写SQL，必须看EXPLAIN，必须知道索引有没有命中。
坑三：缓存只加不删，数据一致性当儿戏
缓存用起来简单，一致性维护起来要命。先更新数据库再删缓存，还是先删缓存再更新数据库？并发下都可能脏读。更可怕的是缓存没设过期时间，数据变了缓存还是旧的，用户看到的是上个版本。缓存要有兜底策略，更要有时效性。
坑四：线程池随便配，线上直接OOM
Executors.newFixedThreadPool一行代码创建线程池，爽不爽？但队列无界，任务堆积直接内存溢出。核心线程数、最大线程数、队列容量、拒绝策略，每一个都要根据业务QPS和任务耗时计算。别等到线上OOM了才想起看线程池参数。
坑五：消息队列不幂等，重复消费成常态
MQ保证至少一次投递，意味着消息可能重复。如果消费端没有幂等设计，一次重复消费就是一次重复扣款、重复发货。用唯一ID+去重表，或者Redis原子操作，把幂等做在业务层。别指望MQ帮你解决所有问题。
坑六：日志只打不查，监控告警全靠人
日志打了一堆，出了事却不知道去哪个文件找。没有统一日志收集（ELK），没有关键指标监控（Prometheus），没有告警（Alertmanager），线上故障全靠用户反馈。日志要结构化，监控要覆盖黄金指标：延迟、流量、错误、饱和度。
坑七：配置硬编码，环境切换就翻车
数据库地址、Redis密码、第三方密钥全写在代码里，开发环境能跑，测试环境就崩。配置必须外置，用配置中心或环境变量，区分多环境。别让一个硬编码的IP地址，成为压垮上线的最后一根稻草。
总结
后端技术栈的坑，归根结底是“想当然”三个字。想当然地认为微服务更好，想当然地认为ORM不用管SQL，想当然地认为缓存不会脏。避开这些坑，不需要多高深的技术，只需要多问一句：如果这里出问题，会怎样？把这句话刻在脑子里，你就已经超过了90%的人。
