length是数组的不可变属性，反映编译期确定的固定容量；硬编码或滥用它会耦合业务逻辑与内存分配细节，导致维护困难，并在不同场景下隐含不同语义（如非空判断或全员参与计算）。
Java数组的length属性看似简单，但它直接暴露了数组的固定容量这一本质特征。一旦在业务逻辑中频繁硬编码长度值或依赖length做边界判断，就会把数据结构细节和业务规则缠绕在一起，导致后续变更成本陡增。
length不是变量，是设计契约
数组创建后length不可变，它不是运行时可调整的配置项，而是编译期就确定的内存分配承诺。这意味着：
- 所有使用
arr.length的地方，实际都在间接依赖“当初分配了多少空间”这个决定 - 如果业务需求从“支持10个订单”变为“支持200个”，不只是改
new Order[10]，还要同步检查所有for (int i = 0; i 、<code>if (index 、<code>Arrays.copyOf(arr, 200)等位置 - 遗漏任何一处，轻则数据丢失（如遍历只到原长度），重则越界异常（如索引计算未重校验）
静态初始化加剧隐性耦合
像int[] scores = {85, 92, 78};这种写法，数组长度由字面量个数决定，表面简洁，实则把数量逻辑藏在数据里：
- 若需动态加载成绩数据，但代码里还保留着
scores.length == 3这样的断言，就会和真实数据规模冲突 - 测试用例若基于该数组长度编写边界条件，换一组数据就可能失效
- 多人协作时，有人新增元素却忘了更新配套的统计逻辑，问题不易察觉
用ArrayList替代数组可解耦长度逻辑
当业务真正关心的是“有多少个元素”，而不是“分配了多少连续内存”，应优先考虑ArrayList：
- 它的
size()返回当前元素个数，与底层扩容无关；capacity()才反映实际分配空间——职责分离清晰 - 添加元素自动扩容，避免手动管理
length带来的边界风险 - 若必须用数组（如高性能计算、JNI交互），至少将长度抽取为常量：
private static final int MAX_USERS = 50;，并在注释中说明业务含义，而非技术限制
length参与运算时务必验证语义合理性
length本身只是数字，但它在不同上下文代表不同含义：
- 在
for (int i = 0; i 中，它表示合法索引上限 - 在
if (arr.length > 0)中，它表示非空判断依据 - 但在
int avg = sum / arr.length;中，它隐含“所有元素都参与计算”的假设——若数组含默认值（如new int[5]中未赋值的0），平均值就失真
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
