InfluxDB Line Protocol写入长文本前必须转义换行符（ → 、 → ）和双引号（"→"），并显式声明字段类型为string；单点建议≤64KB，批量写入需调小batch size（如20）并设flush间隔。
写入长文本前必须处理换行和特殊字符
InfluxDB 的 Line Protocol 不支持原始换行符（
、
），遇到未转义的换行会直接导致写入失败，错误信息通常是 unable to parse 或 invalid field format。长文本里常见日志片段、堆栈跟踪、JSON 片段，天然含换行和双引号，必须预处理。
正确做法是：用 Go 的 strings.ReplaceAll 把
替换成 \n，
替换成 \r，双引号 " 替换成 "。注意——反斜杠本身也要被转义，所以代码里写的是 "\n"，不是 "
"。
- 别用
fmt.Sprintf("%q", s)：它会给整个字符串加双引号并逃逸，但 InfluxDB 字段值不需要外层引号（Line Protocol 要求字符串字段值必须用双引号包裹，但那是你拼接时加的，不是%q加的） - 别跳过
- 长度无硬限制，但单点写入建议控制在
64KB以内；超大文本建议切片或存对象存储，只写 URL 到 InfluxDB
用 WriteAPI 写入时字段类型必须显式声明为 string
Go client（influxdb-client-go）默认把无类型变量当 float64 处理。如果直接传一个未标注类型的长字符串，SDK 可能静默丢弃或报 field type conflict 错误。
必须用 metric.StringField("content", text) 显式指定字段类型。这里 metric 是 github.com/influxdata/influxdb-client-go/v2/api/write 下的 Point 构建器返回的对象。
立即学习“go语言免费学习笔记（深入）”；
- 不能写成
metric.Field("content", text)：这个泛型方法会按 Go 类型推断，string→string看似对，但实际在批量写入时可能因类型缓存错乱 - 字段名避免用
time、measurement、tags这类保留字，哪怕只是普通字段名 - 如果文本含逗号（
,）或等号（=），Line Protocol 不要求转义，但建议统一走前面的ReplaceAll流程，避免混用规则
批量写入长文本要控制 batch size 和 timeout
长文本单条体积大，叠加高并发写入容易触发 InfluxDB 的 max-body-size（默认 25MB）或客户端超时。Go client 默认 batch size 是 1000 点，对长文本来说太激进。
初始化 WriteAPI 时需调用 WriteOptions 调整：
opts := influxdb2.DefaultOptions().
SetBatchSize(20). // 每批最多 20 条，不是 1000
SetFlushInterval(1000). // 1s 强制刷一次，防堆积
SetRetryInterval(1000).
SetTimeout(10 * time.Second)
api := client.WriteAPIWithOptions("my-org", "my-bucket", opts)
-
SetBatchSize(20)是经验值，具体看单条文本平均大小；若平均 >100KB，建议降到5 - 不要关掉
SetFlushInterval：长文本写入慢，不设间隔会导致 buffer 卡住，新数据进不来 - InfluxDB OSS 2.x 对单次 HTTP body 有
max-body-size限制，改配置要重启服务，不如前端控量
查询长文本时注意 field key 和 tag key 的区分
写进去的长文本是 field，不是 tag。InfluxDB 强制要求 tag 值必须是短字符串（≤ 64KB，且索引友好），而 field 才是存任意长度字符串的地方。如果误用 Tag("content", text)，client 会 panic 或静默截断。
查的时候也得用 field 语法：
from(bucket: "my-bucket") |> range(start: -1h) |> filter(fn: (r) => r._field == "content") |> limit(n: 1)
- Flux 查询里没有
SELECT *等价写法，必须明确写r._field == "xxx"或用keep(columns: ["content"]) - 长文本不适合做
GROUP BY或WHERE条件匹配——性能极差，InfluxDB 不为全文检索设计 - 如果真要搜索内容，导出到 Loki / Elasticsearch 更合适，InfluxDB 只负责带时间戳的原始存储
实际跑通的关键就三点：字符串提前转义、字段类型写死为 string、批量参数按体积反推。最容易忽略的是 处理和 batch size 与文本体积的联动——这两处一错，现象就是“明明没报错，但数据就是不出现”。
