view()不分配新内存而共享数据缓冲区，故修改视图即修改原数组；copy()分配新内存实现一层深拷贝，但object数组需deepcopy才彻底隔离。
为什么 arr.view() 修改原数组？
因为 view() 不分配新内存，只是换了个“眼镜”看同一块内存。它共享数据缓冲区（arr.data），改视图就等于改原数组。
常见错误现象：arr.view().fill(0) 后发现原 arr 全变 0；或用 view(dtype=np.int32) 重解释字节后，原浮点数组值乱掉。
- 只在需要类型重解释（如 float32 → int32 按位读）或结构化视图（如
arr.view([('x', 'f4'), ('y', 'f4')])）时才用view() - 不推荐用于“假装复制”——这不是拷贝，连
np.may_share_memory(arr, arr.view())都返回True - 兼容性无问题，但行为和直觉相反，新手极易误以为是安全副本
arr.copy() 真的完全独立吗？
是的，arr.copy() 分配全新内存块，数据、形状、dtype 全部复制，和原数组彻底无关。但要注意：它只做“一层深拷贝”。
使用场景：需要修改副本而不影响原始数据，比如归一化前备份、算法中间状态保存。
-
arr.copy()返回的数组flags.owndata == True，且np.may_share_memory(arr, arr.copy())返回False - 若
arr是 object 类型数组（存了 Python 列表或 dict），arr.copy()不递归拷贝这些对象——内部引用仍共享 - 性能上，
copy()触发完整内存分配 + 数据拷贝，大数据集有明显开销；可考虑np.empty_like(arr); np.copyto(dst, src)略微优化
浅拷贝陷阱：赋值 = 和 np.array(arr, copy=False)
这两者都不创建新数据，只是增加一个指向同一内存的引用，比 view() 还“轻”——连 dtype 转换逻辑都没有。
常见错误现象：函数里写 def foo(x): y = x; y[0] = 999，调用后发现传入的 x 第一个元素真变了。
-
y = x：最危险，语法上毫无提示，但y is x为True（同一对象） -
np.array(arr, copy=False)：默认行为，除非显式设copy=True，否则和直接赋值等价 - 即使
arr是只读（arr.setflags(write=False)），赋值后y依然可写——因为没新建 array 对象，只是别名
怎么选？看是否要改数据 + 是否含嵌套对象
核心判断就两条：你改不改副本？副本里有没有 Python 对象？
- 只读分析、临时切片计算 → 直接用切片（自动视图），省内存
- 要改副本，且数组是数值型（int/float）→ 用
arr.copy() - 要改副本，且是 object 数组（存了 list/dict）→ 必须用
copy.deepcopy(arr)，arr.copy()不够 - 需要 reinterpret 内存布局（如 float → int 字节级映射）→ 用
arr.view()，但得清楚自己在干啥
最容易被忽略的是 object 数组的“伪深拷贝”问题：arr.copy() 看起来安全，实际改内部列表时原数组跟着变。这时候没有捷径，必须上 deepcopy。
