1月26号晚上我把这段时间的后端学习笔记重新翻了一遍顺手把几个反复踩坑的点整理成了这篇日记。后端这个东西入门路径多、资料更杂真正能落到自己项目里的东西反而不多。这篇日记涵盖了我最近在技术选型、前后端分离实战、框架使用和面试复盘几个方向上的积累如果你正打算往后端走或者刚写了几个CRUD项目想往上提一提应该能从中找到一些可以直接用的思路和代码片段。1. 后端到底学什么先想清楚方向再动手1.1 软件后端和数字后端是两条完全不同的路先说一个容易劝退新人的坑。搜“后端”这个词的时候你大概率会看到两类内容一类是Java后端、Python后端、前后端分离这些属于软件后端另一类是“数字后端”“芯片后端”“Innovus数字后端”这些属于芯片设计领域里的物理实现环节。二者名字里都有“后端”实际干的事差别极大学习路线也几乎不重叠。软件后端关注的是服务端程序接收处理请求、操作数据库、调用第三方服务、保证接口性能和稳定性。而数字后端是芯片设计流程中的一个环节负责把电路网表变成可制造的版图核心工具是Innovus、ICC2这类EDA软件。如果你是被“后端”关键词吸引进来的先分清楚自己对哪个方向感兴趣别稀里糊涂学错方向。我自己的建议是如果你对互联网应用、业务系统、接口开发感兴趣走软件后端也就是通常说的服务端开发如果你学的是微电子、集成电路相关专业那才需要关注数字后端。这篇日记谈的内容全部围绕软件后端展开。1.2 主流技术栈怎么选Java生态和Python生态的取舍确定走软件后端之后下一个绕不开的问题是选哪个技术栈。我目前接触最多的是Java和Python最近刚好折腾过Spring Boot 3和FastAPI两个典型框架可以给你一个比较直观的感受。Java生态的核心关键词是稳定和规范。Spring Boot 3是目前的主流版本默认基于JDK 17继承了整个Java生态里成熟的方案MyBatis-Plus操作数据库、Spring Security做权限、Nacos做配置和注册中心。它的优势在于企业级项目的可维护性和团队协作的规范性。一个大型项目往往需要多人长期维护Java的强类型、IDE支持、丰富的静态检查工具能让团队协作时的隐性成本低很多。FastAPI则是Python世界里异军突起的框架。它基于ASGI性能表现不错而且是自动生成OpenAPI文档写接口的同时就把接口文档顺手生成了。如果项目偏AI方向比如要提供一个模型推理服务用FastAPI是非常顺手的组合。所以你问我怎么选答案其实不在框架本身而在项目场景。如果是个人练手、AI服务、快速出原型FastAPI效率更高如果你是在企业里做一个要跑很多年的业务系统或者想为进大厂做准备Java路线依然是投入产出比最高的选择。我认识的不少朋友一开始迷恋“新框架”最后找工作阶段还是老老实实补Java。另外提一个热词里经常出现的问题想用JavaScript写后端项目用什么框架好如果你只会JS、暂时不想学Java或PythonNode.js生态里NestJS是结构化最接近Java Spring的Express和Koa则更适合小项目和接口简单的场景。语言本身不是瓶颈对项目的理解和工程化能力才是。2. 前后端分离实战里的几个硬骨头2.1 跨域前后端分离绕不过的坎前后端分离项目的开发阶段跨域问题几乎一定会遇到。前端跑在5173端口后端跑在8080端口浏览器一看端口不同就直接把请求拦下来了。这不是后端接口没写好而是浏览器同源策略在起作用。跨域的核心是CORS全称是跨域资源共享。解决思路主要有三种后端直接放行、网关统一处理、Nginx反向代理。后端直接配置是最快的方案。在Spring Boot 3里可以全局配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }FastAPI里更简单加一个中间件就行from fastapi.middleware.cors import CORSMiddleware app.add_middleware( CORSMiddleware, allow_origins[http://localhost:5173], allow_methods[*], allow_headers[*], )注意allowCredentials(true)和allowedOriginPatterns()是不能同时用“”的浏览器规范不允许凭证携带加通配源。换句话说如果你要带Cookie就必须明确指定允许的源不能图省事全放通。我见过不少新手在这上面翻车配置全放行结果带不了Cookie接口一直报跨域错。Nginx反向代理是生产环境更常见的方案原理是让前端请求走同源路径由Nginx转发到后端浏览器感知不到跨域存在location /api/ { proxy_pass http://127.0.0.1:8080/; }这种方式还能顺便解决环境配置、SSL证书等一堆问题是后端上线前应该掌握的基本功。2.2 按钮重复提交前端防了后端还得防热词里有一条是“前后端对于按钮重复提交校验方法”这个问题我在实际项目里遇到过很多次用户手抖双击提交或者网络波动触发请求重发结果数据库里插入了两条一模一样的数据。前端处理方式很直观点击之后把按钮置灰、显示loading状态等请求结束再恢复。但前端防不住所有情况比如用户用工具直接调接口或者请求超时后自动重试。所以后端必须做幂等校验。后端做防重提交比较常用的方案是Token令牌机制。流程是这样的用户打开提交页面时先向后端申请一个唯一token提交时把token一并携带后端收到请求后先检查token是否存在存在则处理业务并删除token不存在则直接判定为重复请求。具体到Spring Boot实现可以用Redis做一个简单的接口幂等校验public boolean checkAndDelete(String token) { return Boolean.TRUE.equals( redisTemplate.delete(idempotent: token) ); }delete返回true说明token原本存在且现在被删掉了说明这是第一次提交返回false说明token本来就不存在这次要么是重复提交要么token过期直接拒绝处理。如果项目没引入Redis也有一个简单的替代方案在业务表上加唯一索引利用数据库本身做约束。比如订单表加一个“业务流水号”字段并建立唯一索引重复的流水号插入时数据库会直接报错业务侧捕获这个异常返回“请勿重复提交”即可。这个方案的优点是实现简单、不引入额外中间件代价是只能在插入场景使用对更新场景覆盖不够。从实战角度说前端置灰防手滑后端幂等防并发两者缺一不可。把校验都放在前端等于裸奔只做后端又会牺牲用户体感合理的做法是两层都做各管一段。3. 框架选型与项目落地的关键细节3.1 Spring Boot 3与若依框架带来的启发因为要做一个后台管理系统我专门研究过RuoYi框架也就是热词里的“若依框架”。它的核心价值是把后台管理系统里那些重复性极高的模块——用户管理、角色管理、菜单权限、操作日志——全部内置好了配合代码生成器能快速生成一套前后端分离的CRUD页面。用完之后的一个感受是这类框架解决的是“标准化建设”的问题。绝大多数企业内部的后台系统本质上是把Excel数据搬到网页上加上权限控制。这个场景里若依这类脚手架能省掉大量重复开发时间而且代码结构统一后续交给新人也容易接手。但我不建议一上来就想着套一套框架。若依的权限体系是基于RBAC模型的代码里也带了不少它的设计约束。如果你只是要写一个小接口整个项目反而被框架拖得比较重。我的经验是练手阶段自己从零搭一个Spring Boot项目把Maven结构、统一返回、全局异常、MyBatis-Plus配置这些跑熟然后再去看若依这种框架能看懂的设计就多很多。直接拿若依当学习资料容易被各种封装绕晕以为自己在学Spring Boot实际上只是在学怎么填配置。Spring Boot 3本身有几个新特性值得留意基线版本升到JDK 17、包名从javax迁移到jakarta、对GraalVM原生镜像的支持也更好。如果你用的是旧教程和老代码遇到包名不对的情况基本就是版本迁移问题先检查依赖坐标而不是怀疑代码写错。3.2 多个Java后端项目合并的要点热词里有条“多个java后端项目合并要点有哪些”这个我刚好在一家外包公司经历过。当时公司手里五六个小项目每个都是独立代码仓库、独立数据库客户后期提了要求要把这些系统的账号统一、菜单统一于是就有了合并项目的需求。合并过程中踩过的坑可以给你列一下。首先是代码结构问题。五个项目的Maven坐标可能完全一样或者controller路径相互覆盖直接合并必然乱套。正确做法是拆成Maven多模块结构按业务域划分modules modulecloud-common/module modulecloud-system/module modulecloud-order/module modulecloud-user/module modulecloud-gateway/module /modules公共代码下沉到common模块各业务模块独立成module模块之间不能互相引用只能依赖common层。第二个要点是版本统一。每个项目可能用了不同版本的Spring Boot、MyBatis-Plus合并时如果不统一会冒出各种依赖冲突。建议在父POM里用dependencyManagement统一管理版本子模块只声明依赖坐标、不写版本号避免冲突。第三个要点是数据库权限处理。不同项目的用户表设计不一样有的叫sys_user有的叫t_user合并后必须统一。我的建议是合并阶段先把用户体系统一成一套其他业务数据通过外键关联。先跑通权限再慢慢迁移业务分步推进比一步到位安全得多。配置统一也容易被忽略。几个项目各自带配置文件合并后环境地址、数据库连接散落各处部署阶段会非常痛苦。最好提前引入Nacos或Consul做配置中心把环境差异收敛到一套配置上。4. 后端面试复盘把八股文变成肌肉记忆4.1 面经里翻来覆去问的那些问题到底在考什么说到“滴滴后端面经”“java后端面试八股文”很多新手第一反应是去背题结果背了一堆概念一深问就露馅。我的体会是这些八股文题目背后其实有一套规律搞懂考官想考什么比记住答案重要得多。并发相关问题是Java后端面试的重灾区。线程池参数怎么设置、synchronized和ReentrantLock的区别、volatile到底保证什么这些问题表面上问的是API记忆实际考的是你有没有真正处理过并发场景。我面试实习生的经验是能说出“线程池参数不能拍脑袋定得结合QPS、业务耗时和机器核数来算”这句话比背出完整的ThreadPoolExecutor参数列表更让人信服。JVM和GC同样如此。考官问你JVM内存区域划分不是希望你把《Java虚拟机规范》背一遍而是想确认你在面对线上OOM、频繁Full GC时有没有一套排查思路。正确的回答路径是先用jstat看GC频率再用jmap导出堆转储最后用MAT分析大对象。能把排查动作讲成自己的经验远胜于干巴巴的概念定义。另外MySQL索引和Redis缓存几乎是必考项。索引这块的核心实际上是理解B树为什么适合磁盘存储——树高度低、范围查询友好。Redis强调的是缓存和数据库一致性怎么处理、缓存穿透击穿雪崩怎么应对。这些问题都有标准答案但你要在答案里加入自己的取舍比如“我项目里用的延迟双删”“XX场景下我选择不缓存直接查库”考官才会觉得你真在项目里用过。4.2 笔试和项目描述怎么准备才有亮点热词里还有“java后端前端笔试题”这个表述有点杂糅我把它理解为前后端分离场景下的后端岗笔试。梳理下来常见的题目类型大概三类算法题、SQL题、设计题。算法和SQL没捷径就是刷题和写复杂查询尤其是日期处理、分组统计、窗口函数这类SQL工作中碰到概率极高。项目描述这一块很多人容易写成流水账“负责了登录注册模块”“写了商品接口”。这种描述太弱了。我建议按问题-动作-结果来讲开发中遇到了什么问题我用了什么方案解决带来了什么结果。举个例子“用户反馈下单重复我在后端引入Redis分布式锁做幂等校验重复提交率降到了0”这个描述比“参与订单模块开发”强一个量级。另外热词里有个很接地气的点“java后端怎样和产品经理确定”。这个其实是很重要的一项软技能。后端开发不能拿到需求就开写第一件事是把需求里模糊的地方问清楚数据从哪来、字段怎么定义、异常怎么处理、响应格式什么样。产品经理经常默认你懂业务你不问他以为自己描述清楚了最后做出来的东西对不上浪费的是双方的时间。我的习惯是产出接口文档时同步整理一份字段说明表跟产品逐条确认确认完再动工后续扯皮能少很多。5. 写在最后的几点体会这篇日记写到这正好收个尾。1.26对我来说比较大的收获是发现自己开始能把“学过的东西”和“做过的项目”连起来了。比如防重提交以前看概念觉得很简单真上线遇到重复单才发现有那么多边界情况跨域问题也是开发环境配好了以为万事大吉部署到服务器上又被Nginx代理配置卡了半天。给刚入坑的朋友一个建议学后端一定要做项目做项目一定要做完整的功能闭环。从数据库建表、接口开发、前端联调、部署上线每个环节都亲自动手走一遍。这个完整闭环走完你学过的所有技术点才会有落地的感觉。看教程、记笔记、背八股都替代不了这个体验。最后分享一个小技巧是我写日记沉淀下来的习惯每天学完东西不管多晚花十分钟记录三件事——今天遇到什么问题、怎么解决的、明天准备做什么。别小看这十分钟一个月攒下来你的进步会比你想象的大得多。