Node.js中如何为JavaScript回调函数传入额外参数并长链路透传

单层回调场景 #

第三方SDK回调只接收固定签名的函数时，不需要修改回调的入参列表，有两种稳定实现：

• 利用闭包直接在当前作用域定义回调逻辑，不需要抽离独立函数，上下文参数天然可访问，是零成本、无兼容问题的首选写法：

const create_plan_agreement = (req, res) => {
    const client_id = req.auth.client_id;
    third_party.plan_agreement.create({}, (err, plan_document) => {
        console.log('client plan activated');
        active_client_plan(plan_document, client_id);
    });
};

• 如果需要抽离公共回调函数复用，可以用Function.prototype.bind预绑定参数，注意bind从第二个参数开始传入的值，会按顺序插入到回调入参的最前面，调整回调入参顺序适配即可：

// 预绑定的client_id会作为第一个入参，SDK传入的err、plan_document依次排在后面
const update_plan_agreement = (client_id, err, plan_document) => {
    console.log('client plan activated');
    active_client_plan(plan_document, client_id);
};

const create_plan_agreement = (req, res) => {
    const client_id = req.auth.client_id;
    // 第一个参数传null表示不修改回调内部的this指向
    third_party.plan_agreement.create({}, update_plan_agreement.bind(null, client_id));
};

多层长回调链路场景 #

不需要在每一层调用都反复写bind透传参数，根据项目的代码组织方式选对应方案即可：

• 方案1：单请求逻辑闭包聚合
  如果整个链路的业务逻辑都属于同一个请求处理流程，直接把所有回调函数定义在最外层入口函数的作用域内，所有回调天然能访问到入口层拿到的上下文参数，完全不需要额外透传：

const create_plan_agreement = (req, res) => {
    // 整个链路共用的上下文，所有内部函数都可直接读取
    const client_id = req.auth.client_id;

    const update_plan_agreement = (err, plan_document) => {
        console.log('plan activated, send notification to the client');
        third_party.plan_agreement.update(plan_document, send_agreement_notification);
    };

    const send_agreement_notification = (err, plan_document) => {
        console.log('client plan activated');
        // 直接读取外层作用域的client_id，不需要逐层传递
        active_client_plan(plan_document, client_id);
    };

    third_party.plan_agreement.create({}, update_plan_agreement);
};

这种写法没有额外性能开销，业务逻辑聚合在同一个作用域，排查问题时不需要跨多个文件跳转子函数，是中小规模业务逻辑的首选写法。

• 方案2：上下文挂载到业务对象传递
  如果回调逻辑需要拆分到不同文件、不同模块复用，没法放在同一个闭包作用域下，可以在拿到SDK返回的业务对象时，把上下文挂载到对象的自定义属性上，后续链路直接从对象上读取上下文即可：

// 入口层
const create_plan_agreement = (req, res) => {
    const client_id = req.auth.client_id;
    third_party.plan_agreement.create({}, (err, plan_document) => {
        // 用下划线开头的自定义属性存上下文，避免和SDK原有属性冲突
        plan_document._ctx = { client_id };
        update_plan_agreement(err, plan_document);
    });
};

// 中间层回调（可拆分到独立文件）
const update_plan_agreement = (err, plan_document) => {
    console.log('plan activated, send notification to the client');
    third_party.plan_agreement.update(plan_document, send_agreement_notification);
};

// 最下游回调（可拆分到独立文件）
const send_agreement_notification = (err, updated_plan_doc) => {
    const { client_id } = updated_plan_doc._ctx;
    console.log('client plan activated');
    active_client_plan(updated_plan_doc, client_id);
};

• 方案3：转Promise写法消灭回调透传问题
  目前Node.js项目的主流实践是用util.promisify把第三方SDK的回调风格方法包装为Promise，配合async/await写线性逻辑，彻底消除回调嵌套，上下文天然在同一个async函数作用域内可访问，完全不需要考虑参数透传问题：

const { promisify } = require('util');
// 包装SDK的回调方法为Promise版本，注意绑定原方法的this指向避免内部报错
const createAgreement = promisify(third_party.plan_agreement.create.bind(third_party.plan_agreement));
const updateAgreement = promisify(third_party.plan_agreement.update.bind(third_party.plan_agreement));

const create_plan_agreement = async (req, res) => {
    const client_id = req.auth.client_id;
    try {
        const plan_document = await createAgreement({});
        console.log('plan activated, send notification to the client');
        const updated_doc = await updateAgreement(plan_document);
        console.log('client plan activated');
        active_client_plan(updated_doc, client_id);
        res.send({ code: 0, msg: 'success' });
    } catch (err) {
        res.status(500).send({ code: -1, msg: 'process failed' });
    }
};

注意：不推荐通过bind绑定this的方式跨多层回调传参。很多第三方SDK在内部执行回调时会修改this指向，很容易出现上下文丢失的隐蔽bug，稳定性远低于上面三种方案。

内容的提问来源于stack exchange，提问作者Karam Haj