我之前处理过类似的大型跨语言迁移项目，你的场景里私有依赖无法用npm包替代确实是最大的挑战，下面针对你的三个核心问题给出可落地的思路：

1. AST与转译：适配私有依赖的批量转换方案 #

纯靠现有工具（比如JSweet）确实没法完美适配现代Node/TS环境和私有依赖，推荐自定义AST转译流水线，核心思路是：

• 解析Java AST：用成熟的Java AST解析库JavaParser或者Eclipse JDT批量扫描所有Java文件（包括私有依赖），生成结构化的AST节点，同时记录每个类的依赖关系、泛型参数、注解、方法签名等元信息。
• 映射到TS AST：用TS生态的AST工具ts-morph或者@typescript-eslint/parser来生成TypeScript代码。你需要编写映射规则，比如：
  • Java的public class对应TS的export class
  • Java的方法重载可以用TS的联合类型或者函数重载语法
  • 私有依赖的类引用直接映射到对应转换后的TS模块路径
• 处理复杂场景：对于Java的特性比如静态内部类、枚举、注解处理器，需要单独写适配逻辑，比如把Java枚举转成TS的enum或者对象字面量，把注解转成TS装饰器或者接口。
• 这种方案的优势是完全可控，能处理私有依赖的所有细节，而且可以逐步迭代优化映射规则。

2. 自动化迁移模式：保留结构的程序化工作流 #

要保留原有项目结构和引用，推荐拓扑排序驱动的增量迁移架构：

• 第一步：生成依赖图谱：用工具（比如结合JavaParser和Graphviz）扫描整个代码库，生成完整的依赖图，标记出核心依赖模块（比如底层工具类）和上层业务模块。
• 第二步：拓扑排序转换：按照依赖图的拓扑顺序，先转换最底层的无依赖模块，再依次转换依赖它们的上层模块。这样每次转换时，被依赖的类已经是TS代码，能直接生成正确的导入语句。
• 第三步：保持结构对齐：严格对应Java的包结构到TS的目录结构，比如Java的com.example.utils.StringUtils对应TS的src/com/example/utils/StringUtils.ts，保留类名、方法名的一致性，减少后续重构成本。
• 第四步：自动化验证：把原有的JUnit测试用例转成Jest/Vitest测试，对比Java和TS代码的执行结果（比如输入相同参数，验证输出一致），用tsc做类型检查，确保没有类型错误。

3. 智能体工作流：给LLM提供完整依赖上下文 #

如果用LLM辅助迁移，关键是让LLM拥有全局依赖视角，而不是只看单个文件：

• 预处理依赖图：把生成的依赖图转换成结构化数据（比如JSON格式），包含每个类的导入路径、方法签名、类型定义。在调用LLM转换某个文件时，把这个文件的代码+它直接依赖的所有类的代码+依赖图元信息一起喂给模型。
• 编排智能体角色：
  • 依赖解析Agent：负责扫描文件，提取当前文件的所有依赖，整理成上下文数据。
  • 代码转换Agent：基于上下文，把Java代码转成TS，严格对齐依赖的TS模块路径和类型。
  • 验证Agent：检查生成的TS代码是否通过类型检查，是否和原Java代码逻辑一致（比如对比测试用例结果）。
• Prompt工程优化：给LLM的提示要明确：

  请将以下Java代码转换为TypeScript，保留所有业务逻辑、类结构和方法签名。所有私有依赖的类引用请替换为已转换的TS模块路径，例如原Java的com.example.utils.StringUtils对应../utils/StringUtils。确保生成的代码符合TypeScript 5.x规范，没有类型错误。

这种方式能避免LLM丢失跨文件上下文，确保导入关系和类型定义准确。

内容的提问来源于stack exchange，提问作者Phalaksha C G