webpack系列之五module 生成1

桔妹导读:对于 webpack 来说每个文件都是一个 module,这篇文章带你来看 webpack 如何从配置中 entry 的定义开始,顺藤摸瓜找到全部的文件,并转化为 module。


1.
总览

webpack 入口 entry,entry 参数是单入口字符串、单入口数组、多入口对象还是动态函数,无论是什么都会调用 compilation.addEntry 方法,这个方法会执行 _addModuleChain,将入口文件加入需要编译的队列中。然后队列中的文件被一个一个处理,文件中的 import 引入了其他的文件又会通过 addModuleDependencies 加入到编译队列中。最终当这个编译队列中的内容完成被处理完时,就完成了文件到 module 的转化。

上面是一个粗略的轮廓,接下来我们将细节一一补充进这个轮廓中。首先看编译的总流程控制——编译队列的控制。

2.
编译队列控制 —— Semaphore

_addModuleChain 和 addModuleDependencies 函数中都会调用 this.semaphore.acquire 这个函数的具体实现在 lib/util/Semaphore.js 文件中。看一下具体的实现:

class Semaphore {
  constructor(available) {
     // available 为最大的并发数量
    this.available = available;
    this.waiters = [];
    this._continue = this._continue.bind(this);
  }




  acquire(callback) {
    if (this.available > 0) {
      this.available--;
      callback();
    } else {
      this.waiters.push(callback);
    }
  }




  release() {
    this.available++;
    if (this.waiters.length > 0) {
      process.nextTick(this._continue);
    }
  }




  _continue() {
    if (this.available > 0) {
      if (this.waiters.length > 0) {
        this.available--;
        const callback = this.waiters.pop();
        callback();
      }
    }
  }
}

对外暴露的只有两个个方法:

  • acquire: 申请处理资源,如果有闲置资源(即并发数量)则立即执行处理,并且闲置的资源减1;否则存入等待队列中。

  • release: 释放资源。在 acquire 中会调用 callback 方法,在这里需要使用 release 释放资源,将闲置资源加1。同时会检查是否还有待处理内容,如果有则继续处理。

这个 Semaphore 类借鉴了在多线程环境中,对使用资源进行控制的 Semaphore(信号量)的概念。其中并发个数通过 available 来定义,那么默认值是多少呢?在 Compilation.js 中可以找到。

this.semaphore = new Semaphore(options.parallelism || 100);

默认的并发数是 100,注意这里说的并发只是代码设计中的并发,不要和js的单线程特性搞混了。总的来看编译流程如下图:

3.
从入口到 _addModuleChain
webpack 官网配置指南中 entry 可以有下面几种形式:
  • string: 字符串,例如

{
  entry: './demo.js'
}、
  • [string]: string 类型的数组,例如

{
  entry: ['./demo1.js', './demo2.js']
}、
  • 对象,例如

{
  entry: {
    app: './demo.js'
  }
}
  • 函数,动态返回入口,例如

{
  entry: () => './demo.js'
}
// 或者
{
  entry: () => new Promise((resolve) => resolve('./demo.js'))
}

这些是哪里处理的呢?webpack 的启动文件 webpack.js 中, 会先对 options 进行处理,有如下一句:

compiler.options = new WebpackOptionsApply().process(options, compiler);

在 process 的过程中会对 entry 的配置做处理

// WebpackOptionsApply.js 文件中
new EntryOptionPlugin().apply(compiler);
compiler.hooks.entryOption.call(options.context, options.entry);

先看 EntryOptionsPlugin 做了什么

const SingleEntryPlugin = require("./SingleEntryPlugin");
const MultiEntryPlugin = require("./MultiEntryPlugin");
const DynamicEntryPlugin = require("./DynamicEntryPlugin");


const itemToPlugin = (context, item, name) => {
  if (Array.isArray(item)) {
    return new MultiEntryPlugin(context, item, name);
  }
  return new SingleEntryPlugin(context, item, name);
};


