Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
set CGO_CFLAGS=-g -O2
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\c-yan\AppData\Local\Temp\2\go-build235639566=/tmp/go-build -gno-record-gcc-switches
Expected to get 2684354560, the same value as before conversion.
What did you see instead?
I got 2684354600 which is different from before conversion. Since fmt.Printf can display correctly, I think it is a issue of encoding/json. If we do roughly the same thing in C#, GSon(Java), node.js, there is no issue.
This is not a bug. There's no way to distinguish float32(2684354560) and float32(2684354600) since they're exactly the same value. Go has to choose some serialization for them (which must be the same, since, again, they're the same value), and it picks one that as as-few-as-possible significant digits.
This behavior is generalized to float32s for Go's JSON parser: print as few non-zero digits as is needed to precisely identify the right float32. Note that reading the value back as a float32 reproduces the original float32. In float32 math, 2684354600 == 2684354560.
Similarly, in float64 math, 123456789123456789123 == 123456789123456800000.
If you want to distinguish between 2684354600 and 2684354560, the answer is to not use a float32 at all. Use a float64 instead. (In general a float32 has so little precision that it's almost never the right answer.)
I'd be happy to look at examples from other languages but almost all of them are probably operating on float64s, not float32s, either because the language doesn't have float32 at all or because the language does the C-like thing where float32s become float64s in most calls.