优先选泛型：类型确定、需编译安全、避免强转；Object仅适用于不关心类型、纯暂存过渡场景，但需自行承担ClassCastException风险。

选泛型还是 Object，关键看类型是否确定、是否需要编译期安全、是否涉及强转。泛型不是“更高级的Object”，而是为了解决Object带来的运行时风险而设计的编译期机制。

明确类型范围时，优先用泛型

当你知道操作的数据属于某个类或其子类（比如只处理 Number、String 或自定义接口实现类），就该用带边界的泛型，例如 > 或 。

• 编译器能立刻发现传入 File 却要求 Number 的错误
• 方法内部可直接调用 T 特有的方法（如 doubleValue()），不用强转
• 集合类（如 ArrayList）就是典型：存取都免强转，类型不混杂

仅需通用容器、不关心具体行为时，Object 也够用

某些底层工具或桥接场景中，你确实只需要“暂存一个东西”，后续由调用方自行判断和转换——这时用 Object 更直白，也不强制引入泛型语法。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 比如缓存层的 get(key) 方法返回 Object，因为缓存本身不理解业务类型
• 反射调用结果、序列化反序列化中间值等，常以 Object 作为过渡类型
• 但要注意：这类代码必须配套显式强转，且要自己承担 ClassCastException 风险

避免把 Object 当“万能解”，尤其在 API 设计中

对外提供的方法或类，如果用 Object 做参数或返回值，等于把类型责任全推给调用方。这会降低可读性，增加出错概率。

• 写工具类时，用 T parse(String json, Class type) 比 Object parse(String json) 更安全、更清晰
• 集合、回调、模板方法等场景，几乎总是泛型更合适——Java 标准库的 List、Function、Supplier 全是泛型就是证明
• 用 Object 硬扛多态，往往意味着设计没分层；该抽象接口的地方，别靠类型擦除硬凑

注意类型擦除带来的实际限制

泛型在运行时不存在，所以有些事它也做不到，这时候别怪它不如 Object “灵活”：

• 不能用 instanceof 判断 List —— 只能判断 instanceof List
• 不能写 new T[10] —— 因为 T 运行时是 Object 或上界类型
• 异常信息里看不到真实泛型参数 —— 日志或调试时只能看到原始类型

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南