支持从注解方法的返回类型进行反序列化

[visonforcoding]

目标是存入redis后的json 可以不包含类信息，可以做到跨语言共享缓存结构和防止类文件移动等问题造成缓存失效。

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ visonforcoding
❌ vison.cao

---

vison.cao seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[areyouok]

json不是一个通用的序列化方案，仅有root的类信息是无法反序列化的

[visonforcoding]

json不是一个通用的序列化方案，仅有root的类信息是无法反序列化的

所以PR的代码拿了被@cached注解的方法的返回类型进行了反序列化

[areyouok]

如果返回值定义的类型是Object呢？

[visonforcoding]

如果返回值定义的类型是Object呢？

@areyouok 定义Object确实会存在问题。但是这个是使用者行为，spring 的 @Cacheable 在使用StringRedisSerializer序列化方式时如果定义了非String返回也会异常。只要用户理解了api的姿势就能达到目的，当然姿势错误就会异常。底层满足这种需要存储无类json需求的能力就好，因为在我这边确实遇到跨语言的需求。虽然统一技术栈确实是最终期望的状态，但毕竟过渡阶段是要有的，并且项目历史包袱越大这过渡阶段就越长。

[areyouok]

如果返回值定义的类型是Object呢？

@areyouok 定义Object确实会存在问题。但是这个是使用者行为，spring 的 @Cacheable 在使用StringRedisSerializer序列化方式时如果定义了非String返回也会异常。只要用户理解了api的姿势就能达到目的，当然姿势错误就会异常。底层满足这种需要存储无类json需求的能力就好，因为在我这边确实遇到跨语言的需求。虽然统一技术栈确实是最终期望的状态，但毕竟过渡阶段是要有的，并且项目历史包袱越大这过渡阶段就越长。

这样对使用者要求太多了。业务方法返回值里面有list，map等容器是很常见的，里面可能是任何东西；容器套容器也很常见；或者反射读到返回值是类A，运行时是A的子类B。

你有需求的话，可以实现自己的SerialPolicy，而不是改JetCacheInterceptor要求别人都按你的方式来。