静态 import 仅提供字面依赖关系，需通过标注关键导入点、关联运行时行为、绑定业务事件契约三步增强语义能力，最终输出以业务动作为中心的依赖图谱。
仅靠静态 import 语句本身无法实现真正的“语义依赖追踪”，它只能给出字面层的模块引用关系。要让依赖分析具备业务语义，必须在 static imports 的基础上叠加上下文理解与行为建模。
Static Imports 是起点，不是终点
前端项目中的 import 语句（如 import { login } from '@/services/auth'）明确表达了代码层面的耦合，但它不回答这些问题：
- 这个
login函数是否只在用户登录页调用？还是也被埋点、监控或权限校验逻辑间接使用？ - 它是否在 SSR 首屏渲染中被同步加载？还是通过
dynamic import()延迟加载？ - 它的返回值是否直接驱动了某个关键 UI 状态（如
isAuthenticated）？
这些才是“核心业务路径”的语义所在——静态 import 提供结构骨架，语义需由调用链、数据流和生命周期共同填充。
三步增强 static imports 的语义能力
无需重写构建流程，可在现有工程链路中轻量注入语义层：
立即学习“前端免费学习笔记（深入）”；
-
标注关键导入点：在 import 语句后添加 JSDoc 注释或自定义 AST 标签，例如
/** @business-path auth-flow:login-step */<br>import { login } from '@/services/auth'; -
关联运行时行为：利用构建时插件（如 Rspack 2.0 的
compiler.hooks.processAssets或 Vite 插件）扫描 AST，将带标注的 import 节点与对应函数调用位置、组件生命周期钩子（如useEffect中触发 login）建立映射 -
绑定业务事件契约：为高频业务动作（如“下单”“支付回调”“会话续期”）定义统一事件名，并在调用处显式 emit（如
bus.emit('order:submit:start', payload)）。静态扫描可提取这些 emit 语句，反向定位其所在的 import 模块链
可视化呈现业务路径而非模块图
最终输出不应是“谁 import 了谁”，而是“哪个业务动作依赖哪些服务与状态”。例如：
【登录流程】
→ 触发组件：LoginForm.vue
→ 关键调用：authService.login()（来自 @/services/auth）
→ 数据影响：userStore.setToken() → router.beforeEach 守卫生效
→ 外部依赖：axios（仅在非 mock 模式下启用）
这种图谱可直接嵌入 CI 流程：当某次 PR 修改了 authService.login，系统自动标出所有受语义影响的业务路径，提示测试范围。
避免常见误区
语义依赖追踪不是把所有 import 打上业务标签就完事：
- 不建议在每个 import 后手动加注释——应结合 ESLint 自定义规则，在函数导出/调用处集中声明语义归属
- 不要混淆“技术依赖”和“业务依赖”：一个模块可能被十个地方 import，但只在两个业务路径中承担关键角色
- 避免过度依赖 LLM 解析注释——当前阶段更可靠的是结构化标记（如
/** @semantic:checkout:submit */）+ AST 提取
