方法返回值不应使用泛型通配符（如list），因其削弱类型安全性、限制调用方操作且违背泛型初衷；应改用具体类型（如list）、必要时用上界通配符（如list
这个提示的核心意思是：**方法返回值中不应使用泛型通配符（如 List>、Map, ?>）**，因为这会削弱类型安全性，让调用方无法准确获知实际元素类型，也违背了泛型设计的初衷。
为什么 SonarQube 反对通配符作为返回类型
通配符（?）表示“未知具体类型”，适用于消费场景（比如方法参数），但不适合作为对外暴露的契约。返回 List> 相当于告诉调用方：“我给你一个列表，但你不知道里面是什么”——调用方只能做有限操作（如 size()、isEmpty()），无法安全地添加或强转元素，反而容易引发运行时异常或强制类型转换风险。
推荐的替代方案
-
明确具体类型：如果业务逻辑能确定返回内容的统一类型，直接写死泛型参数。例如返回用户列表，就用
List<user></user>，而不是List>。 -
使用上界通配符（
? extends T）仅当必要且合理：比如工具方法需兼容子类，且只读取不修改，可返回List extends Number>。但注意：它仍不能作为通用返回契约，应配合 Javadoc 明确语义。 -
封装为专用返回类型：若需返回多种可能类型（如不同 DTO 的集合），定义一个包装类（如
ApiResponse<t></t>），让方法返回ApiResponse<user></user>或ApiResponse<order></order>，既保持类型安全，又提升可读性与可维护性。 -
避免“擦除式”设计：不要为了“通用”而返回
Object或原始类型（如List），SonarQube 同样会报Raw types should not be used；也不要用List<object></object>替代，它不代表任意类型，只是装Object实例。
常见错误写法与修正示例
❌ 错误（触发警告）：
public List> getUsers() { return userDao.findAll(); }
✅ 修正（明确类型）：
public List<user> getUsers() { return userDao.findAll(); }</user>
✅ 或（有明确上界且只读）：
public List extends Person> getPeople() { return personService.loadAll(); }
注意：后者需确保所有返回对象都继承自 Person，且调用方确实只需读取属性（如 getName()），不执行 add() 等操作。
补充建议
- 检查是否误将 DAO 层返回的原始
List直接暴露给 Service 或 Controller 层——应在中间层完成类型收敛。 - 若使用 MyBatis 等框架，其
selectList()返回List>是框架内部设计，不应直接作为业务方法返回值；应包装后再返回具体泛型类型。 - 团队可将该规则设为
Critical级别，在质量门禁中拦截，避免此类松散契约流入主干。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
