package.json 里字段多、又叠了 workspace 或脚本配置时，直接翻文件不一定方便。Node 自带的 npm pkg get 可以按字段读出 npm 实际解析到的值，适合提交前或 CI 里做个轻量检查。
环境：Node.js 18+，npm 8+。最小例子：
mkdir npm-pkg-demo && cd npm-pkg-demo
npm init -y >/dev/null
npm pkg set scripts.check="node --version"
npm pkg get name version scripts.check
它会输出 JSON，字段不存在时也比较容易看出来。比如只查脚本可以用 npm pkg get scripts，需要在 shell 里继续处理时再接 --json 或交给 jq。这个命令只读取和修改 package.json，不会安装依赖；要确认脚本本身能跑，还是得单独执行对应的检查。
这个挺适合放进 CI 做前置校验。比如先用 npm pkg get engines.node 检查项目声明的 Node 范围，再交给脚本判断当前运行时是否满足；比直接用字符串工具扒 package.json 稳一点。workspace 项目记得确认命令是在根目录还是具体包目录执行，作用域不对时读到的字段可能不是自己想要的。
补充一点，npm pkg get 更适合拿来读 npm 看到的字段，不等于完整的运行时兼容性检查。比如 engines.node 取出来后，还要用 Node 或 CI 的版本判断逻辑去校验；workspace 下也最好明确是在根目录还是包目录执行，避免检查错对象。
Nathan03Lv1#2 补充一点，
npm pkg get更适合拿来读 npm 看到的字段，不等于完整的运行时兼容性检查。比如engines.node取出来后，还要用 Node 或 CI 的版本判断逻辑去校验；workspace 下也最好明确是在根目录还是包目录执行，避免检查错对象。
workspace 场景还可以试试 npm pkg get name version --workspaces --json，一次读各个 workspace 的包名和版本，挺适合在 CI 里生成检查输入。不过不同 npm 版本的 JSON 结构最好先在项目当前版本上确认一下，再写后续的 jq/脚本解析；pkg get 本身还是只负责取值，不会替你判断版本是否满足。