企业官网建设流程全解析

1. 为什么要在自己的机器上跑一套大模型对话界面

去年这个时候，我第一次把模型跑在自己那台闲置的机器上，动机特别朴素：只是想有个随时随地能用、不用排队、不担心对话内容外流的问答工具。真正动手之后才发现，这件事的门槛比想象中低得多——只要你愿意花一个下午，就能得到一套完全属于自己、能随时切换模型的对话系统。标题里提到的这套组合，本质上是三件事拼在一起：Ollama 负责把模型跑起来，Open WebUI 负责给你一个顺手的聊天界面，Docker 负责把这两件事的安装过程压缩成几条命令。

很多人第一次听到"私有化部署"这四个字，以为要买服务器、要配域名、要懂运维。其实不是。一台有 16GB 内存的普通电脑，或者一台吃灰的小主机，就足够跑起来。你不需要公网 IP，不需要备案，甚至不需要联网——模型下载完之后断网也能用。它解决的问题非常具体：你有一个需要反复提问的场景（写代码时查 API 用法、看文档时做总结、整理会议记录），你不想每次都打开浏览器登录某个服务、等它转圈、还要担心刚才贴进去的代码会不会被记录。

适合谁来参考？三类人最合适。第一类是手上有闲置硬件、想榨干剩余价值的人，一台旧笔记本或者迷你主机就能变成你的私人助手。第二类是对数据流向比较在意的人，比如处理内部文档、客户资料、未公开的代码片段，这些东西贴到任何外部服务里都要掂量一下。第三类是想低成本试玩各种开源模型的人，标题里提到的 gemma、llama2、qwen 这几个系列，参数规模从十几亿到几百亿都有，换一个模型就是改一行命令的事，比在网页上注册账号试用来得快。

我想先把预期说清楚，避免你装完之后失望：这套东西跑出来的效果，和你平时用的那些云端服务不在一个量级。本地能跑的模型，参数量受限于你的内存，7B、8B 级别的模型在常识问答和日常写作上够用，但遇到复杂推理、长文档精确引用、多步数学计算，就会明显吃力、开始胡编。所以我一直建议把它当成"随身小工具"而不是"全能助理"——查语法、改措辞、解释报错、把一段啰嗦的话压缩成三条要点，这些它做得很好；让它帮你设计一套分布式架构，那就别指望了。把预期摆正，这套东西的性价比高得惊人。

还有一个容易被忽略的点：Docker 在这里的价值不是"高级"，而是"可复现"。手工装 Ollama 再手工装一个前端，中间会牵扯到 Python 版本、依赖冲突、端口占用、服务自启动等等一堆琐碎问题，换台机器重来一遍又要踩一遍。用容器编排之后，整套环境被描述在几个配置文件里，出问题删掉重来，换机器复制过去，十几分钟又能跑起来。这是我这几年在本地折腾各种服务之后最深的体会：能重来，比能跑通更重要。

下面我按实际动手的顺序往下讲，从机器要求、模型选择，到编排文件怎么写、坑怎么填。

2. 动手之前：硬件、系统与模型的现实账

2.1 内存决定一切，先算清楚这笔账

本地跑模型，最硬的约束不是 CPU 也不是显卡，是内存。模型文件在你加载它的时候，基本上要整个读进内存（如果显卡显存够，会优先放显存）。所以第一件事是把模型文件大小和你的可用内存对一下。

下面这张表是我实测和推算出来的经验值，按量化后的常见体积估算，给你一个选型基准：

这里有个很多人踩的坑：只看内存总量，不看可用内存。系统本身、Docker 守护进程、浏览器、你开着的编辑器都要吃内存。一台标称 16GB 的机器，实际可用往往只有 11~12GB。所以我的建议是：可用内存至少是模型体积的两倍，留出加载峰值和系统余量。8GB 机器老老实实跑 7B/8B，不要贪心去试 13B，加载到一半被系统杀掉进程，你会以为是软件有问题，其实是内存不够。

另外要区分"有显卡"和"没显卡"。有独立显卡（显存 8GB 以上）的话，模型会部分或全部进显存，速度提升非常明显，每秒出词能从个位数跳到几十个。没有独显、只有核显的机器也不是不能跑，CPU 推理照样能用，只是要有心理准备：一句话的回答可能要等十几秒。我自己的主力机器就是纯 CPU，日常查语法、改措辞完全够用，因为这类任务的输出通常只有几行。