module.exports = class EntryOptionPlugin {
  apply(compiler) {
    compiler.hooks.entryOption.tap("EntryOptionPlugin", (context, entry) => {
       // string 类型则为 new SingleEntryPlugin
       // array 类型则为 new MultiEntryPlugin
      if (typeof entry === "string" || Array.isArray(entry)) {
        itemToPlugin(context, entry, "main").apply(compiler);
      } else if (typeof entry === "object") {
          // 对于 object 类型,遍历其中每一项
        for (const name of Object.keys(entry)) {
          itemToPlugin(context, entry[name], name).apply(compiler);
        }
      } else if (typeof entry === "function") {
          // function 类型则为 DynamicEntryPlugin
        new DynamicEntryPlugin(context, entry).apply(compiler);
      }
      return true;
    });
  }
};

在 EntryOptionsPlugin 中注册了 entryOption 的事件处理函数,根据 entry 值的不同类型( string/array/object 中每一项/functioin)实例化和执行不同的 EntryPlugin:string 对应 SingleEntryPlugin;array 对应 MultiEntryPlugin;function 对应 DynamicEntryPlugin。而对于 object 类型来说遍历其中的每一个 key,将每一个 key 当做一个入口,并根据类型 string/array 的不同选择 SingleEntryPlugin 或 MultiEntryPlugin。下面我们主要分析:SingleEntryPlugin,MultiEntryPlugin,DynamicEntryPlugin

横向对比一下这三个 Plugin,都做了两件事:

  • 注册了 compilation 事件回调(这个事件会在下面 make 事件之前会触发),在 compilation 阶段设置 dependencyFactories

compiler.hooks.compilation.tap('xxEntryPlugin', (compilation, { normalModuleFactory }) => {
  //...
  compilation.dependencyFactories.set(...)
})
  • 注册了 make 事件回调,在 make 阶段的时候调用 addEntry 方法,然后进入 _addModuleChain 进入正式的编译阶段。

compiler.hooks.make.tapAsync('xxEntryPlugin',(compilation, callback) => {
  // ...
  compilation.addEntry(...)
})

结合 webpack 的打包流程,我们从 Compiler.js 中的 compile 方法开始,看一下 compilation 事件和 make 事件回调起了什么作用

xxxEntryPlugin 在compilation 事件中回调用来设置compilation.dependencyFactories,保证在后面 _addModuleChain 回调阶段可以根据 dependency 获取到对应的 moduleFactory。

make 事件回调中根据不同的 entry 配置,生成 dependency,然后调用addEntry,并将 dependency 传入。

在 _addModuleChain 回调中根据不同 dependency 类型,然后执行 multiModuleFactory.create 或者 normalModuleFacotry.create。

上面的步骤中不停的提到 dependency,在接下来的文章中将会出现各种 dependency。可见,dependency 是 webpack 中一个很关键的东西,在 webpack/lib/dependencies 文件夹下,你会看到各种各样的 dependency。dependency 和 module 的关系结构如下:

module: {
  denpendencies: [
    dependency: {
      //...
      module: // 依赖的 module,也可能为 null
    }
  ]
}
}

webpack 中将入口文件也当成入口的依赖来处理,所以上面 xxEntryPlugin 中生成的是 xxEntryDependency。module 中的 dependency 保存了这个 module 对其他文件的依赖信息、自身 export 出去的内容等。后面的文章中,你会看到在生成 chunk 时会依靠 dependency 来得到依赖关系图,生成最终文件时会依赖 dependency 中方法和保存的信息将源文件中的 import 等语句替换成最终输出的可执行的 js 语句。

看完了各个 entryPlugin 的共同点之后,我们纵向深入每个 plugin,对比一下不同之处。

▌SingleEntryPlugin

SingleEntryPlugin 逻辑很简单:将 SingleEntryDependency 和 normalModuleFactory 关联起来,所以后续的 create 方法会执行 normalModuleFactory.create 方法。

apply(compiler) {
  compiler.hooks.compilation.tap(
    "SingleEntryPlugin",
    (compilation, { normalModuleFactory }) => {
       // SingleEntryDependency 对应的是 normalModuleFactory
      compilation.dependencyFactories.set(
        SingleEntryDependency,
        normalModuleFactory
      );
    }
  );


  compiler.hooks.make.tapAsync(
    "SingleEntryPlugin",
    (compilation, callback) => {
      const { entry, name, context } = this;


      const dep = SingleEntryPlugin.createDependency(entry, name);
      // dep 的 constructor 为 SingleEntryDependency
      compilation.addEntry(context, dep, name, callback);
    }
  );
}


