java基本类型参数传递是值拷贝，形参修改不影响原始变量；应通过返回值传递结果，避免副作用，警惕integer等包装类的不可变性与缓存陷阱，并用单元测试验证输入不变性。
Java中基本类型参数传递是纯粹的值拷贝，方法内修改形参不会波及原始变量。要消除副作用，关键不是阻止拷贝，而是认清“改的是谁”——所有改动只作用于栈帧里的副本，原始变量天然免疫。实战中真正需要干预的，是那些误以为能靠参数修改外部状态而写出的逻辑漏洞。
看清变量生命周期：每次调用都新建独立副本
Java每次方法调用都会在栈上分配新栈帧，基本类型参数（如 int、boolean、double）的值被完整复制进该帧的局部变量表。这个副本和调用方变量物理隔离，函数返回即销毁。
- 不要在方法内对形参做“恢复原值”操作（如 value = oldValue），它毫无意义——原始变量本来就没变
- 避免写类似 counter++ 后期望外部 counter 被更新的代码；那只是改了副本，外部变量纹丝不动
- 递归场景中，每层的 depth、sum 等都是全新变量，上层无需也不该手动“回退”
把意图显式化：用返回值替代隐式修改
既然形参改不动原始值，就把计算结果明确交还给调用方。这是最直接、最符合Java语义的无副作用写法。
- 把 void changeValue(int x) 改成 int computeNewValue(int x)，调用时写 original = computeNewValue(original)
- 多个相关值需更新？封装成简单对象或记录类（record），用引用类型传参，但仅用于读取或构造新实例，不依赖“改参数来改外部”
- 工具方法如 Math.max(a, b)、Integer.sum(x, y) 全部遵循此范式：输入不变，输出新值
警惕包装类陷阱：Integer 不等于 int
Integer 是引用类型，但它不可变。传 Integer i 进方法，你拿到的是引用副本；但执行 i = i + 1 实际是创建新 Integer 对象并让形参指向它——原变量仍指向旧对象，外部看起来“没变”，本质仍是值传递（地址副本）。
- 别用 Integer 替代 int 来幻想“可被修改”；它比 int 更难产生副作用，但也更易引发空指针或装箱开销误解
- 若真需可变整数，用 AtomicInteger 或自定义含 set() 方法的容器类，但此时修改的是对象内部状态，不是参数本身
- 日志或调试时打印 i == j 判断相等性，对 Integer 要注意缓存范围（-128~127），避免用 == 比较值
单元测试验证：用断言守住不变性
副作用是否被消除，不能靠经验判断，而要靠测试固化契约。对任何接收基本类型参数的方法，都应覆盖“输入不变”这一前提。
- 测试前保存原始值：int original = x;
- 调用目标方法：method(x);
- 断言未变：assertEquals(original, x);
- 同时断言返回值正确：assertEquals(expected, method(x));
- 边界值全覆盖：0、负数、最大值、最小值，确认副本机制稳定可靠