2.2 系统与 Docker 的前置条件

系统层面没有太多讲究，主流的 Linux 发行版、macOS、Windows 都行。唯一的硬要求是Docker 引擎本身要能正常工作，而且版本别太老。我见过有人在一个很久没更新的环境里装，结果编排文件的语法不被识别，报了一堆看不懂的错，折腾半天才发现是版本问题。

动手前的检查清单，建议你逐条过一遍：

• docker --version输出正常，版本不是那种三五年前的老古董
• docker compose version能输出结果。注意这是新版插件的写法，中间有空格；老式的docker-compose（带横杠）是独立程序，两者命令行行为有细微差别，容易混
• 当前用户有权限操作 Docker。Linux 下如果每次都要加sudo，要么把用户加进 Docker 用户组，要么全程用提权方式执行，别一半加一半不加，容易搞出权限混乱
• 确认磁盘剩余空间。一个 7B 模型 5GB 左右，装三四个模型就是 20GB 出去了，加上镜像本身，建议留出 40GB 以上的空闲空间

还有一个特别容易被忽略的：端口占用。这套组合默认会用两个端口，一个给后端服务，一个给网页界面。如果你机器上已经跑了别的东西占着这两个端口，容器起不来，日志里只会告诉你端口被占用，不会告诉你被谁占了。提前用系统自带的端口查看方式确认一下，能省掉一轮排查。

Windows 用户额外注意一点：Docker Desktop 默认的资源分配是有限的，有时候只给容器分了几 GB 内存，你在宿主机上看内存很富裕，容器里却跑不动模型。这个设置项在设置界面里能调，第一次装完建议先去把它调大，我见过至少三个人在这里卡了两天。

2.3 gemma、llama2、qwen 三个系列怎么选

标题里点的这三个系列，代表了三种不同的取向，值得单独说一下怎么选，因为它们不是简单的"越大越好"的关系。

llama2是这批开源模型里资历最老的，生态最成熟，各种教程、各种衍生版本最多。它的 7B 版本在 8GB 内存的机器上跑得很稳，回答风格偏保守、偏正式。缺点是知识截止时间较早，你问它最近发生的事情，它会答不上来或者给出过时的信息。适合拿来做基础测试，验证你的环境是不是搭对了。

gemma系列的特点是同等参数规模下体积控制得不错，2B 的小版本在低配机器上非常合适——1.5GB 左右的体积，4GB 内存就能跑起来，响应速度快，适合做那种"随手一问"的场景，比如"这个函数名怎么改更清楚"、"帮我把这段日志翻译成人话"。7B 版本则更适合正经一点的文本任务。

qwen系列是我个人在中文场景下最常用的。它对中文的处理明显比前两个系列自然，标点、语气词、成语这些细节不容易出洋相。如果你主要用它处理中文内容——写周报、改文案、解释中文报错信息——优先试这个系列，尤其是 7B 上下的版本，在中文问答上的性价比很高。

选型的实际建议是这样：先用一个小模型（2B 级别）把整条链路跑通，确认界面能打开、能对话、能正常返回。这一步的目的是排错，用小模型启动快、失败快，出问题一眼能看出是环境问题还是模型问题。链路通了之后，再按你的内存和需求换成 7B 或者更大的模型。别一上来就拉一个 30B 的模型，加载十分钟，失败了你还得重新判断问题出在哪一环。

3. 用编排文件把整套环境钉死

3.1 为什么不用一堆 docker run 命令

第一次搭这套东西的时候，我是照着教程一条条敲docker run的，两条命令敲完能跑起来，感觉挺爽。第二次换机器重装，我发现我记不住那些参数了——端口映射写反了、卷挂载的路径少写了斜杠、网络没连上导致前端找不到后端，折腾了快一个小时。

问题不在于命令难，在于命令是一次性的，不会留下任何记录。你今天调通了，三个月后机器重装，你只能靠回忆。所以我后来的做法统一改成：写一个编排文件，把整个服务栈声明清楚，然后一条命令拉起。好处有三个，我列出来你感受一下：

