优先选泛型：类型确定、需编译安全、避免强转；Object仅适用于不关心类型、纯暂存过渡场景，但需自行承担ClassCastException风险。
选泛型还是 Object，关键看类型是否确定、是否需要编译期安全、是否涉及强转。泛型不是“更高级的Object”，而是为了解决Object带来的运行时风险而设计的编译期机制。
明确类型范围时，优先用泛型
当你知道操作的数据属于某个类或其子类（比如只处理 Number、String 或自定义接口实现类），就该用带边界的泛型，例如 <t extends comparable>></t> 或 <v extends user></v>。
- 编译器能立刻发现传入
File却要求Number的错误 - 方法内部可直接调用
T特有的方法（如doubleValue()），不用强转 - 集合类（如
ArrayList<string></string>）就是典型：存取都免强转，类型不混杂
仅需通用容器、不关心具体行为时，Object 也够用
某些底层工具或桥接场景中，你确实只需要“暂存一个东西”，后续由调用方自行判断和转换——这时用 Object 更直白，也不强制引入泛型语法。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 比如缓存层的
get(key)方法返回Object，因为缓存本身不理解业务类型 - 反射调用结果、序列化反序列化中间值等，常以
Object作为过渡类型 - 但要注意：这类代码必须配套显式强转，且要自己承担
ClassCastException风险
避免把 Object 当“万能解”，尤其在 API 设计中
对外提供的方法或类，如果用 Object 做参数或返回值，等于把类型责任全推给调用方。这会降低可读性，增加出错概率。
立即学习“Java免费学习笔记（深入）”；
- 写工具类时，用
<t> T parse(String json, Class<t> type)</t></t>比Object parse(String json)更安全、更清晰 - 集合、回调、模板方法等场景，几乎总是泛型更合适——Java 标准库的
List、Function、Supplier全是泛型就是证明 - 用
Object硬扛多态，往往意味着设计没分层；该抽象接口的地方，别靠类型擦除硬凑
注意类型擦除带来的实际限制
泛型在运行时不存在，所以有些事它也做不到，这时候别怪它不如 Object “灵活”：
- 不能用
instanceof判断List<string></string>—— 只能判断instanceof List - 不能写
new T[10]—— 因为T运行时是Object或上界类型 - 异常信息里看不到真实泛型参数 —— 日志或调试时只能看到原始类型
