一个泛型参数没写对，整条调用链全崩了。上周三下午，同事在群里甩了张编译报错截图，一行红字刺眼得很：type argument String is not within bounds of type-variable T。他写了个工具方法，签名大概是 <T extends Number> void sum(List<T> list)，结果调用时传了 List<String>。编译器直接拦下来，没让代码跑起来——这算是运气好的。
泛型漏洞最阴的地方在于：它经常不在编译期发作，而是拖到运行时才给你一闷棍。Java 的类型擦除是罪魁祸首。你写 List<String> 和 List<Integer>，编译后都变成 List，泛型参数被抹掉了。JVM 根本不看你当初声明的是什么类型。于是有人钻空子，用反射往 List<Integer> 里塞了个字符串。编译器管不着，运行时也不一定立刻报错。等你遍历取值、做运算的时候，ClassCastException 才跳出来。堆栈指向的那一行，离真正出问题的地方可能隔了十几个方法调用。
我见过更离谱的。一个老项目里有人写了 Map<String, Object> 来存配置。某天另一个同事觉得 Object 太宽泛，改成 Map<String, String>。IDE 重构一路绿灯，编译通过。上线后半夜告警，某个 value 原本存的是 List<String>，取出来强转 String 直接炸了。问题出在泛型只约束了编译期的静态类型，那个 List 是运行时通过反射塞进去的，改签名根本不影响已经存在的字节码逻辑。
C++ 模板那边是另一回事。模板在编译期展开，类型不匹配根本过不了编译。听起来更安全？但模板报错信息能刷满三屏，嵌套三层模板元编程之后，错误信息指向的位置和实际问题常常差着十万八千里。我见过一个 std::sort 的调用，因为比较函数签名写错，编译器吐了 200 多行错误，第一行指向 <algorithm> 内部某处。新手看到直接懵了。这算不算漏洞？编译器没放过错误，但错误信息的可读性差到让人怀疑人生。
Go 1.18 引入泛型的时候，社区吵了很久。有人担心类型约束太复杂，有人觉得干脆别加。现在看，Go 的泛型实现相对保守，类型参数必须满足接口约束，运行时也没有类型擦除那套把戏。但代价是表达能力受限，写不出 Java 那种通配符嵌套的花活。这反而少了很多坑。我个人的观察：泛型越灵活的语言，泛型相关的漏洞和误用就越多。Scala 的型变注解 +T -T 写错一个符号，编译能过，运行时行为完全跑偏。那玩意儿调试起来，比追一个空指针还累。
说到底，泛型漏洞的根子不在泛型本身，在于类型系统给不了你所有保证。编译器能查的它查了，查不了的留给运行时。中间那段灰色地带，全靠写代码的人自己兜着。反射、类型擦除、型变、模板特化——每一个特性都是双刃剑。用之前先想清楚：这个类型参数，到底约束的是编译期还是运行期？想不明白，就等着半夜被叫起来修 bug 吧。