支付回调接口为什么必须幂等
支付回调是后端少数「对方一定会重复调你」的接口。把它做成幂等不是加分项，是底线——一旦同一笔支付被当成两笔处理，轻则重复发货，重则重复加余额、重复返佣，直接是资金事故。 回调为什么一定会重复很多人第一反应是「支付平台为什么不调一次就好」，但重复几乎无法避免： 平台重试机制：微信、支付宝的回调约定是——只要没收到你返回的成功标识（如微信的 SUCCESS），就会在几秒到几小时内按退避策略反复推送。你这边超时、抖动、发布重启，都会触...
Excel 导入为什么容易写乱
这篇按踩坑笔记来写，因为 Excel 导入为什么容易写乱 我现在更容易记住“错在哪”，而不是“定义长什么样”。 先记住这句话导入流程要拆成解析、校验、预览、入库和错误反馈。 很多问题不是不会用，而是用得太顺手了，顺手到把边界条件给省掉了。 这类问题一般怎么出现我脑子里会先放这个场景：设计商品批量导入的错误报告。 一开始看着都像是个小问题，真正麻烦的是它往往不是立刻报错，而是跑一阵子、数据一多、并发一上来才暴露。 这次我想盯住的坑 ...
文件上传接口的限制、安全和存储
今天不想写长文，先把 文件上传接口的限制、安全和存储 这块拆成几条短一点的问答。面试里经常会被连续追问，如果只背一句定义，第二问基本就卡住了。 先说我自己的结论上传接口要同时考虑用户体验和安全边界。 我现在会先把这类题分成“定义是什么、为什么这样设计、代码里怎么用、容易翻车在哪”四层去答。这样比死背一段话稳很多。 快问快答 限制大小和类型。我现在的理解：先记结论，再回到代码里找一个能验证它的场景。 文件名不能直接信任。我现在的理解...
小项目的用户表和权限表设计
今天把 小项目的用户表和权限表设计 补成一篇正常一点的学习笔记，不写大而全，就记我这轮最想吃透的部分。 一句话先立住用户权限设计从简单可用开始，避免一上来过度复杂。 我这次真正记住的点 用户表保存身份基础信息 角色表表达权限集合 关联表解决多对多 为什么我会专门记这块因为它很容易出现一种错觉：看资料的时候觉得自己会了，真到写接口、改 SQL、配事务、看线程池参数时又开始发虚。 我现在尽量把知识点挂到一个具体场景上：设计用户、角色...
一个后端接口从需求到上线的流程
这篇我想按“排查记录”来写，主题是 一个后端接口从需求到上线的流程。这种写法比纯概念文更适合我自己回看。 现象先别急着解释把需求拆成设计、编码、自测、联调、上线和复盘。 先把现象钉住，比急着下结论有用。很多时候真正的关键不是“答案是什么”，而是“我是怎么一步步排到这里的”。 我会先看哪几件事 需求阶段问清边界 开发阶段留下测试 上线阶段准备回滚方案 带入一个排查场景梳理新增优惠券领取接口的完整流程。 如果这是线上问题，我通常会先...
代码 Review 时我会重点看什么
这篇我想按“排查记录”来写，主题是 代码 Review 时我会重点看什么。这种写法比纯概念文更适合我自己回看。 现象先别急着解释Review 不是挑刺，而是提前发现设计和维护问题。 先把现象钉住，比急着下结论有用。很多时候真正的关键不是“答案是什么”，而是“我是怎么一步步排到这里的”。 我会先看哪几件事 先看需求是否实现 再看边界和异常 最后看命名和重复代码 带入一个排查场景按清单 Review 一个新增接口。 如果这是线上问题...
接口文档和前后端联调流程整理
今天不想写长文，先把 接口文档和前后端联调流程整理 这块拆成几条短一点的问答。面试里经常会被连续追问，如果只背一句定义，第二问基本就卡住了。 先说我自己的结论接口文档是协作契约，不是上线前补的说明。 我现在会先把这类题分成“定义是什么、为什么这样设计、代码里怎么用、容易翻车在哪”四层去答。这样比死背一段话稳很多。 快问快答 字段含义要明确。我现在的理解：先记结论，再回到代码里找一个能验证它的场景。 错误码要列出来。我现在的理解：先...
集成测试应该测到什么程度
今天把 集成测试应该测到什么程度 补成一篇正常一点的学习笔记，不写大而全，就记我这轮最想吃透的部分。 一句话先立住集成测试关注组件协作，不必覆盖所有细节。 我这次真正记住的点 启动真实 Spring 上下文 核心链路走真实配置 外部系统用测试容器或替身 为什么我会专门记这块因为它很容易出现一种错觉：看资料的时候觉得自己会了，真到写接口、改 SQL、配事务、看线程池参数时又开始发虚。 我现在尽量把知识点挂到一个具体场景上：测试创建...