有一次半夜处理线上事故，订单详情页大面积报“订单不存在”。查了大半天，最后定位到一行不起眼的JSON序列化配置：一个Long类型订单号在传到前端时被转成了Number，超过2^53的精度悄悄丢了，后端拿ID去查库当然查不到。那一刻我对“数据类型”这四个字的敬畏又深了一层——它不是课本里“int占4字节”那种概念，而是会直接在线上咬人的坑。
这篇文章我打算把“数据类型”这件事彻彻底底摊开讲一遍。适合三类人看：写过两三年代码但总在类型问题上翻车的；准备面试想系统补基础的人；还有带团队做代码评审、每天要看一堆类型相关bug的人。我会先从三组最容易被混淆的类型概念讲起，再拆解基本类型、复合类型、类型转换与序列化里的高频事故，最后从性能和排查的角度收尾。每一节都有代码、有场景、有真实踩坑记录，没有废话。
1. 先从三组基础概念说起：静态与动态、强与弱、值语义与引用语义
很多人把“数据类型”理解成一张简单的分类表：整数、浮点、字符串、布尔、数组、对象。这没错，但远远不够。真正决定代码质量和使用体验的，是三组更底层的概念：静态类型与动态类型、强类型与弱类型、值语义与引用语义。这三组概念如果你没理顺，后面所有细节都会变成一团浆糊。
1.1 静态类型和动态类型：不是“有没有类型”，而是“什么时候检查”
所谓静态类型，指的是类型信息在编译期就参与检查。C、Java、Go、Rust、TypeScript都属于这一类。你在代码里写int a = "hello"，编译阶段就会报错，根本跑不起来。动态类型则相反，Python、JavaScript、Ruby这类语言在运行时才会真正判断“这个变量到底是什么东西”，所以很多错误要等到执行到那一行才爆发。
我习惯用一个合同类比去理解：静态类型等于在签合同之前就把所有条款核对清楚，不允许有歧义；动态类型等于先把合同签了，后面每一步执行时再去验货，验不过就当场翻车。两种方式没有绝对优劣。动态类型带来了快速迭代、灵活拼接的便利，Python和JS写小工具或前端交互确实舒服；静态类型则给了大规模重构和多人协作更强的安全感，你一改方法签名，编译器会帮你把调用方所有不相容的地方都标出来。
这里有个常见的误区：很多人把TypeScript当成“JavaScript加了类型”，实际上更准确的说法是，TypeScript是在编译期给JS加了一层静态检查，编译产物运行时几乎不保留类型信息。换句话说，类型系统帮你拦了一部分错误，但没有从根本上改变JS的动态特性。理解这一点之后，你就不会对TypeScript报过高的期望——它能防你改错代码，但管不了运行时从接口里拿回来的数据长什么样。
1.2 强类型与弱类型：隐式转换是便利，还是隐患？
强类型与弱类型讨论的是另一个维度：语言在类型不匹配时，是拒绝操作，还是悄悄帮你做转换。经典的例子是字符串和数字相加。Python里"1" + 1直接抛TypeError，这通常被认为是强类型语言的表现；JavaScript里"1" + 1会得到字符串"11"，而"1" - 1会得到数字0，同一个运算符在不同位置行为不一样，这就是典型的弱类型特性。
Java和C#属于“半强半弱”的类型系统。比如Java中"1" + 1会把整数隐式转成字符串，得到"11"；但反过来1 + "1"也是"11"。这种设计为了字符串拼接的便利性，牺牲了一部分强类型的纯粹性。C语言更狠，整型和指针之间都可以做隐式转换，写坏了可以拿到一个随机地址的操作权限。
我的态度是：强类型不是“更好的类型”，它和弱类型是一个光谱，同一个语言在不同场景下表现也不同。真正重要的是团队是否有明确的约定。比如我在项目里默认禁止在Java中用String + int去拼业务字段，显式用String.valueOf()或格式化占位符；在JS里禁用==，一律用===；在Python里避免把True和数字做算术运算。这样语言本身的弱点就能被规范兜住。
1.3 值类型与引用类型：你复制的到底是数据，还是门牌号？
值类型和引用类型的差别，是“把东西本身给你”还是“把东西所在的地址告诉你”。在C语言里，int、结构体变量直接持有数据，赋值给另一个变量意味着复制一份完整的数据。Java和C#里，基本类型是值类型，而数组、对象、字符串这些全是引用类型，变量里存的只是堆内存里的一块地址。
用生活化的比喻来解释：值类型就像你把一本书复印了一份给朋友，后面你改自己的原版，朋友手上那份不受影响；引用类型则是你把自家的门牌号抄给朋友，朋友顺着门牌号进来把你家家具搬走了，你还得自己受着。写Java代码最常见的一个坑就是：方法里传入一个List或Map，方法内部clear()或者修改了某个字段，调用方的数据也跟着变了。很多人第一次遇到这种问题会怀疑自己的眼睛，其实这正是引用语义的天然行为。
所以“不可变对象”这个概念才会这么重要。Java的String不可变，所以你可以放心把它到处传递；BigDecimal不可变，计算时不用担心副作用；Java的Integer等包装类型也是不可变的，但注意它内部有缓存池，==比较时在-128到127这个范围会有特殊表现，这个细节放到后面讲。理解值语义和引用语义，是你判断“为什么这里要拷贝一份”“为什么这里要返回新对象”这类设计问题的基础。
2. 基本类型拆解：一个数字从声明到落盘，中间经过了多少道坎
基本类型看起来最简单，实际上最容易出事。整数有边界，浮点有精度，字符有编码，布尔有体积，空类型有语义。这一节我按类别逐一拆，每个都会配上真实项目里的反面教材。
2.1 整数：范围边界、溢出回绕与无符号陷阱
先看一张Java里整数类型的对照表：
| 类型 | 占用字节 | 范围 |
|---|---|---|
| byte | 1 | -128 ~ 127 |
| short | 2 | -32768 ~ 32767 |
| int | 4 | -2147483648 ~ 2147483647 |
| long | 8 | -9223372036854775808 ~ 9223372036854775807 |
C和Go里还有无符号版本，比如unsigned int、uint64，它们能表示更大的正数范围，但代价是没有负数。无符号带来的第一个坑是边界比较。举个例子，C语言里如果你写了unsigned int len = 100;，然后判断len - 200 > 0，结果会是真，因为负数被回绕成超大正数。这种问题在写循环、算偏移量时特别容易踩。
有符号整数也会溢出。Java中Integer.MAX_VALUE + 1的结果不是报错，而是变成了Integer.MIN_VALUE，这是二进制补码的“回绕”行为。我见过一个模拟项目X里写的循环：
for (int i = 0; i <= Integer.MAX_VALUE; i++) { // do something }这个循环看起来会跑很久，实际上它会死循环。因为当i等于Integer.MAX_VALUE时，i++会让它回绕成最小值，条件i <= Integer.MAX_VALUE恒为真，永远出不去。排查的人盯着代码看了半天，最后是打印i的值才发现这个问题的。
所以我的建议非常直接：业务上如果有时间戳、订单号、金额这类可能超过21亿的数值，一开始就用long，不要用int。很多老系统把时间戳存成32位整数，2023年还能跑，但等跨过某个界限就会产生越界问题，这种“延迟爆雷”最难受。金额场景则更严格：不要用浮点，用BigDecimal或整数分毫表示，这个下面细说。
2.2 浮点：为什么0.1加0.2永远算不对
浮点数的核心问题是：十进制小数在二进制里往往是无限循环小数，而浮点只能在有限位数内截断存储。你在屏幕上看到的0.1，在内存里是一个接近但不等于0.1的二进制分数。所以0.1 + 0.2的结果不是0.3，而是0.30000000000000004。
这不是Java的问题，也不是Python的问题，是IEEE 754这个浮点标准本身决定的。C、C++、Java、Python、JavaScript全都一样。只不过有些语言打印的时候自动做了舍入，让你误以为算对了，但一旦参与比较或者累加，误差就会积累。
真实案例太多了。某开发者写过一个对账模块，订单金额、税额、运费全部用double存储和计算。三个值加起来，和第二天的结算单总是差几分钱。排查到最后发现是每个月的统计里，浮点尾数在几千次加法中不断累积，最终在舍入点上爆发。幸好是在测试环境发现的，没有造成线上资金纠纷。
工程上正确的做法分两种：一种是精度要求高、业务规则明确的场景，比如金额、税率、积分换算，直接用BigDecimal（Java）或DECIMAL类型（数据库）或整数分厘制；另一种是科学计算、图像处理、统计采样这类本来就有误差预算的场景，用double没问题，但比较时记得用“差的绝对值小于阈值”而不是==。
浮点还有一个反直觉的点：NaN不等于自身。Java里Float.NaN == Float.NaN结果是false，这是IEEE 754钦定的语义。如果一个计算结果非法，比如0.0/0.0，你会得到NaN，而直接把NaN序列化进JSON还可能产生非法值。所以我在代码评审时看到浮点计算，都会加一句：先想清楚这个计算结果的精度预算是多少，再决定用哪种类型，不要凭感觉选。
2.3 字符、布尔与空类型：被低估的边界场景
char和boolean看起来人畜无害，坑也不少。
以Java为例，char是16位无符号整数，能表示Unicode基本多语言平面里的字符。但对补充平面里的字符，比如大部分emoji，需要两个char组成代理对才能表示。如果你按单个char去截断字符串，就可能把一个emoji从中间劈开，得到乱码。我曾经在某论坛的昵称处理代码里见过这个问题，用户昵称里带了个emoji，数据库存进去之后取出来，后半截直接变成不可见字符。正确的处理是直接操作码点（code point），Java用codePoints()，或者干脆用String.codePointAt这类API。
boolean和布尔值的坑主要在内存和序列化。Java的boolean在独立存储时可能占4个字节，boolean[]数组里每个元素占1个字节，看着好像不多，但在大规模缓存行扫描的场景里，这会让缓存命中率下降。更常见的坑是包装类Boolean：它可以是true、false，还可以是null。如果你从数据库或接口拿到的Boolean是null，直接拆箱赋值给boolean，Java会抛NullPointerException。这类问题通常通过静态检查和严格的分层校验去规避。
空类型我用个小标题单独讲，因为它是全行业最高发的运行时错误来源。Java有null，JavaScript有null和undefined，Python有None，Go有nil，Rust则干脆用Option<T>逼你显式处理“可能没有值”。我曾经帮一个朋友排查线上问题：后端接口返回了一个null的对象，前端代码里直接解构字段，导致整个页面白屏。后端开发说“我返回null是表示没有数据啊”，前端说“那你就不能返回一个空对象吗”，两边都有道理，但问题的根源在于类型系统没有把“可能为null”这件事显式表达出来。
现在Java推荐用Optional，但也不是银弹。Optional不该用来包装成员变量、不该作为方法参数，更不该被序列化器直接处理。它最合适的场景是“方法返回值明确告知可能为空”。真正的工程解法是养成防御性习惯：所有外部输入不可信，所有从数据库返回的字段都有为空的可能，所有JSON反序列化出来的对象都要校验关键字段。你可以在代码里约定一个“空值边界”：前端输入、DB查询、RPC返回值这三处必须做判空或使用Optional封装的类型。
3. 复合类型实务：数组扩容、字符串不可变、哈希表与空值语义
复合类型是日常开发的主战场。数组、字符串、哈希表，每个都藏着几道经典大坑。这一节不会讲太多理论，我把最影响实际效率的几个点挑出来说。
3.1 数组：固定长度下的扩容策略
静态数组在多数语言里长度固定，Java的int[]、C的数组、Go的数组都是。动态数组是语言库里封装出来的，比如Java的ArrayList、Go的slice，它们底层还是一块连续内存，只是帮你管理扩容。这里很多人会忽略扩容成本。
Java的ArrayList扩容策略是：容量不够时，新容量大约是旧容量的1.5倍；Go的slice在元素个数小于1024时按2倍扩容，之后按1.25倍增长。为什么要成倍扩容而不是每次只加一个位置？因为扩容涉及申请新内存、拷贝老数据，如果每次都只扩一点点，拷贝次数会很多。翻倍扩容能让总拷贝成本降到线性级别，均摊下来每次插入几乎都是O(1)，这就是“均摊复杂度”的思路。
实操中容易踩的坑是“在循环里往容器头部插入”。ArrayList.add(0, item)每次都会把后面所有元素挪一位，O(n)的插入，循环m次就是O(m×n)。某开发者写过一段日志去重逻辑，三万条数据往头部插，插完又去遍历，整个过程跑了十几秒。优化方式很简单：改用LinkedList（但它内存不连续、缓存命中差），或者反过来追加到尾部最后统一reverse，或者预分配足够容量避免扩容。
预分配是个非常划算的习惯。如果你知道数据量大概是十万条，就提前new ArrayList<>(100000)，少几次扩容拷贝，性能肉眼可见提升。Go的make([]T, 0, 100000)同理。别小看这行代码，在高频场景里它就是“快一倍”和“慢一倍”的区别。
3.2 字符串不可变与拼接陷阱
Java和Python的字符串都是不可变的。不可变的好处是安全、可缓存、线程安全，坏处是拼接时如果处理不当会大量创建临时对象。经典反面教材：
String s = ""; for (int i = 0; i < 100000; i++) { s = s + i; }每次+都会生成一个新的字符串对象，十万次循环可能产生十万个中间对象，触发多次GC，整体耗时可能从几毫秒膨胀到几秒。正确的做法是：
StringBuilder sb = new StringBuilder(); for (int i = 0; i < 100000; i++) { sb.append(i); } String s = sb.toString();Go里同样推荐strings.Builder，C#里推荐StringBuilder，JavaScript里如果拼接量特别大，可以先放进数组再join。这里顺便提一个底层细节：Java 9以后字符串的存储方式改成了按内容选择编码，纯Latin-1字符时用1字节存储，否则用UTF-16，JDK内部叫compact strings。这个优化的存在意味着你不需要自己去做“手动压缩字符串”这种愚蠢的操作，直接信任JVM就好。
字符串还有一个容易被忽略的坑是编码转换。任何一次从网络读取、文件读取、数据库读取，都伴随字节到字符的解码。如果你在团队里没有统一字符集约定，A同学用UTF-8写入的数据，B同学按GBK去读，页面就是一片乱码。我的习惯是把项目里的字符集约定直接写进工程规范：接口传输一律UTF-8，数据库连接串显式指定字符集，文件读写显式指定编码，绝不做隐式依赖。
3.3 Map的哈希与可变键：改完字段之后查不到数据
哈希表是复合类型里的重中之重。以Java的HashMap为例，它内部是数组加链表/红黑树的结构。查找时先对key做哈希，定位到某个桶，再在桶里用equals逐个比较。这意味着“哈希码”和“相等性”高度耦合：同一个对象，hashCode必须稳定，equals相等的对象hashCode也必须相等。
最常见的坑就是用可变对象做key。假设你有一个User对象，hashCode基于userId字段计算，你把一个User实例放进Map当key，之后修改了它的userId。这时候再去map.get(user)就找不到了，因为它的哈希值变了，而它在Map里所在的位置还是按旧哈希算出来的。这种现象让人非常困惑，因为对象明明还是那个对象。
解决方案只有一句话：用不可变对象做key，或者确保放入Map之后不再修改参与哈希计算的字段。字符串、Integer、Long这些都是天然的好key；自定义对象如果非要做key，最好设计成不可变类，或者只用“一旦创建就不再变”的字段参与hashCode。顺带提一下负载因子：Java默认0.75，意思是用到75%容量时就扩容重哈希。如果你大概知道数据量，初始化时指定容量能显著减少rehash次数。Go的map则完全没暴露容量接口，只能通过make(map[string]T, n)预留提示。
3.4 null、undefined与Optional：头号运行时错误的根源
复合类型里的空值问题，单独拿出来说是值得的。前面提过不同语言的空值表达不同，这一节讲讲防御方案。我的核心原则是：在分层边界上统一“空值协议”。
拿一个常见业务链路举例：数据库查询返回null→ ORM映射成Java对象的null字段 → Controller返回给前端JSON → 前端拿到null后访问属性。这一条链路上任何一环没做处理，都可能崩。我的做法是：
- 数据库层：能加
NOT NULL约束就加，尽量让空值没有机会进入。 - 服务层：从外部传入的对象一律视为“可能所有字段都是null”，先校验再使用。
- 返回值层：集合类返回空集合而不是null，否则调用方要写一堆判空；单个对象用
Optional表达可能为空。 - 前端层：接口契约里明确哪些字段可能为null，前端做兜底渲染。
我用过Java的Optional很多年，最后发现它最适合的地方就是方法返回值里表达“可空性”。一旦把它用于字段、参数、序列化对象，麻烦远比收益多。Go的nil则完全靠程序员自觉，所以团队规范里必须写明“函数返回nil时要有注释说明”，否则下一个接手的人大概率会漏判。Rust的设计在这个问题上是最干净的，编译器逼你写match或?，但代价是上手门槛高。工程上不需要追求完美的类型系统，只需要在自己使用的语言范围内把空值规则钉死，让别人不易犯错。
4. 类型转换、泛型擦除与序列化：三次典型事故复盘
这一节我选了三个真实发生过、且很有代表性的类型事故来讲。每一个都对应一类高频问题：隐式转换、泛型运行时的类型信息缺失、跨系统序列化时的精度漂移。
4.1 隐式转换与强制转换：编译过了，运行崩了
隐式转换最经典的教育案例是JavaScript：
console.log('1' + 1); // '11' console.log('1' - 1); // 0 console.log('1' == 1); // true console.log('1' === 1); // false同一个1，加号让它变字符串，减号让它变数字，==还做了类型转换。这种灵活性能写出一行很短的代码，但也会让类型错误藏得很深。我不止一次看到线上bug的根因是某个变量在某个分支里变成了字符串，然后参加了数字运算。
Java里的隐式转换相对温和，主要是“拓宽转换”和“窄化转换”。int到long是拓宽，安全；long到int是窄化，可能丢精度，编译期会警告。但真正危险的是包装类和基本类型之间的拆箱转换。看这段经典代码：
Integer count = null; int total = count + 10; // NullPointerExceptioncount + 10这行看起来人畜无害，编译器会先把count拆箱成int，然后做加法。因为count是null，拆箱直接触发NPE。你根本看不出异常发生的具体位置，因为它藏在一行“普通到不能再普通”的算术里。这种问题的排查效率极低，所以我在团队里定了一条规矩：所有从反序列化、数据库查询、远程调用返回来的包装类型，在使用前必须判空或显式转换为基本类型。
4.2 泛型擦除：为什么重载会冲突，为什么运行时类型信息会丢失
Java泛型是“编译期魔法、运行期裸奔”。List<String>和List<Integer>在编译时是两种不同形态，经过编译后泛型信息被擦除，运行时它们都是同一个List类。所以下面的代码是典型的编译错误：
void process(List<String> list) {} void process(List<Integer> list) {}看起来是两个重载，实际运行时参数类型信息已经没了，JVM根本没法区分。
泛型擦除带来的连锁反应：你不能写list instanceof List<String>，因为运行时不知道泛型参数；你无法获取List<String>的泛型类型对象，除非借助TypeReference这类技巧。常见的框架解决方案是TypeToken模式，比如JSON反序列化时用new TypeReference<List<Order>>() {}传递泛型类型，本质上是利用匿名子类保留了泛型超类的类型参数信息。这一点是Java和C#的重要差异：C#的泛型在运行时是真实存在的，类型信息不会丢失。
Go在1.18版本引入了泛型，但设计思路完全不同，它是“类型参数”模型，语法上面向集合、容器、通用算法更直接。无论是哪种语言，我给团队的建议都一样：不要在运行时过度依赖泛型类型信息做分支判断，涉及类型分发的场景，显式传递一个Class参数或用类型开关（type switch/模式匹配）是更稳的做法。
4.3 序列化中的类型漂移：一次线上事故复盘
最后这个案例我印象特别深。某模拟项目X里有个订单查询接口，返回的订单号是Long类型，数据库主键。测试环境一切正常，上线后用户反馈：部分订单点开详情就报“订单不存在”。排查流程是这样的：
第一步，复现。发现只有订单号大于某个值的订单会出问题。第二步，抓接口原始返回。发现订单号在JSON里显示成了一个奇怪的数字，比如9007199254740993变成了9007199254740992。第三步，查根因。订单号经过Jackson序列化后以JSON Number的形式输出，前端JavaScript解析时用的是Number类型，超过2^53的整数精度就丢了，后端的ID和前端拿到的ID对不上。第四步，修复。订单号这类大整数在前后端传输时统一转成字符串，前端用字符串传递ID，不做数字运算。
这个案例给了我们一条普适经验：序列化会改变类型的用户感知。JSON规范里数字没有区分int和long，很多解析器（尤其早期的一些JSON库）会把所有数字都解析成double，于是大整数在反序列化过程中就变成了浮点，精度当场蒸发。如果你用的是Go标准库，这类问题特别容易遇到。处理方案是：在JSON解析时指定使用json.Number或自定义类型；在Java里给Long字段加@JsonSerialize(using = ToStringSerializer.class)；在接口契约设计上，凡是超过16位十进制整数的字段，一律按字符串处理。
序列化类型漂移还有一个反向案例：某系统从接口读取一个“可能是整数也可能是字符串”的ID，前端按自己的习惯传了字符串，后端反序列化的字段却是Long类型，于是解析失败。接口契约不明确就会滋生这类问题。我的习惯是，类型一致性要写进接口设计文档，并且每次联调前先跑一遍类型双向校验。别觉得这是小题大做，一个Long变Number的事故，够一个技术团队熬夜一天。
5. 性能视角与排查手段：从堆内存、拆装箱到一条自查清单
类型选择不只影响正确性，还直接影响内存占用和CPU开销。这一节我把从性能角度和排查角度的经验合在一起讲，最后落成一张可以贴墙上的自查清单。
5.1 对象头、对齐与缓存行：类型决定了内存布局
同样是“存100万个坐标”，用double[]和用List<Point>内存占用完全不同。Java对象有对象头（Mark Word、类型指针，可能还有数组长度），再加上数据本身和内存对齐，一个简单的Point对象可能占32字节以上，而一个double[]数组里每个double只要8字节。当数据量大到上百万时，对象数组的额外开销是赤裸裸的倍数差距，GC压力也随之升高。所以高性能数据处理场景的共识是：优先用基本类型数组或连续内存结构，而不是一堆小对象。
缓存行是这个问题的暗面。CPU读取数据是按缓存行（常见64字节）批量加载的，如果你遍历的是一个连续数组，第一次加载就能把后面几个元素也带进缓存，遍历速度飞快；如果你遍历的是散落在堆里的对象链表，每次读取都可能触发一次缓存缺失，速度差可能达到数倍。这也是为什么很多性能优化会把数据结构从“对象数组”改成“数组对象”——也就是把多个字段分别放在各自的连续数组里，用索引关联。
C#在这个方向上走得很远，提供了struct、record struct这些真正的值类型，让你能把对象放在栈上或内联进数组。Go也有结构体数组，内存连续。Java虽然长期只有引用对象，但实验项目里也用Value Class做探索。普通业务系统当然不需要天天琢磨缓存行，但当你发现某个核心路径GC频繁、吞吐上不去时，先把对象模型改成数组或扁平结构，往往比调一堆JVM参数有效得多。
5.2 拆箱装箱与隐式对象创建
拆箱装箱是Java和C#里特别常见的隐性开销。每次int转Integer叫装箱，Integer转int叫拆箱。前者会创建对象，后者可能触发NPE。看这个例子：
Integer sum = 0; for (int i = 0; i < 1000000; i++) { sum += i; }每次sum += i都会把sum拆箱、相加、再装箱，一百万次循环就产生一百万次临时Integer对象，触发大量GC。表面看代码很普通，压测时这部分会成为热点。解决办法是把累加变量改成基本类型的int，需要包装时最后再转。
Java的包装类型还有一个缓存池机制：Integer从-128到127会被valueOf复用，同一个对象缓存实例。所以Integer a = 127; Integer b = 127; a == b是true，但Integer a = 128; Integer b = 128; a == b是false。这是无数人踩过的陷阱。用==比较包装类本身就是错误姿势，正确做法是equals或者直接转成基本类型再比较。我在代码评审时看到包装类型的==比较，一定会打回去。
顺带说一个日志打印的隐性开销。很多人写log.info("count=" + count)，当这条日志被禁用时，字符串拼接还是照常执行了，白花CPU。正确做法是使用占位符，比如log.info("count={}", count)，让日志框架决定是否需要真正格式化。这不算类型问题，但属于“隐性类型转换导致的开销”范畴，值得一起提。
5.3 类型事故定位思路与自查清单
最后分享一套我自己反复使用的定位思路，专门针对“数据对不上”“类型报错”“线上偶发怪异行为”这类问题。
第一步，先画数据链路。确定数据从哪个环节开始变形的：数据库 → ORM实体 → 服务层 → 序列化 → 网络传输 → 前端解析。这中间每一层都可能发生类型转换。
第二步，逐层打印类型和值。不要凭脑子推断，直接在出错位置打印变量的运行时类型。Java用getClass()，Go用reflect.TypeOf，Python用type()，JavaScript用typeof。很多时候你打印出来后会发现，你以为的Long，实际已经是String；你以为的int，实际已经变成float64。
第三步，对照下面这张自查清单过一遍：
| 检查项 | 建议做法 |
|---|---|
| 金额类字段 | 用BigDecimal或整数分毫，禁止浮点存储 |
| 大整数ID跨系统传输 | 统一用字符串，禁止依赖Number精度 |
| 浮点比较 | 用阈值比较，不用== |
| Map/Set的key | 使用不可变对象，修改字段后不允许再当key |
| 包装类拆箱 | 先判空再拆箱，避免隐性NPE |
| 字符串循环拼接 | 用StringBuilder或BufferedWriter |
| JSON解析数字 | 大整数使用自定义类型或字符串字段 |
| 集合返回值 | 返回空集合，不要返回null |
| 循环内装箱拆箱 | 累加变量用基本类型，避免创建中间对象 |
| 接口契约 | 明确字段类型，Double/Long/String三选一，别留模糊地带 |
我把这张清单贴在团队项目的文档首页。每次有人写代码时，先花十分钟过一遍类型，就能省下未来排查问题的一整夜。为什么这么说？因为所有类型事故的修复成本都极低，一行代码的事；但定位成本极高，可能要从凌晨一点排查到天亮。类型设计上多花十分钟，排查事故时少熬一晚上，这个帐怎么算都划算。
