本文主要关注所解析的 JSON 对象与已定义的 java 对象结构不匹配的情况，解决方案就是使用 JsonDeserializer 来自定义从 JSON 对象到 Java 对象的映射。

一个简单的例子

有如下 JSON 对象，表示一本书的基本信息，本书有两个作者。

1
2
3
4
5
6

{
  'title':    'Java Puzzlers: Traps, Pitfalls, and Corner Cases',
  'isbn-10':  '032133678X',
  'isbn-13':  '978-0321336781',
  'authors':  ['Joshua Bloch', 'Neal Gafter']
}

这个 JSON 对象包含 4 个字段，其中有一个是数组，这些字段表征了一本书的基本信息。
如果我们直接使用 Gson 来解析：

1

Book book = new Gson().fromJson(jsonString, Book.class);

会发现 ‘isbn-10’ 这种字段表示在 Java 中是不合法的，因为 Java 的变量名中是不允许含有 ‘-‘ 符号的。
对于这个例子，我们可以使用 Gson 的 @SerializedName 注解来处理，不过注解也仅限于此，遇到后文的场景，注解就无能为力了。
这个时候，就是 JsonDeserializer 派上用场的时候。

使用浏览器调试 http 缓存头的时候，有一些需要注意的地方。一个显著的问题是刷新（F5）或者地址栏输入网址方式（Enter）访问页面，所有请求都会自动设置 Cache-Control:max-age=0。
如果是强制刷新（SHIFT + F5）的方式，所有请求都会自动设置 Cache-Control:no-cache。

另外，控制台（Network）也有一个 “disable cache” 的选项，需要注意。

启用 stale-while-revalidate 扩展，这个需要通过 chrome://flags 设置，将 stale-while-revalidate 设置为 enable。

如果需要在浏览器里面去掉这个强制设定的“Cache-Control:max-age=0”，可以使用 ajax 来发起请求，或者使用页面内链接的方式访问。
比如直接设置 a 标签的 href，这个时候浏览器就不会设定 max-age=0 了。

你知道 0x7C00，这个在 x86 汇编中的一个神秘数字吗？
0x7C00 是一个内存地址，BIOS 就是将 MBR (Master Boot Record, hdd/fdd 的第一个 sector) 读入 0x7C00 这个地址，
然后进行后续引导的。

操作系统或是 bootloader 的开发者必须假设他们的汇编代码被加载并从 0x7C00 处开始执行。
不过，为什么在 x86 中 BIOS 要将 MBR 加载到 0x7C00 呢？在回答这个问题之前，我们还有几个疑惑：

第一个疑惑：

我翻阅了所有的 Intel x86(32bit) 编程手册，都没有找到 0x7C00 这个数字。

没错！0x7C00 不是 x86 CPU 里面的定义，你当然不可能在 cpu 文档里面找得到。那么你就要问了，“那是谁定义了 0x7C00？”

第二个疑惑：

0x7C00 的值等于 32KiB - 1024B，这个数字表示什么意思？

不管是谁定义了 0x7C00，他/她为何要定义这样一个奇怪的数字？

这个问题的关键是明确“传值调用（Call by value）”与“传引用调用（Call by reference）”的定义。

简单来说：

“传值调用”是将值（values）作为函数参数传入；
“传引用调用”是将变量（variables）本身作为函数参数传入；

一个隐喻：

“传值调用”是我在纸片上写下一些内容并把纸片交给你， 内容可以是一个URL，也可能是一份完整的《战争与和平》副本。
不管是什么，现在都在我给你的那张纸上，所以它实际上是你的纸。你可以在那张纸上随便涂鸦，也可以通过那张纸找到别的什么东西。

“传引用调用”是当我在我的笔记本上写了一些内容然后把笔记本递给你。
你可以在我的笔记本上涂鸦（也许我想要你这么做，也许我没料到你会这么做），然后我保留我的笔记本，你的任何涂鸦也一并保留在笔记本里。
此外，如果你或我写的是有关如何找到其他内容的信息，无论你或我可以去那里，更改这些信息。