static createDependency(entry, name) {
  const dep = new SingleEntryDependency(entry);
  dep.loc = name;
  return dep;
}

▌MultiEntryPlugin

与上面 SingleEntryPlugin 相比,

  • 1. 在 compilation 中,dependencyFactories 设置了两个对应值

MultiEntryDependency: multiModuleFactory
SingleEntryDependency: normalModuleFactory
  • 2. createDependency:将 entry 中每一个值作为一个 SingleEntryDependency 处理。

static createDependency(entries, name) {
  return new MultiEntryDependency(
    entries.map((e, idx) => {
      const dep = new SingleEntryDependency(e);
      // Because entrypoints are not dependencies found in an
      // existing module, we give it a synthetic id
      dep.loc = `${name}:${100000 + idx}`;
      return dep;
    }),
    name
  );
}
  • 3. multiModuleFactory.create

在第二步中,由 MultiEntryPlugin.createDependency 生成的 dep,结构如下:

{
  dependencies:[]
  module: MultiModule
  //...
}

dependencies 是一个数组,包含多个 SingleEntryDependency。这个 dep 会当做参数传给 multiModuleFactory.create 方法,即下面代码中 data.dependencies[0]

// multiModuleFactory.create
create(data, callback) {
  const dependency = data.dependencies[0];
  callback(
    null,
    new MultiModule(data.context, dependency.dependencies, dependency.name)
  );
}

create 中生成了 new MultiModule,在 callback 中会执行 MultiModule 中 build 方法

build(options, compilation, resolver, fs, callback) {
  this.built = true; // 标记编译已经完成
  this.buildMeta = {};
  this.buildInfo = {};
  return callback();
}

这个方法中将编译是否完成的变量值设置为 true,然后直接进入的成功的回调。此时,入口已经完成了编译被转化为一个 module, 并且是一个只有 dependencies 的 module。由于在 createDependency 中每一项都作为一个 SingleEntryDependency 处理,所以 dependencies 中每一项都是一个 SingleEntryDependency。随后进入对这个 module 的依赖处理阶段,我们配置在 entry 中的多个文件就被当做依赖加入到编译链中,被作为 SingleEntryDependency 处理。

总的来看,对于多文件的入口,可以简单理解为 webpack 内部先把入口转化为一个下面的形式:

import './demo1.js'
import './demo2.js'

然后对其做处理。

▌DynamicEntryPlugin

动态的 entry 配置中同时支持同步方式和返回值为 Promise 类型的异步方式,所以在处理 addEntry 的时候首先调用 entry 函数,然后根据返回的结果类型的不同,进入 string/array/object 的逻辑。

compiler.hooks.make.tapAsync(
  "DynamicEntryPlugin",
  (compilation, callback) => {
    const addEntry = (entry, name) => {
      const dep = DynamicEntryPlugin.createDependency(entry, name);
      return new Promise((resolve, reject) => {
        compilation.addEntry(this.context, dep, name, err => {
          if (err) return reject(err);
          resolve();
        });
      });
    };
    Promise.resolve(this.entry()).then(entry => {
      if (typeof entry === "string" || Array.isArray(entry)) {
        addEntry(entry, "main").then(() => callback(), callback);
      } else if (typeof entry === "object") {
        Promise.all(
          Object.keys(entry).map(name => {
            return addEntry(entry[name], name);
          })
        ).then(() => callback(), callback);
      }
    });
  }
);

所以动态入口与其他的差别仅在于多了一层函数的调用。


入口找到了之后,就是将文件转为 module 了。接下来的文章中,将详细介绍转 module 的过程。

本文作者

▬

崔 静
滴滴 | 高级软件开发工程师
2015年,因为颜控,掉入前端深坑无法自拔,也是同年加入滴滴,正式踏上前端之路。喜欢技术和挑战,爱潜水,要做一条徜徉大海的前端鱼。
同时,我们的团队正在招聘高级/资深前端开发工程师,欢迎投递简历至:cuijing@didiglobal.com。


推荐阅读
▬










更多推荐
▬
滴滴开源 / Open Source
Levin | AoE | Delta | Mpx | Booster | Chameleon | DDMQ | DroidAssist | Rdebug | Doraemonkit | Kemon | Mand Moblie | virtualApk | 获取更多项目


