迁移铁律：跨宿主只传业务契约，实现各自重写

把一个源从 A 平台搬到 B 平台，什么能带走、什么必须留下——这是问渠最重要的方法论帖。

能带走的：业务契约

• 接口契约：URL、参数、响应结构、错误语义。
• 状态机：内容类型识别 → 接口结果归一化（完整 / 降级 / 合法空 / 不可用四态）→ 能力结果。
• 字段所有权表：哪个字段谁生成、谁消费、存哪里。

一个可迁移的 payload schema 至少明确 book_id、item_id、模块归属；缓存失效标记（如时间戳）只作显式可选字段。字段缺失进入对应降级 / 空态，不把宿主对象或 Java List 塞进 payload。

不能带走的：宿主实现

• 网络：java.ajax（Legado/源阅）vs http.Get/Post（轻悦）。
• 存储：source.getVariable vs LoginInfo。
• 加密：有 Packages.java 的环境与必须纯 JS 的环境。
• UI：loginUi 数组 vs HTML 面板。

实操流程（五步）

1. 剥离契约：从源代码里抽出接口契约与状态机，写成宿主无关的伪代码或表格。
2. 画所有权表：每个字段一行，写清谁写谁读存哪里。
3. 选工具链：目标平台按复杂度选直接手写或工程化（大源见 jsLib 工程化帖）。
4. 重写宿主层：网络、存储、加密、UI 按目标平台惯用法重写，不复制原宿主调用。
5. 逐级验证：按《测试七级层级》推进，真机通过才算数。

示例：一段契约长什么样

text
[搜索]
请求: GET {base}/search?q={keyword}&page={n}
响应: { items: [ { id, title, author, cover? } ], hasMore }
错误: 非 200 或 items 缺失 → 状态=不可用；items 空数组 → 状态=合法空

[详情]
请求: GET {base}/book/{id}
响应: { title, author, intro, chapterCount }
依赖: 搜索结果中的 id

这段文字在任何平台都能照着实现——这就是「可迁移」的样子。对照反例：把 java.ajax("...") 的调用链直接贴过来，换平台的人既看不懂契约，也没法复用。

记不住就背这句

业务逻辑可以跨，宿主实现不能搬。