在小屏幕上，表格列数过多会导致布局没有对齐，文章整体出现横向滚动条。

以下是文章源文本

---
title: "Test"
date: 2022-09-19T20:22:50+08:00
draft: false
tags: []
categories: []
keywords: []
description: ""
---

### 小结

对于 jsonparser 来说相对标准库比较而言性能如此高的原因可以总结为：

1. 使用 for 循环来减少递归的使用；
2. 相比标准库而言没有使用反射；
3. 在查找相应的 key 值找到了便直接退出，可以不用继续往下递归；
4. 所操作的 JSON 串都是已被传入的，不会去重新再去申请新的空间，减少了内存分配；

除此之外在 api 的设计上也是非常的实用，ArrayEach、ObjectEach、EachKey 等三个函数都可以传入一个自定义的函数在实际的业务开发中解决了不少问题。

缺点也是非常的明显，不能对 JSON 进行校验，即使这个 传入的不是 JSON。

## 性能对比

**解析小 JSON 字符串**

解析一个结构简单，大小约 190 bytes 的字符串

|库名|操作|每次迭代耗时|占用内存数|分配内存次数|性能|
| --- | --- | --- | --- | --- | --- |
|标准库|解析为map|724 ns/op|976 B/op|51 allocs/op|慢|
||解析为struct|297 ns/op|256 B/op|5 allocs/op|一般|
|fastjson|get|68.2 ns/op|0 B/op|0 allocs/op|最快|
||parse|35.1 ns/op|0 B/op|0 allocs/op|最快|
|GJSON|转map|255 ns/op|1009 B/op|11 allocs/op|一般|
||get|232 ns/op|448 B/op|1 allocs/op|一般|
|jsonparser|get|106 ns/op|232 B/op|3 allocs/op|快|

解析一个结构简单，大小约 190 bytes 的字符串

|库名|操作|每次迭代耗时|占用内存数|分配内存次数|性能|
| --- | --- | --- | --- | --- | --- |
|标准库|解析为map|2292959 ns/op|5214009 B/op|95402 allocs/op|慢|
||解析为struct|1165490 ns/op|2023 B/op|76 allocs/op|一般|

综上，回到文章的开头中，对于我自己的业务来说，业务也只是简单的解析 http 请求返回的 JSON 串的部分字段，并且字段都是确定的，无需搜索功能，但是有时候需要做一些自定义的操作，所以对我来说 jsonparser 是最合适的。

xianmin / hugo-theme-jane

在小屏幕上，表格列数过多会导致布局没有对齐，文章整体出现横向滚动条。 #347