Java中真正引用透明的操作极少，如Math.abs()、String.toLowerCase()（同实例）、Integer.sum()等纯静态方法；而涉及状态、I/O、时间、随机数、全局变量或可变对象的操作均不满足。
Java里哪些操作算“引用透明”？
引用透明的函数，就是无论调用多少次、在哪儿调用，只要输入相同，输出就一定相同，且不产生任何副作用。Java里真正满足这个条件的代码其实很少——不是语法不允许，而是日常写法太容易踩坑。
比如 Math.abs()、String.toLowerCase()（对同一字符串实例）、Integer.sum() 这类纯静态方法，基本算引用透明；但一旦牵扯到对象状态、I/O、时间、随机数或全局变量，立刻失效。
-
new Date()不是引用透明——每次调用返回不同对象，且依赖当前系统时间 -
System.currentTimeMillis()不是——结果随调用时机变化 -
list.sort()不是——修改原列表，有副作用 -
Collections.sort(list)也不是——虽然方法是静态的，但依然会改变传入的list
为什么用Stream.map()也不一定引用透明？
很多人以为用了 Stream 就自动函数式了，其实不然。map() 本身只是个高阶函数容器，它是否引用透明，完全取决于你传进去的 lambda 里写了什么。
常见错误是把外部可变状态塞进 lambda：比如捕获一个正在被多线程修改的 counter，或者在 lambda 里调用 System.out.println()、写文件、改数据库——这些都会让整个流失去引用透明性，进而破坏并行安全性和可重放性。
立即学习“Java免费学习笔记（深入）”；
- ✅ 安全：
numbers.map(x -> x * x) - ❌ 不安全：
numbers.map(x -> { logger.log(x); return x * x; })（日志是副作用） - ❌ 更隐蔽的不安全：
numbers.map(x -> cache.computeIfAbsent(x, this::heavyCalc))（cache是可变的ConcurrentHashMap，首次调用才计算，后续返回缓存值——输入相同但执行路径不同）
用Optional.map()时怎么避免意外打破引用透明？
Optional.map() 看似轻量，但它内部只是条件执行：只有 isPresent() 为 true 才调用函数。这本身不破坏引用透明，但如果你传进去的函数依赖外部状态，问题就来了。
尤其要注意的是：Optional 常和 builder 模式、配置加载混用，很容易在 map 里触发一次性的初始化逻辑（比如第一次访问才加载远程配置），导致后续重试或重放时行为不一致。
- ✅ 安全：
opt.map(s -> s.length()) - ❌ 危险：
opt.map(s -> configService.loadByKey(s))（如果loadByKey有缓存策略或网络调用） - ⚠️ 隐患：
opt.map(s -> new ExpensiveObject(s))——构造函数里做了 I/O 或改了静态字段，就不再是纯的
Lambda捕获局部变量时，编译器到底检查了什么？
Java 要求 lambda 捕获的局部变量必须是“实际上的 final”（effectively final），这只是编译期检查，**跟引用透明性无关**。它只防你改变量本身（比如 i++），但完全不管变量指向的对象有没有被修改。
比如你捕获一个 StringBuilder，编译器不报错，但它在 lambda 里被 .append() 多次，那这个 lambda 就不是引用透明的——哪怕参数没变，输出也可能因 StringBuilder 内部状态而不同。
- 编译器允许：
StringBuilder sb = new StringBuilder(); list.forEach(x -> sb.append(x))，但这是典型的非引用透明用法 - 真正要约束的，不是“能不能捕获”，而是“捕获的东西会不会在多次调用中产生可观测变化”
- 工具层面几乎无检查——JVM 不管，IDE 不提示，得靠人盯住副作用边界
引用透明性在 Java 中不是语言特性，是编码纪律。它不靠语法强制，靠对每个函数输入/输出/可观测行为的诚实判断。最容易被忽略的，是那些看似无害的“读配置”“打日志”“查缓存”操作——它们让函数从纯变成 impure，而且往往没有报错，只在重放、测试或并发时悄悄出事。
