import.meta 没有深度字段，因其是 ecmascript 标准定义的只读对象，仅含宿主注入元数据，不包含模块图拓扑信息；依赖深度属构建/运行时内部状态，浏览器和 node.js esm 均未暴露。
import.meta 本身不提供依赖树深度信息，也无法直接获取当前模块在构建后依赖图中的层级位置。
为什么 import.meta 没有深度字段
import.meta 是 ECMAScript 标准定义的只读对象，仅包含宿主环境注入的元数据（如 import.meta.url、import.meta.env 等），不包含模块图拓扑信息。依赖关系和深度属于构建时或运行时模块系统的内部状态，浏览器原生 ESM 和 Node.js ESM 均未暴露该能力。
可行的替代方案：构建时静态分析 + 运行时标记
要实现“按深度差异化预取”，需在构建阶段识别深度，并将结果以可运行时读取的方式注入模块：
- 使用工具（如 Rollup、Webpack、esbuild 插件）遍历 AST 或模块图，计算每个模块到入口的最短/最长路径长度
- 为每个模块注入一个编译期常量，例如：const DEPENDENCY_DEPTH = 2;
- 在模块中结合 import.meta.url 或自定义标识符，配合该常量执行逻辑，如：
if (DEPENDENCY_DEPTH > 3) { prefetchCriticalAssets(); }
运行时近似估算（有限场景可用）
若无法修改构建流程，可借助调用栈粗略估计“加载链长度”，但不精确、不可靠，仅作启发式参考：
- 在模块顶层捕获 new Error().stack，统计其中 import / require 相关的调用帧数量（需注意不同环境格式差异）
- 利用 document.currentScript（仅限 script 标签）向上追溯 parentElement → src 属性，逐层解析引入关系（仅适用于传统 script 场景，不适用于 ESM 动态导入）
- 这些方法受打包、懒加载、CDN 分发、代码分割影响极大，不能用于生产级策略决策
更实用的工程化思路：用语义化分组替代深度数值
比起难以稳定获取的“深度”，建议按模块职责和加载时机做显式分类：
- 标记核心路由组件为 critical，预取策略激进（preload + cache）
- 标记工具函数、通用 Hook 为 shared，复用已有 chunk，避免重复预取
- 标记第三方 SDK 封装层为 vendor，延迟预取或按用户行为触发
- 通过 import(/* webpackPrefetch: true */ './module.js') 或 import('./module.js').then(...) 显式控制时机，比依赖深度更可控
