pandas datetime64[ns] 内存更省，每元素仅8字节；arrow.arrow实例约64+字节，100万条可多占40mb以上，且无共享结构、gc压力大。
arrow 读取时间数据时内存不省，反而更高
用 arrow 解析字符串为时间对象，看起来轻量，但实际它底层仍会构造完整 datetime 对象（或带时区的 Arrow 实例），每个实例都有固定开销。而 pandas 的 Series[datetime64[ns]] 是紧凑的 NumPy 数组，内存按字节对齐，批量存储效率高得多。
常见错误现象：arrow.Arrow 列表存 100 万条时间，内存占用常是 pandas.Series 的 3–5 倍；用 list(map(arrow.get, str_list)) 更是灾难——每条都新建对象、无共享结构。
- 使用场景：仅需单次解析、少量时间计算？
arrow没问题；批量处理、进 DataFrame、做时间序列分析？直接上pandas.to_datetime() -
pandas.to_datetime()默认启用cache=True，重复字符串自动复用解析结果，arrow.get()每次都重新 parse - 若必须用
arrow（比如依赖其shift()或时区链式操作），先转成datetime再喂给 pandas：pd.Series([a.datetime for a in arrow_list])，别留着Arrow实例数组
pandas datetime64[ns] 的内存是固定的 8 字节/元素
datetime64[ns] 是 NumPy 的原生 dtype，底层就是 int64，每个值只占 8 字节，和 Python 的 datetime（约 48 字节）或 arrow.Arrow（约 64+ 字节）完全不在一个量级。
性能影响：100 万条时间，datetime64[ns] 占约 7.6 MB；同数量的 list[Arrow] 很容易破 50 MB——不仅吃内存，GC 压力也大。
立即学习“Python免费学习笔记（深入）”；
- 参数差异：
pandas.to_datetime(..., infer_datetime_format=True)能跳过正则推断，比默认快 2–3 倍；arrow.get()没等效优化开关 - 兼容性注意：
datetime64[ns]不能表示纳秒以上精度，也不能存时区信息（得用datetime64[ns, tz]，内存翻倍）；arrow天然支持任意时区链式转换，但代价是对象膨胀 - 路径陷阱：从 CSV 读时间别用
dtype={'time': 'string'}再手动转——先让pd.read_csv(..., parse_dates=['time'])直接走 C parser，内存和速度双优
arrow 不适合当 pandas 时间列的底层存储
有人试过用 pd.Series 存 Arrow 对象，以为能兼顾易用性和灵活性。结果既没获得 datetime64 的内存优势，又丢掉了 Arrow 的方法链能力（因为 Series 不代理 Arrow 方法），还触发频繁的 __getattr__ 回退，性能反降。
错误现象：series.dt.hour 报 AttributeError；调 series.apply(lambda x: x.shift(hours=1)) 比纯 pandas 慢一个数量级。
- 正确做法：时间运算全交给 pandas 的
.dt访问器；真需要arrow.shift()那种语义，先转成datetime，用pd.Timedelta或pd.offsets替代 - 配置项注意：
pandas.options.mode.use_inf_as_na = True不影响datetime64列的NaT行为，但会让Arrow的None处理更混乱——别混用 - 命令验证内存：用
series.memory_usage(deep=True).sum()看真实占用，别信sys.getsizeof(series)——它不统计底层 NumPy 数据
arrow 是个好工具，但它不是数组。 