技术干货 / Recommended article
重磅!滴滴跨端框架Chameleon 1.0正式发布 | Android 性能优化之 Activity 启动耗时分析 | HDFS 源码解读:HadoopRPC 实现细节的探究| 阅读更多内容 

相关推荐

滴滴多篇论文入选 ICML2026,值得一读!

与此同时,在一个滴滴大规模网约车应用场景中的实验进一步显示,本文方法相较于现有基线方法取得了显著提升,其效果可与使用显著更多 RCT 数据训练得到的模型相仿。广泛的实验表明,当前最先进的智能体在这些任务中表现远不如人类,且无法通过简单的扩大规模来提升,其失败的主要原因在于上下文锁定(in-context locking)和基础能力的缺失。通过将记忆构建为一个不断进化的生态系统,DMS在无需任何额外训练的情况下,显著提升了MLLM智能体的任务成功率、执行稳定性与效率。

DiDi_Tech的博客 406

多轮 Agent 场景下,滴滴的 EAGLE-3 训推加速实践

在 64K / 128K 级别的长序列训练中,显存的主要消耗来自“中间状态”,包括 attention 的中间激活(如 softmax 相关中间量、Q/K/V 张量等),以及反向传播必须保留的激活,包括 EAGLE-3 特有的多层特征参与训练所带来的额外激活存储,与 TTT 多步展开引入的 k 轮中间态堆叠。为缓解这一问题,EAGLE-3 在训练阶段引入 TTT 机制(见图 2),按照真实 decode 流程展开:先生成一步预测,再将该预测作为下一步输入,多步递进,从模拟真实推理过程。

DiDi_Tech的博客 666

滴滴的工程师们,都在读什么书?

它兼具技术、商业与历史视角,能帮读者建立宏大产业格局,提升认知高度。从 LoRA/QLoRA 轻量微调、RAG,到服务化部署、监控迭代,每一个技术要点都搭配可视化图表,易懂、易落地、可复用。尤其适配支付、金融等高并发场景的工程化落地,轻松打通大模型「从理解到应用」的第一步,是技术岗从入门到实战的高效进阶手册。它不只教你调 API,更聚焦如何构建健壮、可扩展的 AI 生产系统,是技术人转型 AI 工程师的通关秘籍。直指大模型与自动驾驶的伦理风险,提供长期 AI 安全的底层思路,兼具技术深度与人文思考。

DiDi_Tech的博客 398

一文读懂滴滴OpenClaw专属打车Skill

在复杂场景中,AI 不再只是执行工具调用,而是开始具备一定的推理能力,例如:能够根据“22:20 落地”推算实际用车时间、主动补全你缺失的起点信息,并对整体行程进行合理规划。当你说出“帮我叫车”时,OpenClaw 会识别触发条件,并加载 didi-ride-skill 的相关内容,使 AI 能够懂得并调度滴滴的出行能力。根本的问题在于:IM 通道的异步特性本身就引入了额外复杂度,包括轮询等待、消息乱序处理、以及“如何判断回复结束”等工程问题,而这些都与测试框架本身目标无关,但会显著增加维护成本。

DiDi_Tech的博客 1004

滴滴多篇成果入选CVPR 2026,产学研协同创新结硕果

该论文首先构建了FaceCoT,首个面向人脸反欺诈的、百万级视觉问答式思维链数据集,通过模拟人类思维过程设计六阶段层级式思维链结构,首次引入结构化、可解释的推理标注机制,不仅给出真假标签,更明确呈现“攻击成立的依据与逻辑路径”,为模型学习“为什么是欺诈”提供清晰且高质量的监督信号。通过设计统一的视觉-语言-动作模型的框架,该方案解决了以往工作中推理速度慢与文本轨迹不稳定的问题,并且将多模态信息在隐空间中进行了统一,在保持推理能力的同时提高了模型的效率。图: GeoPredict框架示意图。

DiDi_Tech的博客 396

滴滴邀你一起,迈入智能工作美好协同

发送简历至HR邮箱,开启快速投递通道。

DiDi_Tech的博客 423

滴滴云平台事业群热招中!“云端”有位,虚位以待

发送简历至HR邮箱,开启快速投递通道。

DiDi_Tech的博客 381

清华大学车辆学院联合滴滴自动驾驶提出STAPO算法,解决大模型强化学习微调稳定性问题

