避免滥用 @SuppressWarnings 的核心是主动管理风险而非消除黄线，应明确指定警告名、限制作用域、优先重构修复，并辅以白名单与运行时断言加固安全。
避免滥用 @SuppressWarnings 的核心，是把“压制警告”变成“主动管理风险”。它不该是清理黄线的快捷键，而应是经过判断后、有据可依的明确声明。
只抑制确认安全的特定警告
编译器警告不是噪音，而是分类提示：有的关乎风格（如 unused），有的直指运行时风险（如 unchecked、null、serial）。用 "all" 会一并屏蔽后者，等于主动关掉安全哨兵。
- 明确写清警告名，例如
@SuppressWarnings("unchecked")，而不是"all" - 只在你已人工验证过该段代码行为、理解警告成因、且确认无实际危害时才加
- 常见合理场景包括：对接老系统必须用原始集合、switch 中故意 fallthrough、测试中 mock 触发 resource 警告
作用域压到最小，不跨层传染
注解的作用范围决定风险边界。加在类或方法上，会让所有子元素继承这个“静音”，包括未来新增的、本该被提醒的代码。
- 优先放在单条语句或局部变量前（JDK 8+ 支持对变量使用）
- 其次放在方法上，且仅覆盖该方法内明确已知无害的警告
- 避免加在类、字段或接口上——尤其不能给 Service 类或 Controller 加
"all"
优先消除警告，而非压制警告
大多数警告背后都有可修复的编码改进点。压制只是临时方案，重构才是根本解法。
-
unused？删掉未使用的变量、参数或空方法 -
deprecation？升级到替代 API，或加版本判断做兼容 -
unchecked或rawtypes？补全泛型，如把ArrayList改成ArrayList<String> - 实在无法改（如反射调用）？用具体警告名 + 简短注释说明原因，例如：
// 已校验返回类型为 String，此处 unchecked 安全
配合白名单与运行时断言加固可信度
当静态分析工具（如 SonarQube）因动态拼接 SQL 标识符报误警时，单纯压制会弱化安全契约。此时应转向可验证的设计。
- 将表名、列名等限定为枚举或
final static常量 - 在
getTable()、getColumns()方法中加入显式校验，失败抛IllegalStateException - Javadoc 明确声明：“该方法仅返回白名单内标识符，已通过静态/动态双重校验”
