背景

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

坑一：SQLite 字段 VARCHAR(5000) 截断

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

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

教训：别用 VARCHAR 存可能很长的内容，长文本一律 TEXT，避免被中间某层按声明长度截断。

坑二：Excel 单元格 32767 字符上限

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

解决：对于这种超长字段，要么不导出原始数据（隐藏对应 sheet），要么分片拆到多个单元格 / 多行。

小结

这两个坑本质是同一类：忽略了存储介质对“单值长度”的隐性上限。做数据搬运时，字符串字段先确认上限——数据库的列类型、Excel 的单元格、各配置的行长度——别让超长数据在中间被静默截断或报错。