Node 开发者熟悉 Java 的建议

结合本项目 · global-flight-distribution(Next.js / TypeScript BFF)

一句话结论:本项目本体是 Node/TS,Java 重在读不在写。 守住类型边界 connectors/types.ts + 转换层 shared/*normalizer,不需要深学 Java 语法。

Java 只出现在两个地方

① HSF 调用

src/server/api/connectors/

调用 Java 后端服务。你写 TS,但对方的类型、方法名、返回值全是 Java 来的。

② 旧 Java 后端

global-flight-distributors

只作为确认业务口径的参考代码来读。严禁调用(AGENTS.md 硬性边界)。

所以几乎不用「写 Java」,主要工作是读 Java → 把类型和业务口径写到 TS 这边。

概念对照表(Node → Java)

Node / TSJava(HSF / 旧后端)在本项目里的含义
import 的 npm 函数HSF service 的 methodconnectors/types.ts 每个 method 对应一个 Java 方法
REST endpoint + JSONHSF(接口全限定名 + 版本 做 RPC)service id = 接口FQN:版本,见 connectors.ts
interface { }Java DTO / POJOJava 一串 getXxx() = TS 的一个字段
null / undefinedJava nullInteger vs int包装类型(Integer/Long)会来 null,基本类型(int/long)不会
numberint / long / BigDecimallong 在 JS 会丢精度,金额 / ID 一律用字符串
字符串 enumJava enum(序号或 name)enums.ts 锁口径;Java 给的是数字还是 name 先确认
try / catchJava 异常 + 返回的 ResultDO错误常常是返回值里的状态字段,不是抛异常
PromiseJava 同步方法HSF 本身同步,TS 这边包成 Promise

读 Java 的最少诀窍

一次 HSF 调用的数据流

route.ts薄层 dispatch service业务编排 connectorrequest-builder HSFJava 后端(同步) normalizerJava 响应→TS ResultDO统一返回

你写代码主要在两端:request-builder(TS → Java 入参)和 normalizer(Java 出参 → TS)。中间的 Java 实现只读不碰。

最容易踩的坑(Node 出身)

  1. long 丢精度 —— 订单 ID / 金额用 number 接会坏。在边界 mapper 里转 string。
    Java Long 最大值 ≈ 9.2×10¹⁸,JS Number.MAX_SAFE_INTEGER ≈ 9×10¹⁵,差了 1000 倍。订单号一般 16~18 位,必出问题
  2. 别凭习惯猜 HSF 元信息 —— 方法名 / 参数 / 返回类型用 mw hsf 查原文(docs/hsf-query-guide.md),不要按 Java 习惯「应该是这样」去填。
  3. 别以为旧后端能调 —— com.fliggy.global.flight.distributors.client.* 只是参考,不是可调 provider。
  4. null 安全 —— Java 包装类型字段随时可能 null。TS 这边的 optional / 默认值收敛到 coercion.ts

建议的上手顺序

1
src/server/api/connectors/types.ts
看清和 Java 的边界(最稳定的一层)
2
docs/hsf-query-guide.md
学怎么查 Java 服务的元信息
3
connectors/shared/order-normalizer.ts
看 Java 响应 → TS 的真实转换例子
4
业务口径有疑问时,搜旧 Java 来读
只读不改不调