• 参数可视：端口、卷、环境变量、依赖关系全写在文件里，出问题一眼能对照
• 一键重来：配置改错了，删掉容器重新拉起，不用重新敲一遍命令
• 便于迁移：换机器把文件拷过去，模型目录也拷过去，直接起

下面这份编排文件是我自己在用的精简版，你去掉注释直接能用。我故意把两个服务写在同一个文件里，这样它们会自动进入同一个网络，前端用服务名就能找到后端，不需要你手动建网络、手动连容器。

services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./ollama-data:/root/.ollama # 有 NVIDIA 显卡时保留下面这段，纯 CPU 机器整段删掉 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - "3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 volumes: - ./webui-data:/app/backend/data depends_on: - ollama

这份文件里有几个地方值得展开说，因为它们直接决定了你后面会不会踩坑。

卷挂载的路径。我写的是相对路径./ollama-data，意思是容器数据存在编排文件同目录下的文件夹里。这样做的好处是数据跟着项目走，你想备份就是把整个文件夹拷走，想迁移就是拷到新机器上。很多人图省事不挂载卷，结果容器一删，几个 GB 的模型全没了，要重新下载。模型下载在国内网络环境下有时候慢得让人想砸键盘，丢一次你就记住了。

depends_on的作用有限。它只保证启动顺序——先起后端再起前端，但不保证后端"已经准备好接收请求"。所以第一次启动的时候，前端可能会短暂报连不上后端，等十几秒刷新一下就好了。这不是故障，是启动时序问题。我一开始也以为配置错了，查了半天日志才发现后端还在初始化。

端口映射的左右关系。"3000:8080"的意思是宿主机的 3000 端口转发到容器的 8080 端口。左边你可以随便改，右边别动，因为那是容器内部服务监听的端口。我第一次写反了，访问 8080 打不开，访问 3000 打开了但页面是空的，绕了一圈才反应过来。

restart: unless-stopped这行很实用。机器重启之后容器自动起来，不用你手动去拉。除非你明确停掉它，否则它一直在。对于这种"装好就长期挂着"的服务，这行几乎是必写的。

3.2 显卡加速那段配置什么时候该留

上面文件里有一段deploy.resources.reservations.devices的配置，是给有 NVIDIA 显卡的机器用的。判断标准很简单：nvidia-smi这条命令能正常输出显卡信息，说明驱动和工具链齐了，可以保留；命令不存在或者报错，那就整段删掉，不要留着。

留着但环境不支持会怎样？容器启动失败，日志里会报找不到 GPU 设备或者驱动不匹配。这个错误看起来吓人，其实就是配置和环境对不上。删掉那段配置重新拉起，立刻恢复正常。

对纯 CPU 的机器，还有个隐性好处：删掉这段之后，你不需要装任何显卡相关的运行时组件，整个部署流程少了一大块依赖，成功率高很多。我见过不少人卡在显卡运行时安装这一步，装了两天没装好，其实他们根本不需要——先用 CPU 把整套跑通，后面想加速再说。

3.3 一条命令拉起的完整流程

编排文件写好后，把它放在一个你专门建的空目录里，比如~/ai-stack/。然后打开终端进到这个目录，执行：

docker compose up -d

-d是后台运行的意思。执行之后它会去拉两个镜像，第一次会花几分钟，取决于你的网络。拉完之后容器就在后台跑起来了，用docker compose ps能看到两个服务的状态，都显示 running 就对了。

接下来验证后端是否正常：

curl http://localhost:11434/api/tags

这条命令是问后端"你现在有哪些模型"。如果返回一段 JSON，哪怕是空的模型列表，也说明后端活得好好的。如果返回连接被拒绝，那说明容器没起来，去看日志。

日志的查法：

docker compose logs -f ollama

-f是持续跟踪，能看到实时输出。按Ctrl+C退出跟踪但不会停容器。这一步是我排查问题的第一站，九成的问题在日志里都有直接答案，别急着去网上搜，先看日志。

界面这边，浏览器打开http://你的机器地址:3000。第一次访问会让你注册一个管理员账号。这个账号只存在你本地，密码随便设，但建议记下来——后面换浏览器或者清缓存了还得登录。注册完之后你就进到聊天界面了，此时大概率还没有模型，界面会提示你去拉模型。

