背景

做历史层位 / 病害的 Excel 导入导出的时候，连踩了两个”长度上限”的坑，一个在数据库，一个在 Excel 本身，记一下。

坑一：SQLite 字段截断

导入历史层位线以后，滚到中间位置，长段的层位线突然变成了一条水平直线。排查发现，存深度数据的 depth_index_array 列定义成了 VARCHAR(5000)，超长段的数据被静默截断了——SQLite 写入的时候不报错，读出来就是一截残缺数据，渲染自然就错了。

解决办法：把这列改成 TEXT，不限长度。SQLite 的 TEXT 本身不限长，VARCHAR(N) 里的 N 只是个 hint、并不会真限制（SQLite 弱类型），但有些驱动 / ORM 层会按声明长度截断，所以声明成 TEXT 最保险。

教训就是：别拿 VARCHAR 存可能很长的内容，长文本一律 TEXT，免得被中间某一层按声明长度给截了。

坑二：Excel 单元格字符上限

层位导出的时候，原始数据那列把整个深度数组塞进了一个单元格，结果导出直接失败。原因是 Excel 对单个单元格的字符数有硬上限：32767 个字符。深度数组动不动上万点，序列化之后轻松超限，POI 写入就会抛异常。

这种超长字段，要么别导出原始数据（把对应的 sheet 隐藏掉），要么分片拆到多个单元格 / 多行里。

这两个坑其实是同一类：都栽在”存储介质对单值长度的隐性上限”上。以后做数据搬运，字符串字段先摸清楚上限——数据库的列类型、Excel 的单元格、各种配置的行长度——别让超长数据在中间被默默截断或者直接报错。