Excel 导入要把错误反馈当成产品功能
Excel 导入要把错误反馈当成产品功能后台系统经常有 Excel 导入。真正影响体验的不是能不能读文件，而是导入失败时用户能不能知道哪里错了、怎么改、改完能不能继续导。 模板要明确导入模板应该尽量减少歧义。字段名称、必填说明、枚举取值、日期格式、示例数据，都应该放在模板里。不要把规则只写在接口文档里，因为实际使用模板的人未必会看文档。 模板越清楚，后端校验压力越小，用户试错成本也越低。 校验要分层导入校验可以分成格式校验、字段校...
定时任务不要只关注能不能跑
定时任务不要只关注能不能跑定时任务写起来很快，但线上最容易出问题的地方往往不是能不能触发，而是重复执行、执行失败、部分成功、没人发现和无法重跑。 任务要能重复执行定时任务可能因为发布、调度抖动、人工补偿而重复触发。如果任务逻辑不幂等，重复执行就可能造成重复扣款、重复通知、重复生成数据。 所以任务入口要和普通接口一样考虑幂等。可以通过业务状态、任务记录、唯一标识等方式保护。 失败要可恢复任务失败后不能只依赖下一轮自然执行。有些任务错...
代码评审应该先看风险
代码评审应该先看风险代码评审如果只盯格式、命名和缩进，很容易错过真正重要的问题。风格当然要统一，但评审的第一目标应该是降低上线风险。 先看行为变化我看评审时会先问：这个改动改变了什么业务行为。新增功能、修改状态流转、调整查询条件、改变权限判断、重写异常处理，这些都比变量名更值得优先关注。 如果行为变化说不清，说明提交本身也可能没有被充分理解。 再看边界情况边界情况包括空数据、重复请求、并发提交、依赖失败、权限不足、历史数据兼容。很...
单元测试不只是为了覆盖率
单元测试不只是为了覆盖率单元测试如果只为了覆盖率，很容易写成调用方法、断言不报错。这样的测试看起来存在，真正重构时却给不了多少信心。 测业务规则我更关注业务规则是否被测试固定下来。比如状态是否允许流转、金额是否正确计算、权限是否能阻止非法操作、异常输入是否被拒绝。 这些规则一旦有测试，后面改代码时就不容易悄悄改变业务含义。 测边界条件边界条件比普通路径更容易出错。空列表、缺少字段、重复提交、状态不匹配、外部依赖失败，都值得写成测试...
上线清单是把经验前置
上线清单是把经验前置上线清单不是形式主义。它的价值是把过去踩过的坑前置到发布前，让团队不用每次都靠记忆和临场发挥。 检查配置很多线上问题来自配置差异。数据库地址、缓存开关、第三方接口、文件路径、定时任务开关、环境变量，都应该在上线前确认。 配置检查不只是看有没有值，还要看值是否属于当前环境。测试环境能跑，不代表生产环境配置就正确。 检查数据变更如果上线涉及表结构、初始数据、历史数据修复，就要提前准备脚本和回滚方案。脚本最好在预发布...
Nginx 反向代理排查从请求路径开始
Nginx 反向代理排查从请求路径开始Nginx 反向代理出问题时，表现可能是页面打不开、接口跨域、静态资源丢失、后端拿不到真实地址。排查时先不要急着改配置，先把请求路径走一遍。 先确认请求到了哪里第一步是确认域名解析、端口监听和 server 匹配是否正确。请求如果没有进入预期的 server 块，后面的 location 配置再正确也没用。 这一步可以通过访问日志和错误日志确认。日志里能看到请求路径、状态、上游地址和错误原因。...
Docker 部署后端服务要关注可替换性
Docker 部署后端服务要关注可替换性Docker 部署的好处不只是能跑在容器里，而是让服务更容易替换、回滚和迁移。要做到这一点，镜像、配置、日志和数据都要有清晰边界。 镜像只放应用镜像应该尽量只包含应用运行所需内容，不要把环境配置、临时数据、日志文件都固化进去。配置应该通过环境变量、配置文件挂载或配置中心注入。 这样同一个镜像才能在不同环境复用。否则每个环境都做一个镜像，部署会越来越乱。 数据要放在容器外容器可以删除重建，所以...
Spring Boot 配置分层要避免到处散落
Spring Boot 配置分层要避免到处散落Spring Boot 项目里配置很容易越写越散：一部分在配置文件，一部分在启动参数，一部分在环境变量，还有一部分写死在代码里。短期能跑，长期会让排查和迁移变困难。 环境配置要分开不同环境的数据库、缓存、文件存储、第三方服务地址通常不一样。它们应该通过环境配置隔离，而不是靠改代码切换。 环境配置分开后，发布时要确认当前激活的环境和配置来源。很多问题不是配置不存在，而是用了错误环境的配置...