4. 模型下载与第一次对话

4.1 用命令行拉模型，比在界面里等更可控

界面里也能拉模型，但我不推荐，原因很实在：看不到进度，卡住了不知道是慢还是死了。命令行拉模型会显示下载进度条，你能判断它是在正常下载还是彻底卡住。

拉模型的命令长这样：

docker exec -it ollama ollama pull qwen2.5:7b

拆开看：docker exec -it ollama表示进入名为 ollama 的容器执行命令，ollama pull是拉取模型，后面跟着模型名和标签。标签就是版本号，不写的话默认拉最新的。

几个常用的模型名，你可以按内存情况挑：

# 小体积，用来验证链路，4GB 内存可跑 docker exec -it ollama ollama pull gemma2:2b # 主力选择，8GB 内存推荐，中文场景优先 docker exec -it ollama ollama pull qwen2.5:7b # 老牌稳定，做个对照 docker exec -it ollama ollama pull llama2:7b # 内存富裕时尝试，16GB 以上 docker exec -it ollama ollama pull qwen2.5:14b

拉完之后确认一下：

docker exec -it ollama ollama list

会列出本地所有模型，带体积和更新时间。看到目标模型在里面，就说明装好了。这时刷新网页界面，左上角的模型下拉框里就能选到它。

提示：下载中断是很常见的情况，尤其是大模型。重新执行同一条pull命令会接着断点续传，不会从头开始，所以中断了不用慌，重跑就行。

4.2 第一次对话该问什么

第一次对话我建议故意问一个你已知答案的问题，用来判断模型能力和环境是否正常。比如问"把下面这句啰嗦的话精简到 20 字以内：这个方案在考虑到各方面的因素之后，我们认为目前阶段暂时还不具备实施的条件"。答案明显应该接近"现阶段暂不具备实施条件"。

为什么要这样测？因为如果模型输出乱码、重复同一句话、或者答非所问，说明环境有问题（可能是模型文件损坏，或者模型和界面之间的接口对不上）。用一个有标准答案的问题，你能立刻区分"模型能力不行"和"环境搭错了"这两种完全不同的情况。

我在第一次跑通的时候犯过一个错：界面里选了模型，发消息一直转圈没有回复。我以为是模型太大加载慢，等了五分钟。后来看日志发现，界面的模型下拉框里选的是"默认"，但实际请求发到了一个我根本没下载的模型名上。解决办法很简单——在下拉框里明确选一个你已经拉下来的模型，别用默认。

环境跑通之后，接下来才是正经用法。我给几个我实际高频使用的场景，你可以照着试：

• 解释报错：把一段看不懂的报错信息贴进去，让它用人话说明白是哪里出错、大概什么原因。本地模型在这类任务上表现比想象中好，因为报错信息本身信息量大，不需要模型有太多外部知识
• 改写措辞：写完一段话觉得别扭，让它改一版更通顺的，通常能给你几个可选方向
• 生成样板代码：让它写一个函数的骨架、一个配置文件的模板，然后你自己填细节。本地模型写复杂逻辑容易出错，但写结构、写样板很在行
• 翻译与润色：中英互译、把口语化的内容改成书面表达，这类任务对模型能力要求不高，7B 级别完全够

4.3 模型在哪些地方会让你失望

这部分我必须单独说，因为它直接决定了你会不会在用了三天之后把这个系统扔在一边。

本地小模型最不可靠的地方是精确事实。你问它某个库的函数签名、某个版本的具体变更、某个人的出生年份，它很可能会给你一个看起来非常像真的、但完全错误的答案。这种错误最危险，因为它编得太自然了，你不去核实根本发现不了。我的做法是：凡是需要精确的地方，一律不用它回答，只让它整理和改写我自己提供的内容。

第二个失望点是长文档处理。你贴一篇五千字的文档让它总结，7B 模型经常会漏掉中间部分，或者把前后内容混在一起。这不是配置问题，是模型本身的能力上限。如果确实要处理长文本，两个办法：一是分段喂，一段一段总结再合并；二是换更大参数的模型，但代价是速度。

第三个是多轮对话的记忆衰减。聊了七八轮之后，它可能忘记你前面说过的约束条件。这不是 bug，是上下文窗口的机制决定的。重要的约束条件，在关键提问里再重复一遍，比指望它记住可靠得多。

