simdjson 初始化需复用 simdjson::dom::parser 实例，避免循环中重复创建；多线程下每线程独享；预分配容量可规避 CAPACITY 错误；字段访问优先用 .at_key() 而非 ["key"] 以确保安全。
simdjson 在 C++ 里怎么初始化一个解析器
simdjson 不是“拿来就 parse”，必须先创建 simdjson::dom::parser 实例，它内部持有内存池和临时缓冲区。不复用 parser 会导致重复分配、缓存失效，性能直接掉一截。
常见错误是每次解析都 new 一个 parser：simdjson::dom::parser parser; 放在循环里——这会反复初始化 SIMD 环境、重置状态，实测比复用慢 3–5 倍。
- 始终把
simdjson::dom::parser当成长期存活对象，全局或类成员变量最稳妥 - 如果多线程使用，每个线程独享一个 parser（它不是线程安全的）
- 不用手动管理内存：parser 析构时自动清理内部缓冲区
parse() 返回 error 是不是代表 JSON 语法错了
不是。simdjson::error_code 返回值涵盖三类问题：语法错误（如缺逗号）、内存不足（输入太大且没预分配）、以及平台不支持（比如 ARM 上用了 AVX2 优化路径但 CPU 不认）。最常被忽略的是第三种。
典型现象：本地编译运行正常，CI 或客户机器上 simdjson::error_code::CAPACITY 或 simdjson::error_code::INVALID_UTF8 突然出现，其实只是 parser 尝试用了高级指令集但 fallback 失败。
立即学习“C++免费学习笔记（深入）”；
- 用
simdjson::dom::parser::allocate_capacity()预分配足够缓冲（比如 10MB），能避开多数CAPACITY错误 - 检查运行环境是否支持：调用
simdjson::get_active_implementation()->name()打印当前生效的后端（westmere/haswell/arm64） - UTF-8 校验失败不一定是编码问题，也可能是二进制数据误当 JSON 传入——先确认输入流确实以
{或[开头
访问 object 字段时 .at_key() 和 ["key"] 有什么区别
.at_key("foo") 是安全访问：查不到返回 simdjson::error_code::NO_SUCH_FIELD；而 ["foo"] 是不检查直接取，遇到不存在字段会返回 simdjson::dom::element{}，后续调用 .get_int64() 等方法才报错，堆栈更难定位。
性能上两者几乎无差，但语义风险差很多。尤其在嵌套结构里：doc["data"]["items"][0]["id"] 这种链式写法，中间任一环节不存在字段都会静默返回空 element，最后 .get_int64() 报 INCORRECT_TYPE，你根本不知道是 data 缺失还是 items 是 null。
- 生产代码一律用
.at_key()+ 显式 error 检查，哪怕多写两行 - 如果确定字段必存在（比如解析自己生成的 JSON），可用
.at_key_unchecked()省一次哈希查找，但仅限可信输入 - 数组索引同理：优先用
.at(0)而非[0]
为什么小 JSON（
simdjson 的优势在批量吞吐：它靠预读、SIMD 并行扫描、延迟解析（lazy parsing）摊薄固定开销。对极小 JSON，这些机制全成负担——光是跳过空白、验证 UTF-8、建 DOM 树的起步成本就超过 nlohmann 直接递归解析的开销。
实测在 200 字节左右的 JSON 上，simdjson 解析耗时可能是 nlohmann 的 1.5–2 倍，且内存占用高 3–4 倍（最小缓冲区默认 1MB）。
- 别为了“高性能”强行统一用 simdjson，小于 2KB 的场景，nlohmann 或 jsoncpp 更合适
- 如果业务混合大小 JSON，考虑运行时判断长度：用
std::string_view先看首百字节，size() 就切到轻量解析器 - simdjson 的真正价值在日志行解析、API 批量响应、数据库导出数据——单次处理几百 KB 到几 MB 的 JSON 流
别低估预分配和错误分支的代价。很多人卡在 “明明用了 simdjson 却没快起来”，问题往往不在 parse() 这一行，而在 parser 生命周期管理、错误处理粒度、或者压根选错了适用场景。
