主要区别在MsgInterceptor跟ApiInterceptor这两个拦截器上

原来1.8版本，是下面的方式一次性将ApiConfig绑定到ThreadLocal

ApiConfigKit.setThreadLocalApiConfig(ApiConfig apiConfig)

需要ApiConfig的时候可以从ThreadLocal中一次取出

现在1.9的版本，是只将ApiConfig中的appId绑定到ThreadLocal

ApiConfigKit.setThreadLocalAppId(String appId)

需要ApiConfig的时候，根据绑定的appId再从Map中获取完整的ApiConfig。

当然这个Map需要在JFinal.afterStart中预先初始化，方法是：

ApiConfigKit.putApiConfig(ApiConfig apiConfig)

这么改进的用意还不太清楚，可能是减少了ThreadLocal的数据量，提高了性能

但在实际项目中很麻烦

主要有两点：

1、通常appId跟其他ApiConfig信息是保存一张表里，每个会话从数据库中获取appId跟获取整个ApiConfig没有区别

2、ApiConfigKit只能将appId作为获取ApiConfig的MapKey，非常不灵活。通常项目中，肯定会存在一个用户ID或者单位ID，这个ID才会贯穿项目始终，而ApiConfig表中的外键也会是这个ID，如果使用这个ID来作为MapKey来检索ApiConfig才更加符合要求。

说了这么多，其实就想将ApiConfigKit中的putApiConfig方法修改如下：

//当前1.9：
//public static ApiConfig putApiConfig(ApiConfig apiConfig) {...}
//修改后：
public static ApiConfig putApiConfig(String apiKey, ApiConfig apiConfig) {...}

很高兴1.9增加了智能硬件等新接口支持，但感觉ApiConfigKit部分1.8已经做的足够好了