这两年我一直在帮企业落地内部知识库，前前后后把 Dify、FastGPT、MaxKB、RAGFlow 这些开源方案都过了一遍。说实话，如果单看“聊天体验”和“流程编排”，RAGFlow 未必排第一，但真要处理那些结构复杂的 PDF、Word、Excel，丢进知识库之后还能翻出带页码的原文出处，RAGFlow 算是我见过的开源产品里，第一个把“文档解析”当成核心竞争力来做的。这篇文章不聊虚的，把我这半年部署 RAGFlow、批量建库、拿它给企业搭知识库的实操过程讲透，也帮还在 Dify、RAGFlow 和同类型开源知识库产品之间纠结的朋友，提供一个明确的选型参考。
我先给个结论：如果你要建的知识库以“文档”为主，且文档里充满表格、多级标题、页眉页脚、扫描件，那 RAGFlow 值得优先试；如果你的核心诉求是快速搭一个带知识库的问答机器人，而且文档类型非常规整，那 Dify 或 MaxKB 可能上手更快。下面的内容，全部围绕 RAGFlow 展开，包括它的架构逻辑、部署步骤、批量处理技巧，以及我踩过的坑。
1. 先搞清楚 RAGFlow 到底解决了什么问题
1.1 一个长期被忽视的痛点：解析质量决定检索上限
在正式讲 RAGFlow 之前，我得先聊一个被很多团队忽略的事实：RAG 系统的效果，一半以上取决于文档解析和切片质量，而不是大模型本身。我自己见过不止一次这种场景：企业选了一个很贵的私有化大模型，又拉了一堆向量库，结果把 Word 和 PDF 丢进去之后，用户问“第一季度销售数据是多少”，系统答非所问。排查到最后才发现，问题根本不在模型，而在文档解析环节——PDF 里的表格被拆得七零八落，Word 里的多级标题完全没被识别，长文档被无脑切成固定长度片段，关键信息被拦腰截断。
传统 RAG 的典型做法是：拿 PyPDF 或 pdfplumber 这类通用库把文本抽出来，然后按固定大小切块，再灌进向量数据库。这种做法在处理“纯文字、无复杂格式”的文档时勉强能跑，但面对企业里那些排版混乱、图文混排、带页眉页脚的标书、合同、产品手册、财务报表时，效果立刻崩盘。
这就是 RAGFlow 立项时想解决的核心问题：它把“深度文档理解”放在整个 RAG 链路的最前端，先让系统真正看明白文档结构，再做切片、向量化和检索。你可以把它理解成，传统 RAG 是让一个实习生对着扫描件快速抄写文字，而 RAGFlow 是让这个实习生先学习版式布局，再按语义和结构把内容分门别类整理好。
1.2 RAGFlow 的设计基调：可解释、可控、可追踪
RAGFlow 是 InfiniFlow 团队开源的一套基于深度文档理解的开源 RAG 引擎，它跟市面上“对话式问答 + 知识库”的产品定位不太一样。官方给它的定义是“Retrieval-Augmented Generation engine based on deep document understanding”，这个定位很准确——它不是一个通用聊天机器人平台，而是一个把“检索增强生成”拆得很细、每一步都给你控制权的引擎。
它的三个设计基调值得每个做企业知识库的人关注：第一，文档解析阶段引入版面分析、表格识别、阅读顺序还原，而不是简单抽文本；第二，切片阶段支持“模板化 Chunk”，也就是针对不同文档类型定义标题、段落、表格的拆解策略；第三，检索出的每一段答案都能追溯到原始文档的页码和位置，做到引用可验证。这三点放在一起，才是它和普通 RAG 工具拉开差距的地方。
对于企业场景，“可解释”尤其重要。老板问“这个结论哪来的”，总不能回答“大模型猜的”。RAGFlow 的引用溯源机制，让每个回答都能回到原始文档具体段落，这在企业内部审计、合规检查、知识考核场景里几乎是刚需。后面我会具体拆解它是怎么实现的。
2. 技术架构拆解：RAGFlow 的文档理解管线是怎么运转的
2.1 从文件入库到答案返回，一条完整的 RAG 链路
我按一条知识库问答请求的完整生命周期来拆解 RAGFlow 的架构。当你把一个 PDF 上传到 RAGFlow 后，它内部要经历四个大的阶段：深度解析、切片与模板化、向量化与索引构建、检索与生成。
深度解析阶段，RAGFlow 内置了 DeepDoc 文档理解模块，它会先对页面做版面分析，识别出文本块、表格、图片、页眉页脚、标题层级等元素，然后按照阅读顺序重新组织内容。这一步最关键，因为后续所有切片都建立在“理解结构”的基础上。
切片完成后，RAGFlow 不会直接把文本一股脑丢给向量模型，而是允许你给不同类型的文档配置 Chunk 模板。什么是 Chunk 模板？简单说，就是告诉系统“这个段落从哪里开始切、切完是否保留标题、表格是否单独成块、关键词和摘要怎么配套生成”。这一步做过知识库的人都懂，切片策略直接决定召回的精准度，切太碎语义断裂，切太大检索噪声高。
随后是向量化。RAGFlow 在部署时会预置一个嵌入模型（Embedding Model），默认支持 BGE 系列中文模型，也允许你通过环境变量切换到其他模型。向量化之后的切片会被写入内置的向量数据库（默认用 Infinity 引擎），并建立索引。需要注意的一点是，RAGFlow 的检索过程是“向量召回 + 重排（Rerank）”两段式：先用向量召回候选片段，再用重排模型对候选结果打分排序。这个设计对最终效果提升非常大，我后面展开讲。
最后阶段，系统把重排后的 Top N 切片包装成上下文，连同用户问题一起交给大模型生成回答，同时给每个切片标注来源文档和页码信息，前端界面上会以划线高亮的方式展示引用出处。
2.2 为什么说“模板化 Chunk + 重排”是企业知识库的胜负手
很多团队一开始会觉得，切片不就是设一个 chunk_size 吗？如果真这么想，那大概率会在企业内部文档上翻车。RAGFlow 最有价值的设计之一，就是允许你为知识库定义不同的 Chunk 方法：按照文档本身的结构去切，而不是按固定字符数硬切。
我在实际项目里最常用的组合是：标题级别设置成“h1/h2 独立成块”，正文段落保持原文顺序，表格单独抽出来建块，并自动生成一个“表格标题 + 表格内容 + 关键词”的组合切片。这么做的好处非常明显。举个例子，一份产品手册里有一张“故障代码表”，传统固定长度切片很可能把一个 20 行的表格拦腰切成三段，检索时你只召回中间那一段，上下文不完整，大模型根本无法正确回答。而 RAGFlow 的表格抽取模式会把整张表作为一个完整块，再配合模板生成摘要信息，效果立刻不一样。
再说重排。光靠向量召回有一个天生缺陷：向量相似度高的片段，语义未必真的对得上。尤其是企业内部文档，大量术语相近但含义不同，Top 5 向量召回结果里经常混入无关片段。加一个重排模型（比如 BGE Reranker）之后，系统会对候选片段逐一计算与问题的相关度分数，只保留得分最高的几个作为最终上下文。这一步我实测下来，平均能把答案准确率拉高 15 到 20 个百分点，代价只是多一次模型推理的时间，非常划算。
顺带提一嘴 RAGFlow 的“引用溯源”机制。它在返回答案时，不会只给你一段文本，而是会把生成回答依据的切片编号、来源文件、页码一起返回。前端界面里点击引用标记，能够直接定位到原文档对应位置。这套机制对企业来说意味着可审计、可复核，是它区别于很多“黑盒问答”产品的关键。
3. 本地化部署实操：Docker 一键拉起与 Windows 11 环境
3.1 部署前的硬性条件评估
RAGFlow 的部署方式对普通玩家非常友好，官方主推 Docker Compose 一键启动。但在动手之前，我建议你先做一轮“硬件体检”，否则后面会遇到各种各样奇怪的性能问题。
我自己的经验，如果要跑一个能用的 RAGFlow 实例，最低配置大概是：CPU 4 核以上、内存 16GB 以上、磁盘可用空间 50GB 以上。这还只是“能用”，如果你要批量处理几百份文档，同时在线用户超过十个，建议直接按官方推荐的生产配置来：16 核 CPU、32GB 内存、不低于 100GB 的 SSD 磁盘。为什么磁盘要留足？因为 RAGFlow 运行时要加载嵌入模型、重排模型，还要存储原始文档、解析结果、向量索引，这些都会在本地落盘。很多人在 Docker 部署后发现容器重启后索引丢失，或者磁盘爆满，基本都是因为预留空间不足。
操作系统方面，RAGFlow 支持主流 Linux 服务器、macOS 和 Windows。Windows 上的体验比较特殊，我放在后面单独说。如果你在 Linux 服务器上部署，我强烈建议直接用 Docker 方式而不要碰源码安装，因为 RAGFlow 的依赖项包含深度学习推理相关组件，手工编译又慢又容易出错，Docker 镜像已经把这些环境全部固化好了。
3.2 Docker Compose 部署全流程
下面是我在 Linux 服务器上完整跑通 RAGFlow 的操作记录，直接抄作业即可。
首先确认 Docker 和 Docker Compose 插件已经安装。用docker compose version检查，如果提示找不到 compose 命令，需要单独安装 docker-compose-plugin 或用docker-compose旧版命令，两者语法略有差异。
然后拉取项目代码，RAGFlow 的部署编排文件都在 GitHub 仓库里，我自己习惯用固定版本下载而不是直接 clone 主干，因为主干更新频繁，偶尔会有配置格式变动。比如我用的版本是 v0.9.0，对应代码目录里的docker/docker-compose.yml。下载解压后，进入目录执行：
docker compose up -d这条命令会按照 compose 文件拉取三个核心镜像：ragflow 主服务镜像、MySQL 镜像、MinIO 镜像，再加上它内置的 Infinity 向量引擎相关组件。首次拉取会比较耗时，镜像总大小差不多 10GB 上下，具体看网速。启动完成后，用docker compose ps查看状态，确保所有服务都是 Up 状态。
接下来打开浏览器，访问http://你的服务器IP:9380，第一次访问会让你设置管理员账号密码。设置完成后，系统会引导你配置嵌入模型和聊天模型。这一步有两个选择：一是使用 RAGFlow 内置的模型服务，它在启动时已经预打包了默认的 BGE 嵌入模型，可以直接选；二是配置外部模型 API，比如企业已有的 OpenAI 兼容接口或者本地推理服务。对企业私有化部署来说，我建议把模型 API 地址指向内网已有的模型服务，避免把文档向量化数据送到外部。
初始化完成后，你可以先建一个空白知识库，上传一份格式简单的 PDF 测试全链路，然后再进入批量处理阶段。整个部署流程其实就三个动作：装 Docker、起 compose、配模型，半小时内能完成。
3.3 Windows 11 上跑 RAGFlow 的几个坑
Windows 11 上部署 RAGFlow 的总体思路和 Linux 一致，都是通过 Docker Desktop 跑容器，但有几个 Windows 特有的坑，我替大家踩过了，提前说出来避免浪费时间。
第一个坑是 WSL2 的内存限制。Docker Desktop 在 Windows 上默认跑在 WSL2 虚拟机里，而这个虚拟机的默认内存上限往往只有物理内存的一半甚至更少。RAGFlow 起容器后要同时跑多个服务，内存不够时表现是：容器能启动，但网页一直加载不出来，或者导入文档时进程直接卡死。解决办法是手动调整 WSL2 的内存配置，在用户主目录下创建.wslconfig文件，内容类似：
[wsl2] memory=24GB swap=8GB然后执行wsl --shutdown重启 WSL 生效。如果你的物理内存只有 16GB，建议把 memory 设成 12GB 左右，给 Windows 本身留一点余量。
第二个坑是端口冲突。RAGFlow 默认占用 9380 端口，如果你机器上已经装了其他应用占用它，compose 启动会直接报端口绑定失败。一般我会先把 9380 和 MySQL 映射端口检查一遍，实在冲突就把 compose 文件里宿主机侧的端口映射换成一个空闲端口，比如 9381:9380。
第三个坑是 Docker Desktop 的资源占用。RAGFlow 跑起来之后，CPU 和内存占用都不低，Windows 本机如果还要干别的活，会明显感觉卡。我给的建议是：Windows 上只做轻量测试，真正批量处理和持续服务，还是放 Linux 服务器上跑。Windows 端作为演示环境完全没问题，但请务必要考虑到 Docker Desktop 在 Windows 上天生多一层虚拟化开销，这也是所有本地容器应用的共性限制。
4. 知识库构建与批量处理实操：文件从入库到可检索
4.1 上传文件前必须先做的三件事
代码跑通了，接下来才是真正考验耐心的地方——知识库内容建设。我在批量处理文件时吃过不少亏，现在总结出三条铁律，每次导入前必做。
第一，把 PDF 统一转成文本版 PDF，再送进解析器。什么是文本版 PDF？就是文件本身自带文字层，可以用鼠标直接选中文字的 PDF。与之相对的是扫描版 PDF，里面全是图片，RAGFlow 虽然自带 OCR 能力，但识别速度和准确率都会下降。如果企业里有大量扫描件，我建议先用 OCR 工具把扫描件转成带文字层的 PDF，再做后续导入。这一条能省下很多排查时间。
第二，规范文件命名。RAGFlow 会以文件名作为知识库检索的来源标识，文件名越规范，最后引用溯源的可读性越强。我一般统一用“文档主题_版本_日期”的格式，比如“数据中心运维手册_v2.3_20240401.pdf”，这样用户在查看引用出处时一目了然，也方便后续版本更新时做去重。
第三，小批量试跑验证。不要一次性把 1000 个文件全传上去，然后等结果出来再发现解析格式不对。我习惯先传 5 到 10 个覆盖不同版式的样本，去“文档解析结果”页面逐个看切片效果，确认标题分割、表格抽取、段落顺序都没问题后，再放开批量导入。
4.2 批量解析时的参数设置与模板配置
RAGFlow 的文档解析界面里，有几个参数最值得关注：Chunk 模板、标题层级、表格策略、关键词生成开关。
先说 Chunk 模板。默认情况下，系统会按“标题 + 正文段落”的方式切分，适合大多数结构化文档。但如果你处理的是操作手册、规章制度这类标题层级很重的文档，建议自定义模板：用“h1 作为顶层切分依据，目录自动生成，每个 h1 下的内容作为一个独立大块，内部再根据 h2 分隔”。这样切出来的块，语义完整性极高，用户问的问题只要落到某个二级标题下，基本都能精准召回。
表格策略我建议选择“独立成块 + 生成表格摘要”。RAGFlow 会尝试把页面中的表格区域识别出来，作为独立对象进行抽取。开启表格摘要后，系统会在切片时额外生成一段对表格内容的概括性描述，把它存在块的开头。这么做的好处是：用户提问时经常不包含表格里的具体值，而是问“5 月份哪些型号库存缺货”，如果块里没有语义描述，只有一堆数字表格，向量召回很难匹配上；加上摘要后，检索命中率会明显提升。
还有一个经常被忽略的选项是“自动关键词生成”。默认开启，系统会为每个 Chunk 生成若干个关键词标签，这些标签会参与向量匹配。我实测下来，对于中文文档，这个功能对召回率提升有帮助，但会额外增加解析耗时。如果你的文档批量很大，可以按需关闭来换速度。
批量上传时，我建议控制并发，一次传个二三十个文件，等解析完成再传下一批。原因很简单：RAGFlow 的解析任务很吃 CPU，同时解析几百个文件会造成负载飙升，反而拖慢整体速度，还不如分批稳扎稳打。解析失败的文件也会在任务列表里标红，可以单独点击查看失败原因，大部分失败都出在“文件损坏”“格式不支持”“PDF 加密”这三类。
4.3 RAGFlow 的检索调优：从默认配置到企业级效果
建完库只是开始，检索效果调优才是知识库落地的重头戏。第一次检索时大多会遇到一个问题：召回结果命中关键词不够精准，或者答案生成的内容引用了不相关的文档段落。这时候不要立刻怀疑是模型不行，先按下面三个步骤排查。
第一步，确认重排模型是否启用。RAGFlow 默认会在检索时调用重排器，但如果你的配置里没有指定重排模型，或者重排模型服务没起来，它是会静默跳过还是报错，取决于版本。强烈建议到设置里确认已经添加 RAGFlow 自带的重排模型，比如 BGE-Reranker，并在知识库配置里把它勾上。这是投入产出比最高的调优手段。
第二步，调整召回数量参数。知识库配置里一般有“召回片段数量”和“重排后保留数量”两个参数。默认值是召回 6 到 8 个、保留 3 到 4 个。如果你的文档块切得比较细，可以适当调大召回量，比如召回 12 个再重排保留 5 个，能给生成模型提供更充分的上下文。但要注意，保留太多会稀释答案的聚焦度，反而让回答显得啰嗦。
第三步，检查嵌入模型与文档语言是否匹配。中文文档优先选 BGE 或 M3E 系列中文优化的嵌入模型，尽量避免用面向英文语料的通用模型。很多团队部署时图省事挂了 OpenAI 的 embedding 接口，处理英文文档还行，处理中文企业文档效果中规中矩。RAGFlow 部署时预置的 BGE 嵌入模型在中文场景下表现已经很稳，如果自己另配模型，建议用几组带标准答案的测试问题做一次召回率对比，再决定到底用哪个。这一步值得多花时间。
5. 企业级知识库选型对比：RAGFlow 与其他开源方案怎么选
5.1 几个关键维度的对比拆解
每天都有团队在社区里问“RAGFlow、Dify、FastGPT、MaxKB 到底选哪个”。我给企业做技术选型时，一般不看谁的功能列表长，而是看四个维度：文档解析深度、流程编排能力、模型接入灵活性、私有化部署门槛。下面这个表格是我基于实际体验整理的心得，供参考：
| 对比维度 | RAGFlow | Dify | 其他开源知识库（如 MaxKB 等） |
|---|---|---|---|
| 文档解析深度 | 强，支持版面分析、表格抽取、模板化 Chunk | 中，对复杂 PDF 表格处理较弱 | 弱到中，主打简单文本切分 |
| 流程编排能力 | 中，侧重知识库检索链路 | 强，可视化 Agent 工作流 | 中，主打问答机器人 |
| 模型接入灵活性 | 中高，支持 API 和本地模型 | 高，兼容几乎所有主流模型接口 | 中，通常绑定自家推荐配置 |
| 引用溯源 | 强，逐段标注页码和文档位置 | 弱，只返回来源知识库名称级别 | 中，能定位到片段但展示弱 |
| 上手门槛 | 中，强调调优和模板 | 低，十分钟可跑通 | 低，快速聊天式问答 |
先说 RAGFlow 的优势区间。如果你的核心场景是“企业内部知识库”——比如规章制度库、产品手册库、售后维修资料库、项目文档库，这些场景极度依赖文档结构和表格信息，那张表里 RAGFlow 的解析优势会被放得很大。尤其是标书、合同类文档，里面有大量条款编号和表格数据，传统 RAG 工具基本无能为力，RAGFlow 则能比较完整地保留下逻辑结构。
Dify 的优势则在流程编排。如果你想做一个复杂的 Agent：先调用工具、再查知识库、然后走多轮对话策略、最后对接外部系统，Dify 这种工作流引擎比 RAGFlow 灵活得多。但代价是它对文档解析本身不怎么上心，同一个 PDF 在 Dify 里切出来的块，跟 RAGFlow 里切出来的块，质量差距非常明显。所以我常建议：文档质量高、格式简单、核心诉求是快速搭建 Agent 应用选 Dify；文档格式复杂、内容为王、需要高准确率知识问答的，选 RAGFlow。
MaxKB 这类产品，更强调“开箱即用”和运维集成场景，通常自带了与运维工单、监控告警联动的模块，适合做客服问答和内部运维助手。但它的文档理解能力比 RAGFlow 弱一档，如果你只是需要一个“能和知识库对话的机器人”，它可以胜任；如果需求上升到“准确回答并给出可追溯依据”，它的短板就出来了。
5.2 我的选型方法论与建议
我自己的选型决策流程是这样的，你可以直接用：先拿十份有代表性的真实业务文档，跑一遍各候选方案的解析结果，肉眼检查切片质量。这一步基本能筛掉 60% 的方案。然后做一轮二十个标准问题的问答测试，对比答案准确率和引用正确率。这两步跑完，候选方案的高下自然就出来了。
还有一个很多人忽略的维度是团队技术栈。RAGFlow 虽然部署简单，但如果你想深度调优——比如定制解析模型、改 Chunk 模板、接入自己的重排模型——你需要团队具备一定的 Python、Docker、机器学习基础。Dify 则更偏向应用开发人员，会写 API、能拖工作流就能上手。所以最终选型不只是选产品，也等于在选后续的维护成本。
结合我服务过的企业案例，给出我比较推荐的组合：知识库核心引擎用 RAGFlow，承担文档解析、检索、引用溯源；上层对话应用如果以后要做复杂 Agent，可以再接入 Dify 来做工作流编排。两套系统通过 API 打通，既发挥了 RAGFlow 的文档理解优势，又不牺牲 Dify 的编排灵活性。目前这种“组合拳”的方案在不少企业都跑得不错。
6. 常见问题速查与避坑记录
6.1 部署、导入、检索三类高频问题
把我在社区和项目里遇到的问题整理成速查表，方便你排查时直接对号入座。
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 网页无法打开 | 服务未全部启动、端口冲突 | docker compose ps检查，换端口重启 |
| 上传 PDF 后一直解析中 | 文件是加密或扫描版本、CPU 资源不足 | 去密、转文本版 PDF、减少并发解析 |
| 答案引用内容与问题无关 | 重排模型未启用、切片粒度不合理 | 启用重排、调整 Chunk 模板 |
| 检索不到中文关键词 | 嵌入模型与语言不匹配 | 切换到 BGE 或中文优化的嵌入模型 |
| 批量导入大量失败 | 文件格式不支持、命名不规范 | 按支持列表预处理格式 |
| 磁盘空间迅速占满 | chunk 快照和索引文件多 | 定期清理旧文件、重建索引 |
| Windows 上容器频繁重启 | WSL2 内存不足 | 调整.wslconfig内存上限 |
这里挑两个最典型的展开说。一个是“解析任务一直卡住”的问题。在批量导入文档时，经常会看到某个文件一直处于 50% 解析进度不动，后面所有任务排队等它。我排查后的结论是，这类文件通常是某个页面存在超大分辨率图片，DeepDoc 识别图像的过程把 CPU 占满了。解决办法是先把这类文件单独拎出来，用图像压缩工具把重图压一遍再入库。
另一个是“检索结果看起来很准但答案不准”。这个问题往往不是检索链路的问题，而是生成环节的幻觉。RAGFlow 支持在对话时调整温度，降低生成模型的随机性。企业知识库问答场景，建议把温度设低，比如 0.1 到 0.3，让模型尽可能基于检索内容作答而不是自由发挥。这个细节经常被忽略，但对准确率的影响特别大。
6.2 我在实际项目里沉淀的四条经验
第一，模板化 Chunk 值得花时间仔细调。很多团队建完知识库就把 RAGFlow 扔给用户用，结果受不了。其实真正拉开效果差距的，是上线前对每个知识库定制 Chunk 模板的过程。操作手册、财务报告、合同文书这三类文档，模板完全不同。你越愿意在模板上花时间，上线后的问答效果越稳定。
第二，定期重建索引不是可有可无。RAGFlow 在文档更新后会自动增量索引，但如果你大批量删除了旧文件，或者替换了嵌入模型，库里会残留很多旧索引垃圾，影响检索速度。我习惯每个月做一次全量重建：导出知识库、删除重建、重新导入。虽然耗时，但换来的检索质量提升非常明显。
第三，版本升级前先备份 docker-compose 配置和数据库。RAGFlow 迭代速度很快，每次升级都可能改配置文件格式。我最早因为直接升级导致知识库配置全部丢失，后来学乖了：升级前用docker compose exec mysql导出数据，同时把自定义的模板配置截图留档。这个习惯帮我省了很多麻烦。
第四，选型对比一定要用同一批测试文档。很多团队比较 RAGFlow 和 Dify 时，拿各自的官方演示文档测试，得出的结论毫无意义。正确做法是：准备一套包含 PDF、Word、Excel、扫描件的混合样本，统一跑三遍——解析速度、切片质量、问答准确率。跑完数据一目了然，比任何人讲都直观。
我个人在实操中最深的体会是，RAGFlow 在开源 RAG 领域扛把子级别的存在，它的价值不光是代码开源，更是把“深度文档理解”这个概念真正落到了产品里。如果你所在的企业正在被复杂文档困扰，我建议按这篇文章的流程先搭一个测试环境，拿真实业务文档跑一轮，你会很快判断出它适不适合你。知识库的搭建从来不是一次性的项目，而是一个需要持续调优的数据工程，选对了引擎，后面的路会顺畅很多。