前者筛选前20%的优势词元进行训练,而STAPO则通过剔除极少数虚假词元(仅0.01%),确保数据纯洁度和训练稳定性。以六个基准测试(AIME24、AIME25、AMC23、MATH500、Minerva 和 OlympiadBench)和三个大模型(Qwen3 1.7B、8B 和 14B)的实验表明,正成为自动驾驶端到端模型、机器人具身智能模型、语言类多模态模型的重要训练算法,尤其是在大规模神经网络的微调(Fine-tuning)阶段,具有。,所采用的方案是剔除虚假词元的S2T机制。

DiDi_Tech的博客 260

滴滴开源新进展:华佗项目支持国产沐曦GPU,助推信创发展

华佗是由滴滴主导发起开源,依托中国计算机学会(CCF)孵化的操作系统深度观测项目,专注为云原生通用计算,AI 计算,云服务,基础服务等提供操作系统内核级深度观测能力。开发者可通过华佗平台,实时获取沐曦GPU的关键运行指标,这将进一步丰富华佗在异构计算环境下的可观测能力,为云原生、AI训练等场景的运维诊断提供更全面的数据支撑。滴滴开源始终以共建共享为核心,致力于携手产业伙伴共同探索技术创新与落地实践的最佳路径,促进生态资源、能力与经验的共享。有关指标的详细说明,请见后续的"指标介绍"章节。

DiDi_Tech的博客 482

滴滴自动驾驶成立深穹远航实验室,携手清华大学开展前沿研究

滴滴自动驾驶将以实验室为载体,向高校研究团队开放真实场景和工业级算力,为前沿研究提供强力支持,加速研究成果的落地。清华大学车辆与运载学院、人工智能学院李升波教授表示,自动驾驶是全球科技竞争的战略高地,清华大学在汽车智能化领域拥有深厚的基础研究实力和顶尖人才资源,滴滴自动驾驶在自动驾驶关键技术研发和应用上已有近十年的积累。双方的深度合作,将进一步提升科研成果工程化落地效率,共同服务国家科技自立自强与产业高质量发展。展望未来,滴滴自动驾驶将持续加大AI领域的研发投入,加强自主创新,深化与清华大学的产学研合作。

DiDi_Tech的博客 203

滴滴与智谱达成战略合作,将共同探索出行Agent场景落地

基于此次战略合作,双方将共同推进Agent场景落地和大模型领域人才培养,深化出行场景的意图对齐与推理能力建设,推动Agent在更复杂业务场景中的验证与落地。近年来,滴滴持续加大在大模型与智能体方向的技术投入,依托真实复杂出行场景,逐步推进了AI出行助手、商旅助手等智能体的创新应用。滴滴与智谱宣布达成战略合作,双方将围绕通用人工智能(AGI)关键技术及其在出行领域的智能体应用开展前瞻性协同探索。滴滴相关负责人表示,期待双方充分发挥各自优势,共同推动通用人工智能在更广阔真实场景中的应用与发展。

DiDi_Tech的博客 302

<span class=“js_title_inner“>滴滴与智谱达成战略合作,将共同探索出行Agent场景落地</span>

基于此次战略合作,双方将共同推进Agent场景落地和大模型领域人才培养,深化出行场景的意图对齐与推理能力建设,推动Agent在更复杂业务场景中的验证与落地。近年来,滴滴持续加大在大模型与智能体方向的技术投入,依托真实复杂出行场景,逐步推进了AI出行助手、商旅助手等智能体的创新应用。滴滴与智谱宣布达成战略合作,双方将围绕通用人工智能(AGI)关键技术及其在出行领域的智能体应用开展前瞻性协同探索。滴滴相关负责人表示,期待双方充分发挥各自优势,共同推动通用人工智能在更广阔真实场景中的应用与发展。

DiDi_Tech的博客 217

AI 在泛前端领域的思考和实践-上篇

而泛前端从业者自带 “懂交互、懂服务串联、懂用户体验” 的基因,在打造 AI Agent 驱动的无页面方案时,反而更具天然优势,如:在开发 “无页面化” 的服务场景时,泛前端能更快理清 “用户需求 - Agent 交互逻辑 - 后端 API 调用” 的链路,更精准地规避无页面场景下的体验痛点(如交互断层、反馈不及时),甚至能将过往跨端、组件化的技术经验,复用到 AI Agent 的功能模块设计中,让无页面方案更稳定、更易扩展。这意味着,单纯 “会写代码”“能套用方案” 的能力,正在逐渐失去稀缺性;

