CodePlayer

**Additional note**: After comparative testing, we found that this issue occurs only when `useServerPrepStmts=true` is enabled. However, MySQL still returns correct results even with this parameter enabled.

这是特性，设计如此。 你设置了 `WriteClassName`，那么 Fastjson 就会将属性的**类型信息**序列化进去，这样反序列化时才会自动恢复为正确的类型。 附加一个 L 就是便于 `Long` 类型和 `Integer` 等其他整型进行区分，而且占用的额外存储空间也不大。 如果是自定义类型，则是添加一个 `@type` 属性，其值即为完整的类型名称，例如 `package.to.ClassName`。

> @CodePlayer 希望再来个特性，能控制它的关闭：）。。。有些场景下，需要与其它框架的互通性 如果要与其他框架互通，那你就不应该使用 `WriteClassName` 这种序列化方式。 这不只是 `Long` 类型的 `L` 后缀问题，其他框架也不一定能支持 `"@type"` 这种自定义类型识别呀。 感觉你考虑的实现思路有些误入歧途。如果要实现不同序列化框架之间的互通： 1. 最好都使用**相同**的组件，这样就没有实现上的差异 2. 如果不能使用相同的组件，那么就使用**与单一框架无关**的协议来通信。如果两边对数据类型都是**已知**的，那在传输过程中就不必附加这种类型信息，你不需要设置 `WriteClassName`，直接传输 纯数据 JSON，接收方自行反序列化为已知的类型即可 。 3. 如果数据类型对双方是**不确定**的，那么必须用一种两边**都能识别**的方式来传递数据类型信息。具体如何实现，得取决于你的实际情况。

> @CodePlayer 非你所想。。。大多 json 框架，都有 WriteClassName 类似的特性，都可以有 `@type` 属性。 你可以说说大多数JSON框架是哪些呢 ？ 类似的特性肯定都有，但是并没有统一约定为 `@type` 这个Fastjson使用的的类型属性名称。 也就是 JSON框架 **默认**并不是互通的，**本质上就是，如何保存序列化对象自身的类型信息，在 JSON 框架领域并没有一个统一的标准**，不然大家都会遵循规范统一实现了。 当然，结合框架的自定义功能设置，我们还是可以将不同框架的 类型 属性名称 调整为相同的。 至于 L，你也可以设置 `JSONWriter.Feature.WriteLongAsString` 将 Long 值序列化为字符串。 最后，无论如何，其他...

@like520-WQ 看这个注释，使用的是 LPGL 协议，只要不修改源代码，商业项目使用应该也没什么风险吧 ？

我们也遇到了这个问题。 我们使用的是 Nacos 2.5.1 + Log4j 2.25.2 版本，应用启动时，会执行调整日志配置的代码： ```java final LoggerContext ctx = (LoggerContext) LogManager.getContext(false); final Configuration config = ctx.getConfiguration(); for (LoggerConfig cfg : config.getLoggers().values()) { if (cfg.getLevel().compareTo(Level.INFO) > 0)...

@JGoP-L 我们目前还是 Nacos 2.5.x，没有升级到最新的 3.x（服务端还是 2.x，担心只升级客户端会不兼容），所以还没有升级。 > **我们的临时解决方案**: > > -Dnacos.logging.reload.interval.seconds=31536000 # 1 年（实际上相当于禁用） 🙏 我们目前也是如上调整定时任务的间隔时间来规避的 。 等后续升级验证后，再来回复。 大多数应用应该没有热更新配置文件的需求，不知道能不能搞一个开关来关闭这个定时任务。

先设置这个： ```java JSON.configWriterDateFormat("millis"); ``` [官方文档](https://github.com/alibaba/fastjson2/wiki/fastjson_1_upgrade_cn)里也有说明哦：