Windows上np.array([1,2,3])默认dtype为int32，因MSVC下C long为32位且np.int_映射其类型；这导致跨平台不一致、random.randint越界及JSON序列化失败，需显式指定dtype或用.item()转换。
为什么Windows上np.array([1,2,3])默认是int32？
这不是bug，而是NumPy在Windows 64位平台上的历史约定：C的long类型在MSVC编译环境下被定义为32位，而np.int_（即np.array默认整数类型）直接映射到C long。所以即使你用的是64位Python，np.array([1,2,3])的dtype仍是int32——这和Linux/macOS上默认int64不一致。
后果很实际：np.random.randint(0, 2**32)在Linux能跑，在Windows直接报ValueError: high is out of bounds for int32；json.dumps()序列化含np.int32的字典也会失败。
- 别依赖
np.int_或np.int（后者已在NumPy 2.0+中弃用） - 显式指定
dtype才是跨平台安全做法 - 尤其在生成随机数、做索引、存档数据时，必须提前确认位宽
np.random.randint在Windows报high is out of bounds怎么修？
错误根源是np.random.randint底层用int32生成随机数，但你传入的high=2**32超出了int32最大值（2**31 - 1）。Linux下因int_是int64，所以不报错。
- 方案一：缩小范围 → 改用
np.random.randint(0, 2**31)（兼容所有平台） - 方案二：强制64位 →
np.random.randint(0, 2**32, dtype=np.int64) - 方案三：换接口 →
np.random.Generator().integers(0, 2**32, dtype=np.int64)（推荐，新API更明确）
注意：np.random.seed()不解决这个问题，它只控制种子，不改变底层整数类型。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
JSON序列化时报Object of type int32 is not JSON serializable怎么办？
json.dumps()只认Python原生int/float，不认识np.int32这类NumPy标量。即使isinstance(np.int32(42), int)返回True，JSON encoder仍会拒绝它。
- 临时修复：对每个NumPy标量调用
.item()→json.dumps({'x': np.int32(42).item()}) - 批量处理：递归遍历字典/列表，遇到
np.integer或np.floating子类就.item() - 一劳永逸：自定义
JSONEncoder，重写default方法，专门拦截np.integer和np.floating
别用str()或int()强转——对np.int64大数可能触发精度丢失，.item()才是正确解包方式。
什么时候该用np.int32，什么时候必须用np.int64？
不是“越长越好”，而是看场景：
- 做数组索引（如
arr[idx]）→ 优先用np.intp（指针大小整型），它在Windows 64位是int64，Linux 64位也是int64，天然跨平台 - 存传感器时间戳、大ID、计数器超过21亿 → 必须
np.int64，int32溢出后不报错，只静默翻转（比如2147483647 + 1变成-2147483648） - 嵌入式或内存敏感场景（如千万级稀疏矩阵）→ 可用
np.int32省一半内存，但得全程确保数值不越界
最易被忽略的一点：np.iinfo(np.int32).max是2147483647，不是2**32；np.iinfo(np.int64).max是9223372036854775807，不是2**64——有符号整型的上限永远是2**(n-1) - 1。
