npm ls 报 isWorkspace 空值错误：检查未安装的根依赖

工作区项目执行 npm ls --workspaces=false，没有列出缺少的包，先报 Cannot read properties of null (reading 'isWorkspace')。若根项目声明了尚未安装的依赖，检查是否走到了这条工作区过滤分支。

npm 12.2.1 有明确的触发条件。根依赖可能是真正缺失，也可能是按 --omit=dev 合法省略的开发依赖，或当前平台不安装的可选依赖；它们不能仅凭这次崩溃被判为安装损坏。

空依赖边与错误的依赖树不是同一件事

npm ls 需要检查声明边及其目标。某个依赖未落盘时，边还存在，目标节点可能为空。12.2.1 的工作区禁用过滤在根节点处直接读取 edge.to.isWorkspace，没有先判断 edge.to，因此可能在正常分类缺失、已省略或可选依赖之前就抛错。

先保留当前安装选项、实际 npm 版本和根清单，确认用了哪个工作区开关。不要只因错误包含 isWorkspace 就删除 workspaces 配置；那会改变项目结构，也没有修复查询工具的空值处理。

用同一 omit 条件做局部对照

如果原命令是：

npm ls --omit=dev --workspaces=false

可在保留 --omit=dev 等原有条件的前提下，临时移除 --workspaces=false：

npm ls --omit=dev

这用于取得不经过该分支的依赖信息。它会改变工作区过滤范围，因此不能把更大的输出直接交给原来只接收根项目的自动解析器。人工诊断时明确分辨根与工作区节点；CI 工具需要根范围结果时，应采用包含空值处理修正并经过回归的版本，或在自己控制的消费层明确过滤。

去掉开关后，真正缺少生产依赖仍可能返回 ELSPROBLEMS，这不是失败的绕行，而是终于得到应处理的依赖诊断。相反，已省略的开发依赖不应为了让列表工具通过而被强制安装到生产镜像。

区分查询恢复和安装恢复

不要给 npm ls 统一追加 || true，那会连真实缺依赖、无效版本和其他诊断一起吞掉。也不要用空目录冒充一个已安装包，让 edge.to 非空；安装树会变得更难核对。

恢复查询后，检查输出是否仍按预期反映缺失、无效和已省略的依赖，再执行项目实际需要的构建或启动。若原来只是查询崩溃，而运行所需依赖完整，不必因此删除 node_modules 或重建锁文件。

12.2.1 的正式 ls 实现仍有上述未检查空目标的分支，不能把其他工作区问题的修复套用到这里。升级时保留“合法省略开发依赖”与“确实缺少生产依赖”两种回归，确认工具既不崩溃，也不会把本来应该失败的依赖树误报为正常。