把这些边界搞清楚之后，这套系统的价值反而更清晰了：它是一个不会泄露内容、随时可用、零成本的文本处理工具，不是一个知识库，更不是一个能替你做判断的助手。用对地方，它很好用；用错地方，你会觉得它一无是处。

5. 那些文档里不会写的坑

5.1 数据卷权限和"模型下完了但界面里看不到"

这是出现频率最高的一个问题，我至少帮人排查过五次。现象是：命令行里ollama list能看到模型，但网页界面的下拉框里空空如也。

原因通常有两个。第一个是模型确实下到了容器里，但没下到挂载的卷里。如果你在挂载卷之前就用别的方式拉过模型，那些模型存在容器的临时层里，容器一重建就没了。判断方法很简单：docker compose down再up -d，如果模型消失了，说明它没在卷里。

第二个原因是前端缓存了旧的模型列表。界面的模型列表是在加载时拉取的，你在另一个终端里拉了新模型，界面不知道。强制刷新浏览器（大多数浏览器是Ctrl+Shift+R）通常就能看到。

还有一种比较隐蔽的情况：两个服务不在同一个网络里。正常情况下写在同一个编排文件里的服务会自动连通，但如果你之前用别的方式单独起过后端，端口和网络就会打架。这时候前端配的后端地址指向了一个已经不存在的容器，看起来是"没模型"，实际是"连不上后端"。排查方法是看前端日志里有没有连接失败的记录，比盯着下拉框猜要快。

5.2 端口冲突的表现和排查链路

端口冲突的症状很典型：docker compose up -d之后，docker compose ps显示某个容器状态是 exited 或者反复重启。这时候别急着重装，按这个顺序查：

第一步，看这个容器的日志。docker compose logs 服务名，日志里如果出现"address already in use"这类字样，基本就确定是端口被占了。

第二步，找出谁占着这个端口。系统自带的网络工具能列出当前监听的端口和对应进程，Linux 和 macOS 上有对应的命令行工具，Windows 上可以用资源监视器看。找到之后你有两个选择：停掉那个程序，或者改我们这套服务的端口。

第三步，改端口。改编排文件里冒号左边那个数字，比如把"3000:8080"改成"3001:8080"，然后docker compose up -d重新拉起。注意后端端口也在用，如果 11434 也被占了，两个都要改。

我踩过的一个坑是：改了端口之后忘了改前端的环境变量。前端的OLLAMA_BASE_URL里写的还是旧的后端端口，结果界面能打开但一发消息就报错。这种"改了 A 忘了 B"的情况，在这类多服务编排里特别常见，改动之前先想清楚有哪些地方引用了这个值。

5.3 启动顺序带来的"假故障"

depends_on只保证启动先后，不保证服务就绪。这个问题在低配机器上尤其明显，因为后端加载模型本身就要花时间。

表现是：容器都 running，但打开界面发第一条消息时，它会转很久，然后报一个连接超时或者 502 之类的错。第二次发就好了。

处理办法有两个。简单粗暴的是等。启动后先去做别的事，两三分钟后再用。另一个办法是预加载模型，主动发一个请求让后端把模型读进内存：

curl http://localhost:11434/api/generate -d '{"model":"qwen2.5:7b","prompt":"hi","stream":false}'

这条命令会把指定模型加载起来并做一次推理。执行完之后模型已经在内存里待命，界面里的第一次对话就会很快。这个技巧在演示或者给别人展示的时候特别有用，能避免"第一次用就卡住"的尴尬。

需要提醒的是，模型加载进内存之后会一直占着，直到有一段时间不用被系统回收。所以如果你内存紧张，别同时预加载好几个模型。

5.4 磁盘悄悄被吃光

这个问题最阴险，因为它不报错，只是某天你发现系统卡得不行，或者容器莫名重启。

模型文件都很实在，一个 7B 模型 5GB 上下，你试了四五个模型就是 20 多 GB。加上 Docker 镜像本身、构建缓存、日志文件，三四十 GB 很容易就没了。

