1.sqlmap查询的字段是否是全部字段，在使用实体类对象的时候，需要判断是否正确的获取到数据。 如果查询的是个别的字段，而使用的字段不在查询的字段中，就会无法获取到值。 建议的做法：按中台的思路，提供的查询方法是大而全的方法。提供对业务的支持。
2.测试的方法：查询数据提供了查库和查缓存的两种访问方式，但是访问的地址不同。 这样在做postman接口测试的时候，首先需要确认地址和端口是否正确。
3.开发接口的文档的维护的重要性，可以将版本号，变更内容和时间等维护上去，比如对接不同的供应商，每家的需求不同， 提供出去的是通用标准化的文档，但是每家对接的需求不同，哪些接口做了对接，哪些接口没有做对接，可以在文档中明确的标识出来， 方便日后的排查和回顾。时间长了，很多都很容易遗忘。代码注释同理。 对开发的总结，方便后续对接类似或相同需求的快速接入。避免每次都是需要从头开始梳理。
4.公共逻辑，底层逻辑的改动方法，首先需要考虑影响的上层调用的方法，接口。并且需要做测试覆盖和回归。警惕：非空逻辑的判断 并且不能在公共方法中抛出异常等，中断业务逻辑。公共逻辑更多的是做兼容并包的逻辑，而不是特立独行的逻辑。 如果是特立独行的逻辑，可以将公共逻辑抽象出来，具体的实现类来继承，个性化的逻辑在具体的实现类中来处理。 减少对公共业务逻辑的代码污染。
5.接口设计的兜底方案，比如：if elseif else {}，可以理解为最后一个else就是兜底，如果条件都不允许，则做兜底的逻辑。 比如获取经纬度城市名称，为了减少查询高德接口的次数，内部业务系统A在接收到业务系统B接口的数据，有数据用接口数据，没有数据，则业务系统A接口内部根据经纬度来反查城市名称。
6.公开化的接口或页面，方便发现问题（比如下单页面）。定时任务的接口等不容易发现，隐蔽性强。往往不容易发现的是更加需要警惕的。
7.代码的review和项目组内沟通，一个人开发视角的局限性，多人参与可以从不同的角度来分析，规避问题，避免上线后出现问题。
