副作用是指函数调用后除返回值外还改变了外部可观察状态，如修改全局变量、写文件、改对象字段或调用System.out.println()等；Java中易踩坑处包括条件表达式、方法链、Stream操作及++i等，需通过命名规范、分层设计和工具检测来约束。
什么是副作用：函数调用后“偷偷改了什么”
副作用就是一段代码在计算结果的同时，还改变了程序外部的可观察状态。比如修改了全局变量、写了文件、改了传入对象的字段、甚至只是调用了 System.out.println() ——这些都不是“纯计算”，都算副作用。
Java 里最常踩坑的是把有副作用的操作塞进表达式里，比如条件判断、三元运算、方法链中间。编译器不会拦你，但逻辑会变得难以追踪。
-
list.remove(0)返回被删元素，但同时list本身变了 —— 这个返回值如果被忽略，就容易误以为没发生修改 -
map.put("k", "v")返回旧值，但map已更新；若写成if (map.put("k", "v") != null)，语义就混乱了：你想判断旧值，还是想触发插入？ - 在
stream().filter(x -> log(x)).map(...)里调用日志方法，看似“只是打印”，但一旦 stream 被短路（如用findAny()），log 可能根本不会执行 —— 副作用不再可控
哪些 Java 表达式最容易藏副作用
Java 不强制纯函数，所以很多常用操作天然带副作用。关键不是“能不能用”，而是“用在哪会让别人（或未来的你）看不懂”。
-
++i和i++：修改变量本身，且返回值不同；嵌套在array[i++] = x或method(i++, i++)中时，求值顺序依赖 JVM 实现，行为不可靠 -
Optional.orElseGet(() -> heavyInit())是安全的，但Optional.orElse(heavyInit())会无条件执行初始化 —— 看似只差一个Get，实际副作用触发时机天壤之别 -
Boolean.TRUE.equals(obj)没副作用，但obj.equals(Boolean.TRUE)如果obj是 null 就抛NullPointerException—— 这个异常本身就是副作用，而且打断正常流程
Stream 和 Lambda 里的副作用陷阱
Stream API 设计上鼓励无副作用，但语言不限制你乱来。一旦在 map、forEach 或谓词里改外部状态，就等于放弃并行能力，还埋下竞态隐患。
立即学习“Java免费学习笔记（深入）”；
-
stream.map(x -> { cache.put(x.id, x); return x.transform(); })：缓存写入是副作用，但map不保证执行顺序，也不保证一定执行（如被优化掉）；换成forEach更直白，但也意味着不能转成并行流 -
stream.filter(x -> x.isValid()).peek(x -> audit.log(x))：看起来只是“顺便记录”，但peek是调试专用，不保证在所有终端操作中都被调用（比如某些收集器会跳过） - 用
Collectors.collectingAndThen包装副作用（如日志）比硬塞进流更清晰，因为副作用被显式隔离在“收集完成之后”
怎么识别和约束副作用
没有语法标记能帮你自动发现副作用，只能靠习惯和工具辅助。重点不是消灭它，而是让它“看得见、管得住”。
- 方法命名要诚实：
calculateTotal()不该清空缓存；saveAndNotify()就该有副作用 —— 名字是第一道防线 - 把副作用集中到明确的层：比如 Service 方法可以改 DB、发消息；DTO 的
toString()或equals()必须无副作用 - 静态分析工具如
errorprone能捕获部分危险模式，例如在switch表达式里调用可能抛异常的方法，或对不可变集合调用add() - 单元测试里验证副作用：不是只测返回值，还要检查
mockLogger.wasCalledWith("x")或verify(db).insert(...)
副作用本身不可怕，可怕的是它躲在表达式中间，等你加了个 .parallel() 或换个 JDK 版本才突然暴露。写的时候多问一句：“这个调用，除了返回值，还在哪留了痕迹？”
