前言最近在持续优化之前编写的 JSON 解析库 xjson，主要是两个方面的优化。 第一个是支持将一个 JSONObject 对象输出为 JSON 字符串。 这点在上个版本中只是利用自带的 Print 函数打印数据： 12345678func TestJson4(t *testing.T) { str := `{"people":{"

原文链接 在日常使用 Goland 时，团队收集了一些可以帮助我们专注于创造的同时减少重复工作的小技巧。如果你是在 IDEA 中使用的 Go 插件，或者其他 IntelliJ 的产品，同样也有这些特性。

前言在上一篇中介绍了 xjson 的功能特性以及使用查询语法快速方便的获取 JSON 中的值。 同时这次也更新了一个版本，主要是两个升级： 对转义字符的支持。 性能优化，大约提升了30%⬆️。

前言在之前实现的 JSON 解析器中当时只实现了将一个 JSON 字符串转换为一个 JSONObject，并没有将其映射为一个具体的 struct；如果想要获取值就需要先做断言将其转换为 map 或者是切片再来获，会比较麻烦。 12345decode, err := xjson.Decode(`{"glossary":{"title":

前言之前在写 gscript时我就在想有没有利用编译原理实现一个更实际工具？毕竟真写一个语言的难度不低，并且也很难真的应用起来。 一次无意间看到有人提起 JSON 解析器，这类工具充斥着我们的日常开发，运用非常广泛。 以前我也有思考过它是如何实现的，过程中一旦和编译原理扯上关系就不由自主的劝退了；但经过这段时间的实践我发现实现一个 JSON 解析器似乎也不困难，只是运用到了编译原理前端的部分知识

前言最近又在重新学习编译原理了，其实两年前也复习过，当初是为了能实现通过 MySQL 的 DDL 生成 Python 中 sqlalchemy 的 model。 相关文章在这里：手写一个词法分析器

背景前段时间同事碰到一个问题，需要在 SpringCloud 的 Feign 调用中使用自定义的 URL；通常情况下是没有这个需求的；毕竟都用了 SpringCloud 的了，那服务之间的调用都是走注册中心的，不会需要自定义 URL 的情况。

前言大概在两年前我写过一篇 撸了一个 Feign 增强包，当时准备是利用 SpringBoot + K8s 构建应用，这个库可以类似于 SpringCloud 那样结合 SpringBoot 使用声明式接口来达到服务间通讯的目的。

背景许久没有分享 Java 相关的问题排查了，最近帮同事一起排查了一个问题： 在使用 Pulsar 消费时，发生了同一条消息反复消费的情况。

介绍我猜测大部分长期使用 Java 的开发者应该较少会接触 gRPC，毕竟在 Java 圈子里大部分使用的还是 Dubbo/SpringClound 这两类服务框架。 我也是近段时间有机会从零开始重构业务才接触到 gRPC 的，当时选择 gRPC 时也有几个原因： 基于云原生的思路开发部署项目，而在云原生中 gRPC 几乎已经是标准的通讯协议了。 开发语言选择了 Go，在 Go 圈子中 gR