C++ 解析 package-lock.json 极其困难，因无官方支持、schema 随 npm 版本漂移（lockfileVersion 1/2/3 结构迥异）、依赖需递归展开且含语义歧义，须手动分支处理、谨慎类型转换、构建邻接表防环、校验 integrity 时注意编码细节。
不能直接用 C++ 解析 package-lock.json —— 它不是为 C++ 设计的，也没有官方 C++ 解析器；你得自己选库、处理 schema 变体、应对嵌套结构和语义歧义。
为什么 package-lock.json 在 C++ 里特别难啃
它不是标准 JSON Schema：字段含义随 npm 版本漂移（比如 lockfileVersion: 1 vs 2 vs 3），dependencies 下可能是对象、也可能是带 version/resolved/integrity 的扁平结构，还混着 packages 数组（v2+）。更麻烦的是“深层依赖”不存于单一路径，要靠 requires 字段递归展开，而 C++ 没有原生模块图遍历能力。
-
lockfileVersion: 1：依赖树藏在dependencies嵌套对象里，键名即包名，值含dependencies子对象 -
lockfileVersion: 2/3：主干用packages数组，每个条目是""（root）或"node_modules/foo"路径，requires字段才是关键依赖映射 - 同一包多个版本共存时，路径 key 可能含
node_modules/foo/node_modules/bar，C++ 字符串解析易漏层级
用 nlohmann/json 读出结构但别信它的类型推断
它能 parse 成 json 对象，但 dependencies 在 v1 是 object，在 v2+ 是 absent；packages 在 v1 不存在，在 v2+ 是 array。硬写 json["dependencies"].is_object() 会 crash 或跳过真实数据。
- 先读
json["lockfileVersion"]，转成 int，再分支处理逻辑 - v1：遍历
json["dependencies"].items()，对每个 value 检查是否含"version"和"dependencies" - v2/3：遍历
json["packages"].items()，过滤掉空 key（root），用key.substr(14)提取包名（"node_modules/xxx"），再查value["requires"]获取直接依赖列表 - 所有字符串字段（如
"integrity"）必须用.get<:string>()</:string>显式转换，否则.dump()后再 parse 可能丢精度
构建依赖图时绕开递归爆栈和环引用
package-lock.json 允许 peer / optional / dev 依赖交叉，requires 不保证 DAG；C++ 里手写 DFS 容易栈溢出或死循环。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 用
std::unordered_map<:string std::vector>></:string>存邻接表，key 是包名（如"lodash"），value 是它 require 的包名列表（不含路径前缀） - 遍历前用
std::unordered_set<:string></:string>记已访问包名，遇到重复立即跳过 —— 不要尝试还原完整 resolve 路径 - 别试图从 root 往下递归展开；改成两遍扫描：第一遍建图，第二遍用 BFS 拓扑排序（若需顺序）
- 对
"peerDependencies"字段保持静默 —— npm 本身也不强制解析它来安装
别忽略 integrity 和 resolved 的编码陷阱
深层依赖的 resolved 可能是相对路径（"https://registry.npmjs.org/foo/-/foo-1.2.3.tgz"）或 file 协议（"file:../bar"），integrity 是 "sha512-xxx" 格式，但 C++ 字符串比较时容易因换行/空格失败。
- 提取
integrity前先erase(remove_if(...))清除首尾空白，再检查是否以"sha512-"或"sha256-"开头 -
resolved若含"file:"，不要拼接当前工作目录 —— lockfile 里的路径是相对于 project root 的，而你的 C++ 程序可能在任意路径运行 - 需要校验时，用 OpenSSL 的
EVP_DigestInit系列函数，别用 base64 解码后比对原始 hash ——integrity的 base64 是带 padding 的，OpenSSL 默认不校验 padding
真正卡住人的从来不是 JSON 解析，而是 npm 把语义藏在字段存在性、路径格式、版本字段组合里；C++ 没有 package.json 的 runtime context，你得自己模拟 npm install 的 resolve 规则——而那部分根本没文档。
