数组拷贝不直接触发GC，但通过改变引用关系间接影响回收：浅拷贝共享嵌套对象引用，易致内存滞留；深拷贝切断引用链，利于及时回收但开销大；删除操作模拟标记-清除；基本类型数组GC压力小，引用类型数组更敏感。

数组拷贝本身不直接触发垃圾回收，但它会间接影响对象的引用关系和内存生命周期，进而改变垃圾回收器（如 Python 的引用计数、标记-清除，或 JVM 的标记清除）的判断依据。

浅拷贝让多个变量共享底层数据

对一维数组或列表做浅拷贝（如 list.copy()、[:]、Object.assign），只复制容器本身，内部元素仍指向原对象。如果这些元素是可变对象（比如嵌套列表、字典），那么新旧数组就共用同一份数据。

• 修改嵌套对象时，所有持有该引用的数组都会看到变化
• 只要还有一个数组或变量持有着这个嵌套对象的引用，它就不会被回收
• 容易造成“本以为已脱离作用域，实际还在被隐式引用”的内存滞留

深拷贝切断引用链，释放旧对象压力

深拷贝（如 copy.deepcopy()）为嵌套结构创建全新副本，各层对象都独立分配内存。这相当于解除了原数组与副本之间的引用依赖。

• 原数组被销毁后，其内部对象若不再被其他变量引用，引用计数归零，可立即回收
• 避免因循环引用或意外长生命周期引用导致的延迟回收
• 代价是额外内存开销和拷贝时间，尤其在大数组或深层嵌套时明显

数组删除操作模拟标记清除逻辑

很多语言中数组删除并非立即搬移数据，而是先打“已删除”标记，等空间不足时再批量整理——这和 JVM 或 Python GC 的标记-清除阶段高度相似。

• 例如：删除前三个元素，不马上移动 d~h，而是记下删除位点
• 后续插入或扩容时统一清理，减少频繁搬移开销
• 这种延迟清理策略，本质是在用户态复现了 GC 的“标记+惰性回收”思想

基本类型数组更少牵涉 GC，引用类型数组更敏感

数组存储的内容类型决定了它与垃圾回收的耦合程度。

• 存 int、float 等基本值：数组本身是连续内存块，GC 只需管理数组对象自身，不追踪每个元素
• 存对象引用（如 Python 列表里放字典、Java ArrayList 存 Integer）：每个元素都是独立对象指针，增删拷贝都会影响它们的引用计数或可达性
• 特别注意：ArrayList 在自动扩容时会新建数组并迁移引用，原数组若无其他引用，即可被回收