用 compose 替换嵌套回调可将业务链路转为自上而下的声明式流水线，关键在于统一输入输出形态、显式处理异步、隔离副作用、增强可观测性。
直接用 compose 替换嵌套回调或层层 .then，能让业务链路从“向右滑动的面条”变成“自上而下的声明式流水线”。关键不是堆砌函数，而是把每一步抽象成输入→输出明确、无副作用、可独立测试的小单元。
先统一数据形态，再组合
真实业务中，各步骤输入输出类型常不一致：接口返回的是对象，拼接 URL 需要字符串，WebSocket 初始化又要 ID。强行 compose 会卡在参数传递上。解决办法是提前约定“链路契约”：
- 所有函数接收一个对象（如
{ token, appId, h5Id, url }），只读取自己需要的字段 - 每个函数返回新对象，保留原有字段，并添加自己产出的字段（如
{ ...input, h5Id: res.result.h5Id }） - 错误不靠
return undefined隐式传播，而是统一抛出Error，由最外层try/catch或专用错误处理器接管
异步操作必须显式包装
原生 compose 不处理 Promise，所以不能直接塞 fetch 或 async 函数。正确做法是：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 把每个异步步骤封装为返回
Promise的一元函数，例如：getSSOToken = ({ tag }) => singleSignOnToken({ formSource: tag }).then(r => ({ ...r, tag })) - 组合时用
await compose(step5, step4, step3, step2, step1)(initialData)，而不是compose(...)(await initialPromise) - 避免把
async/await塞进compose内部——那会让调用方无法控制 await 时机，也破坏了函数纯度
把副作用和分支逻辑“隔离”出来
WebSocket 连接、页面渲染、弹窗提示这些操作有副作用，不适合放在纯函数链里。建议：
- 纯函数链只负责“计算”，产出最终状态对象（如
{ appId, h5Id, url, wsReady: true, keywords: [...] }） - 副作用交给单独的“执行器”函数，比如
renderPage(result)或initWebSocket(result)，它接收 compose 输出，再触发 DOM 或网络动作 - 条件分支（如“token 失效则跳登录”）用高阶函数包裹，例如
ifThen(tokenValid, getSSOToken, redirectToLogin)，保持主链仍是线性流
调试与可观测性不能丢
compose 链一旦出错，堆栈指向内部，很难定位哪一步挂了。上线前加两道保障：
- 开发期用
tap(console.log)包裹中间函数，比如compose(tap(x => console.log('after create:', x)), appH5Create, ...) - 给每个函数加简短命名（非匿名），例如
const fetchToken = ...，让错误信息至少带函数名 - 关键步骤记录耗时，比如用
withTiming('fetchToken', fetchToken)，方便后续性能归因
