支付系统就一定需要对账，需要下载支付平台侧的账单与自己业务系统的交易数据时行对账。

微信账单：商户（支付通道）通过下载历史交易清单。比如掉单、系统错误等导致商户侧和微信侧数据不一致，通过对账单核对后可校正支付状态。

系统提供对外接口或公用方法时，通常需要对入参校验，即直接在接口入口层就进行校验，不让非法参数流入到业务层导致异常，确保系统的健壮性。。

数据校验分客户端校验和服务端校验，客户端校验主要在页面通过JavaScript来实现，过滤正常用户的误操作，仅做初步过滤；服务端校验是整个应用阻止非法数据的最后防线，客户端校验绝不能替代服务端的校验，客户端校验可以降低服务器的负载。

最近在做支付通道开发，需要对接微信和支付宝，银联，云闪付，各大银行等。

微信支付的开放接口对于开发者来说，相对支付宝并不那么友好，主要是有些小坑，开放文档描述的不够一致。

例如，同一个属性，返回的字段名与调起支付的字段名不一致，对开发者来说容易搞混。微信支付的 SDK 中定义为抽象的方法却使用 private 控制修饰符，导致外部不能重写。

最近在做支付通道开发，需要对接微信和支付宝，银联，云闪付，各大银行等。

微信支付的开放接口对于开发者来说，相对支付宝并不那么友好，主要是有些小坑，开放文档描述的不够一致。

例如，同一个属性，返回的字段名与调起支付的字段名不一致，对开发者来说容易搞混。微信支付的 SDK 中定义为抽象的方法却使用 private 控制修饰符，导致外部不能重写。

函数式接口 就是一个有且仅有一个抽象方法，但是可以有多个非抽象方法的接口（default 修饰），这又关联了 Java 8 的另一个新特性，允许在接口中定义默认方法（default 修饰）。

函数式接口是行为的抽象，是数据转换。其最直接表现是将函数（行为）作为数据传递进方式中。

函数式编程的一大好处，是可以用更精练的代码来表达常用数据处理。函数接口能够轻易地实现模板方法模式，只要将不确定的业务逻辑抽象成函数接口，然后传入不同的 Lambda 表达式即可。

整理这篇文章由两个因素引发：

• 一个是参与的微服务项目涉及到权限管理应用到了 HandlerMapping ，使用自定义注解，自动或手动拿到各个微服务所有自定义的 Controller RequestMapping（URI）同步到权限管理模块。

• 二是开发的项目报了异常，打印的异常信息比较有意思，就跟踪源码查到信息也是来自于 HandlerMapping，这些信息可以自己获取后应用在拦截器或 Controller 层的 AOP 中。

  备注：已使用 AOP 拿到类似到源码抛出的打印的异常信息，但没有源码抛出的异常信息完美优雅。

Java 多线程并发编程中，常用到两个关键字：synchronized 和 volatile，synchronized 是重量级锁，而 volatile 可以理解为轻量级的 synchronized ，但并不保证线程安全。

volatile 在并发环境中保证了共享变量的 可见性，即当一个线程修改一个共享变量时，另一个线程能读到这个修改的值。volatile 变量修饰符使用适当的话，相对于 synchronized 的使用和执行成本更低，因为它不会引起线程上下文的切换和调度。

多线程同时执行可以充分利用 CPU 的多核多线程功能来显著提高应用程序的性能，在多核环境中表现的更加明显（目前市面主流 CPU都是几乎都是多核多线程），即使单核 CPU 也支持多线程。

线程是操作系统调度的最小单元，CPU 通过给每个线程分配 CPU 时间片来实现多线程执行，时间片非常短（一般几十毫秒），通过不停切换线程来执行，给人的感觉是同时执行的。

创建 Spring Boot 应用，默认会添加 Maven 插件：spring-boot-maven-plugin。如果该应用的结构比较简单，使用默认的编译打包等，可以不用额外的配置。

若应用结构比较复杂，如父子工程，多层结构等；或要通过命令行动态指定打包方式等等，就需要额外的配置支持了。

该篇结合官方文档对 spring-boot-maven-plugin 的使用配置进行详细描述。另有的 Maven 相关文章，但不是针对 Spring Boot 和 插件的。

Spring Boot Maven Plugin 官网，Apache Maven 官网。

在 Windows 和 Linux 环境安装MySQL，记录下操作步骤。

官方资料：2.3 Installing MySQL on Microsoft Windows，2.5 Installing MySQL on Linux