该用，但需分场景：适合方法入口和构造函数的null断言，避免在循环、分支逻辑或已有判空处滥用；Optional不能自动防NPE，慎作字段和参数；字符串判空优先用isEmpty()或"".equals(str)；Map取值需区分null语义。
Java里Objects.requireNonNull该不该用？
该用，但得看场景。它适合明确“此处绝不允许null”的断言点，比如方法入口参数校验、构造函数初始化。不是所有地方都适合——比如你只是想安全取值或默认兜底，硬塞requireNonNull反而让逻辑变重、堆栈变深。
常见错误现象：NullPointerException在深层调用才抛出，排查困难；而提前用requireNonNull能把问题卡在第一现场。
- 别在循环体里反复调用，有性能开销（哪怕很小）
- 和
@Nullable/@NotNull注解配合用，IDE才能联动提示 - 如果后续逻辑本来就要判空走分支，就别先用
requireNonNull再try-catch——这是典型叠床架屋
用Optional包装返回值真能防NPE吗？
不能自动防，只能帮你「显式表达可能为空」。很多人误以为用了Optional就万事大吉，结果写出optional.get()这种和直接解引用null没区别的代码。
使用场景：适合做API返回类型（如findById），或链式转换（map/flatMap）；不适合当字段类型、不建议用于参数传递。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
Optional.of(null)会立刻抛NullPointerException，要用Optional.ofNullable - 别用
isPresent() + get()写法，优先用orElse、orElseGet或ifPresent - 序列化框架（如Jackson）对
Optional支持不一，生产环境慎作DTO字段
字符串判空为什么不用str == null || str.equals("")？
因为str.equals("")在str为null时直接炸。这是最常踩的坑之一，尤其从Python转过来的同学容易惯性写错。
正确姿势是把字面量放前面："".equals(str)，或者用工具类——JDK 11+ 推荐str == null || str.isEmpty()，更直观；老版本用StringUtils.isBlank(str)（Apache Commons）更稳妥。
-
isEmpty()只判长度，isBlank()还会过滤空白字符（空格、制表符等） - 注意
isBlank不是JDK原生方法，得引依赖，别在没加包的项目里硬写 - 数据库查出来为
null的字符串字段，和查出来是""，语义往往不同，别一股脑||合并处理
Map取值时get返回null，怎么区分“没找到”和“存了null”？
标准HashMap允许value为null，所以map.get(key) == null无法判断是key不存在，还是key存在但值就是null。这是个设计层面的模糊点，得靠额外手段确认。
使用场景：缓存、配置映射、状态机跳转表等对“是否存在”敏感的逻辑。
- 用
map.containsKey(key)先查key，再get——最直白，但两次哈希查找 - 用
Map.getOrDefault(key, sentinel)，选一个绝不会出现的哨兵对象（如new Object()），再用==比 - 改用
ConcurrentHashMap时注意：computeIfAbsent这类方法内部已规避此问题，可优先考虑
真正麻烦的是历史代码里混着null值写法，又没文档——这时候光靠读代码很难判断本意，得翻提交记录或补单元测试反推。