定期清理的原则是：不用的模型删掉，不用的镜像清掉。删模型用ollama rm 模型名，这个命令在容器里执行。清镜像和悬空资源用 Docker 自带的清理命令，但注意别把正在用的镜像清了，清理前先看一眼有哪些镜像在跑。

我自己的习惯是每试完一批模型，就ollama list看一眼，把明显不会再用的删掉。犹豫要不要删的时候，问自己一句：这个模型我这周用过吗？没用过就删，需要的时候再拉，反正下载速度比纠结的速度快。

5.5 换个网络环境就下载不动

模型下载慢或者中断，很多时候不是你的问题，是网络路径的问题。这个我没法给具体方案，但有几个通用思路。

一是优先拉体积小的模型验证一切正常，别一上来就拉 30B 的。二是中断了直接重跑，大多数情况支持续传。三是错峰，某些时段网络确实更拥堵。四是如果反复失败，先确认磁盘空间够不够——磁盘满了会表现成下载中断，这个错我犯过。

还有一点值得说：拉模型和拉镜像是两件事。镜像（Ollama 本体、WebUI 本体）体积小，通常很快；模型动辄几个 GB。如果卡在镜像这一步，那是网络问题；如果镜像好了卡在模型，也是网络问题，但更可能是带宽。区分清楚，排查方向不一样。

6. 让它长期稳定跑着的几个习惯

先说最实在的一条：先备份再折腾。这套系统的全部状态就两个文件夹，一个是模型目录，一个是界面目录（存账号、对话历史、配置）。改动编排文件之前，把这两个文件夹拷一份，出问题直接还原，比你翻日志快十倍。我在这个上面吃过亏——有一次手滑改了挂载路径，重建容器之后对话历史全没了，虽然不是什么重要的东西，但那种"本来可以不丢"的感觉很不舒服。

第二条：升级要谨慎，别追新。镜像标签写着 latest 的那种，你某天重启一下可能就拉到新版本了，新版本可能有新的要求（比如需要更新的 Docker 版本，或者配置项改名了）。我的做法是跑通之后把标签固定下来，不主动去追新。真想升级，先备份、再升、有问题回滚。

第三条：限制一下资源。如果不做限制，一个跑模型的容器可能把内存吃掉大半，导致你其他程序卡顿。编排文件里可以给服务加资源上限，具体写法按你的 Docker 版本查一下文档。设上限的代价是超大模型可能跑不动，但换来的是系统整体不卡，我觉得值。

第四条：给界面加一道门。默认情况下这套东西只能在本地访问。如果你想让同一局域网里的其他设备也能用（比如手机、平板），需要把监听的地址放开，同时务必设一个强密码。这套系统没有内置的账号体系之外的防护，一旦放开到网络里，谁都能进来聊，甚至能看到你的对话历史。我在自己家局域网里放开过，用起来确实方便——手机上随时问一句，但密码设得比较长。

第五条：记住它只是个工具，别为了用它而用它。这话听起来奇怪，但确实是我用了半年之后的真实感受。一开始我把什么都往里面塞，结果发现很多任务用搜索引擎、用现成的编辑器插件更快。后来我把它的使用场景收窄了：处理不方便外发的内容、需要反复改写的文本、离线环境下的查漏补缺。场景收窄之后，它反而变成了我一个高频使用的工具，因为我知道什么时候该找它，什么时候不该。

最后分享一个我最近才养成的小习惯：给常用的提问存个模板。比如"把下面这段内容压缩成三条要点，每条不超过 20 字"、"指出下面这段代码里可能的空指针风险"、"把这封邮件改得更委婉但保持明确"。这些模板存在笔记里，需要的时候复制粘贴，比自己现编 prompt 稳定得多。本地小模型对 prompt 的敏感度比大模型高，一句明确的指令和一句模糊的要求，输出质量差距很明显。这个习惯花不了多少时间，但能显著提升你每天用它的效率。

硬件这块还有个后续可玩的方向：如果你手上有多台机器，可以让一台上只跑后端、其他的只跑界面，把算力集中到一台内存大的机器上。编排文件拆成两个，前端那台把OLLAMA_BASE_URL指向后端机器的地址就行。这个玩法我试过一次，在同一局域网里延迟很低，用起来和本地没区别，如果你的主力工作机内存小、又有台大内存的机器闲着，这是个不错的组合。