DiDi_Tech的博客 1529

AI 在泛前端领域的思考和实践

而泛前端从业者自带 “懂交互、懂服务串联、懂用户体验” 的基因,在打造 AI Agent 驱动的无页面方案时,反而更具天然优势,如:在开发 “无页面化” 的服务场景时,泛前端能更快理清 “用户需求 - Agent 交互逻辑 - 后端 API 调用” 的链路,更精准地规避无页面场景下的体验痛点(如交互断层、反馈不及时),甚至能将过往跨端、组件化的技术经验,复用到 AI Agent 的功能模块设计中,让无页面方案更稳定、更易扩展。这意味着,单纯 “会写代码”“能套用方案” 的能力,正在逐渐失去稀缺性;

DiDi_Tech的博客 636

滴滴开源走进浙江大学|共话开源实践与高校共建

Mpx是一款增强型跨端开发框架,以小程序原生语法和技术能力为基础,借鉴Vue框架的优秀语法设计,通过静态转译与运行时适配相结合,实现“一份源码,多端运行”。滴滴开源与CCF(中国计算机学会)重点孵化的HUATUO项目基于eBPF技术实现低损耗、零侵扰的内核数据采集,覆盖TCP/IP协议栈、CPU调度、内存管理等核心模块,并构建异常事件驱动诊断与全自动化追踪(AutoTracing)两大核心引擎,能够自动捕获softlockup、oom、网络延迟等关键事件,精准定位云原生场景下的偶发与突发故障。

DiDi_Tech的博客 877

滴滴开源荣获多项 OSCAR “开源+”典型案例奖

作为一个针对开源操作系统的深度可观测性项目,在滴滴内部,HUATUO 实现了超大规模部署,覆盖通用计算、AI 计算、大数据、存储、消息队列等核心场景,并与阿里云龙蜥、华为欧拉、腾讯、麒麟软件等主流生态合作,联合多家科技企业共建开源生态,实现技术共享与协同创新。秉承这一精神情怀,钱一峰积极引领开源文化生根发芽,鼓励更多内部技术同学参与开源贡献,让开源不再只是技术成果的输出,更成为连接个人与社区、企业与行业的重要桥梁,让“共建共享”的理念真正融入开源技术创新的每一步。OSCAR开源+安全及风险治理。

DiDi_Tech的博客 957

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 773

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 534

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 695

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 695

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 533

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 423

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 1030

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 544

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

标题:Order Acquisition Under Competitive Pressure: A Rapidly Adaptive Reinforcement Learning Approach for Ride-Hailing Subsidy Strategies作者:Fangzhou Shi(史方舟)、Xiaopeng Ke(柯晓鹏)、Xinye Xiong(熊薪叶)、Kexin Meng(孟可欣)、Chang Men(门畅)、Zhengdan Zhu(朱正丹)论文链接:https://arxiv.

DiDi_Tech的博客 915

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 991

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 370

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 926

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 755

ECML-PKDD ‘25 | FCA-RL框架——基于强化学习的出行服务商动态市场环境效率保障方法

这套离线仿真系统将在后续开源,敬请关注。我们的方法(FCA-RL)相较于传统基线方法大幅降低了出行服务商在动态市场环境下的投资预算控制误差且提升了订单的获取效率,但依然存有局限,比如暂未考虑建模乘客对于投资的长期心智变化及长期供需变化,在未来的工作中,将会尝试将这些考虑进来。在我们的背景设定下,站在我方RSP视角,其他RSP不定期投资幅度变化会导致市场环境动态变化,这会导致在原问题下的求解出的最优解在后续竞争的过程中发生偏移,使得最终花费偏离最初的预算约束,以及原始最优解的钱效变低。

DiDi_Tech的博客 671
上一篇: 滴滴海量离线数据的在线化 — FastLoad
下一篇: 详解火了2019 Google开发者大会的滴滴AR黑科技
滴滴技术
滴滴技术 企业官方账号 企业官方账号
博客等级 码龄8年 2449粉丝 331原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值