“串”引用
直接get set 容易踩坑
对于外围系统返回的结果，有至少4种情况的判断（成功、失败、重复调用、未知异常）
对于资金处理的返回结果，是否检查了金额、状态等关键要素
单位约定要清晰
业务失败必须实现回滚
并发与幂等控制（业务正确性）
静态util与单例必须是【线程安全】的
并发处理必须遵循：一锁、二判、三更新的规范
缓存刷新与业务处理并发时，是否影响业务正常处理
给出以什么单号做幂等性控制，确定调用方法是否可以以此单号做幂等性控制
给出接受到重复调用后，返回的错误码，确定调用的方法没有把此错误当做错失败处理？
给出【幂等性】的底层机制，并确定底层机制确实存在，且抛出的异常正确处理
对于分布式事务，需要考虑事务悬挂的各种场景：TX_ID相同、不同；幂等控制条件相同、不同相关场景的组合
调用外围系统、机构或商户的接口是否具备幂等性控制能力，并且自身已经处理了幂等的场景
稳定性
内存：
Profiler#enter，release必须成对调用，而且必须finally至需要增加release
线程上下文变量的设置与清除必须配对（必须在最初使用之前相应的finally中进行清除）
对于线程，线程资源必须通过线程池提供，不允许在应用中自行显式创建线程
缓存刷新失败是否影响业务逻辑
不建议在业务处理过程中刷新缓存
是否存在堆外内存溢出 （NIO JDNI使用尤为注意）
对于文件、流的 IO 操作，必须通过 finally 关闭
参数设置
session 清空与超时
超时（客户端、服务端）
连接数/线程池（客户端、服务端）
JVM参数
db存储操作
数据锁（死锁）: 为记录加锁时，需要保持一致的加锁顺序，否则可能会造成死锁
不建议循环操作DB
数据库等存储热点
连接风暴
SQL语句查询条件中是否包含索引字段
批量处理
批量处理注意控制处理频率，同时需要考虑多台机器并发处理同一批记录的问题，避免集群处理并发量造成对外围系统冲击
批量处理逻辑，必须增加数量限制
并发处理批量更新流水时，是否在Sql的where条件中增加了原有流水的状态，且检查了updata方法返回的记录条数是否满足预期
并发锁是否合理，在吞吐量范围内是否会造成请求积压
一致性处理
对于业务逻辑上要求数据完整性的数据（例如同事操作多个表，对同一个表反复操作等），必须采用事务的方式进行处理
对于重要消息必须在事务内采取可靠消息模式
兼容性
是否已考虑了发布过程中新老数据老服务、老数据新服务相关场景的兼容处理
异常考虑
四舍五入，精度是关键
最外层的业务使用者，必须处理异常，将异常转化为用户可以理解的内容
短信多发也是一种资损
对于日志的打印，任何情况都不允许日志的错误导致业务失败